grsecurity forums

by **Murphy** » Thu Apr 17, 2003 2:50 pm

When I try to change the password for a user (as that user), it doesn't let me. It gives me this error: "Cannot lock the password file; try again later."

It didn't happen with 1.9.9e and Slackware 8.1 but now I'm using 1.9.9f and Slackware 9.0. Anyone have any idea why this is happening and how I can fix it?

Thanks

by **Murphy** » Thu Apr 17, 2003 2:55 pm

also, if I su to root and type passwd <user>, it gives me the same error. If I do gradm -a and enter the grsecurity password, then try to change the password of a user, it works fine, but I shouldn't need to do that to change a password.

by **TGKx** » Thu Apr 17, 2003 5:32 pm

Read the kernel log for the access denied messages from grsecurity. That will tell you why your ACL is not working with passwd and what permissions you need to correct.

by **Murphy** » Fri Apr 18, 2003 5:03 pm

I'm not sure I know what you mean by kernel logs but every time I'm not able to change my password, errors are sent to tty1 on the machine. These are the errors I get and I tried editing the acl file to allow those files to be written to, did gradm -R, but it just won't work:

grsec: From 64.202.110.30: denied open of /etc/.pwd.lock for writing by (passwd:32091) UID(0) EUID(0), parent (bash:12167) UID(501) EUID(501)

grsec: From 64.202.110.30: denied connect to the unix domain socket /dev/log by (passwd:32091) UID(0) EUID(0), parent (bash:12167) UID(501) EUID(501)

grsec: From 64.202.110.229: denied open of /var/log/wtmp for writing by (sshd:10961) UID(0) EUID(0), parent (sshd:32028) UID(0) EUID(0)

The last problem means that the "last" command wont even show the last logins and I don't know how to correct either of these problems. I've been using grsecurity for a while and I've installed it on a few machines and never had any problems with it until now.

by **spender** » Sat Apr 19, 2003 8:09 am

Please paste your ACL for /usr/bin/passwd.

-Brad

by **Murphy** » Sat Apr 19, 2003 2:24 pm

I didnt originally have any lines in the ACL file for /usr/bin/passwd because i didnt think i needed them. I never had problems before but I had tried adding these and it didnt change anything:

/etc/.pwd.lock rwx
/usr/bin/passwd rwx

the permissions of /usr/bin/passwd are:
-rws--x--x 1 root bin 33924 Mar 9 21:22 /usr/bin/passwd

by **miha** » Sat Apr 19, 2003 2:40 pm

passwd also writes to /etc/shadow*, so you should have ACLs for that as well.

by **Murphy** » Sat Apr 19, 2003 4:35 pm

I tried adding ACLs for all of those and it doesnt seem to make a difference.

/etc/.pwd.lock rwx
/etc/shadow rwx
/usr/bin/passwd rwx
/etc/passwd rwx

by **spender** » Sat Apr 19, 2003 5:54 pm

Please paste your full ACL for /usr/bin/passwd, and the log messages that you receive after using that ACL.

-Brad

by **TGKx** » Sat Apr 19, 2003 10:41 pm

You should make an initial acl by putting passwd into learn mode...

/usr/bin/passwd lo {
/ h
-CAP_ALL
}

Let it run for a few days then have gradm generate a acl from the logfile.

That will normally put you on the right track, then you can check logs to see what you are missing if there is anything.

by **Murphy** » Mon Apr 21, 2003 5:58 pm

I tried adding the line to put it into learn mode and its still not working. Other then that I dont have an ACL for /usr/bin/passwd but I'm not exactly sure what logfile you're referring to. If it's /proc/sys/kernel/grsecurity/acl, then when I try to cat or edit the file it says denied, even after I do gradm -a. After adding these ACLs it still wont work:

/etc/passwd rwx
/etc/shadow* rwx
/etc/.pwd.lock rwx
/etc/shadow.lock rwx

/usr/bin/passwd lo {
/ h
-CAP_ALL
}

The only error messages I get are sent to TTY1 on the machine and this is the only error message I get when I try to run /usr/bin/passwd as any user:

grsec: From 64.202.110.30: denied link of /etc/shadow.2910 to /etc/shadow.lock by (passwd:2910) UID(0) EUID(0), parent (bash:21417) UID(502) EUID(502)

by **spender** » Mon Apr 21, 2003 6:41 pm

Add /etc rw to the ACL. It should work then. It being denied during learning mode is a bug that will be fixed shortly.

-Brad

by **Murphy** » Tue Apr 22, 2003 1:18 am

Is it safe to set /etc rw? I tried and it wouldn't even let me. It gave me this:

Write access is allowed to /etc, the directory which holds initialization scripts and configuration files.

There were 1 holes found in your ACL configuration. These must be fixed before the ACL system will be allowed to be enabled.

by **hightower** » Tue Apr 22, 2003 3:53 am

Hi Murphy,

Murphy wrote:Is it safe to set /etc rw? I tried and it wouldn't even let me. It gave me this:

Write access is allowed to /etc, the directory which holds initialization scripts and configuration files.

There were 1 holes found in your ACL configuration. These must be fixed before the ACL system will be allowed to be enabled.

Well, able to read?

The answer for "Is it safe to set /etc rw?" is in the gradm output.

"Write access is allowed to /etc, the directory which holds initialization scripts and configuration files."

Use "/etc r" and allow write access after this line if you need write access to some files.

ciao, Marc

by **miha** » Tue Apr 22, 2003 9:42 pm

"grsec: From 64.202.110.30: denied link of /etc/shadow.2910 to /etc/shadow.lock by (passwd:2910) UID(0) EUID(0), parent (bash:21417) UID(502) EUID(502)"

I had the same thing on slackware-9.0
Passwd creates temp. file /etc/shadow.<PID_OF_PASSWD>
I had to enable rw on /etc for passwd to make things work

Question to Brad - is it possible to make such ACL that will work with passwd in described way? We never know what will be the PID of passwd next time you run it.
Default ACL has this - '/dev/tty?? rw', does it mean /dev/tty<ANY_2_LETTERS/DIGITS_HERE>?

Mikhail.