grsecurity forums

What the heck is going on? I'm getting the same sort of thing from crond where it has access to the file but is erroring saying it cant read the hidden file. It appears some sort of corruption of the table may be going on.

This acl was working fine 36 hours ago, but now its flipping a shitbrick =(

Current version is CVS of both gradm and grsec.

gradm -T /usr/bin/procmail /etc/passwd
Allowed access for /etc/passwd from /usr/bin/procmail:
Read: yes
Write: no
Append: no
Execute: no
Hidden: no
Inherit ACL on exec: no
Read-only ptrace: no
Audit reads: no
Audit writes: no
Audit execs: no
Audit appends: no
Audit finds: no
Audit inherits: no

Apr 18 09:55:25 src@soup grsec: From 161.114.1.207: denied access to hidden file /etc/passwd by (procmail:26499) UID(0) EUID(0), parent (sendmail:9556) UID(0) EUID(0)

/usr/bin/procmail o {
/var/spool/mail rw
/usr/share/zoneinfo/US/Central r
/lib rx
/lib/ld-2.2.5.so x
/etc/passwd r
/etc/nsswitch.conf r
/etc/ld.so.cache r
/etc/group r
/dev/null rw
/dev
/dev/log rw
/usr/bin/procmail x
/usr/local/bin/spamassassin rx
/home rw
/root rw
/bin/bash rx
/ h
-CAP_ALL
+CAP_CHOWN
+CAP_SETGID
+CAP_SETUID
+CAP_SYS_NICE
connect {
127.0.0.1:512 dgram udp
}
bind {
disabled
}
}

/usr/sbin/sendmail o {
/var/tmp
/var/spool/mqueue rw
/var/spool
/var/spool/clientmqueue rw
/var/run/sendmail.pid w
/var/run
/var
/usr/share/zoneinfo/US/Central r
/usr/bin/procmail x
/usr/bin
/usr
/root
/proc/loadavg r
/proc/cpuinfo r
/lib rx
/lib/ld-2.2.5.so x
/home
/etc/mail rw
/etc r
/dev/null rw
/dev/log rw
/usr/sbin/sendmail x
/
-CAP_ALL
+CAP_SETGID
+CAP_SETUID
+CAP_NET_BIND_SERVICE
}

Are you sure you're using current CVS? Current CVS wasn't even compiling between the 16th and today.

If something was a problem, it would have been due to ACL recreation. So, what happens is, when there exists an object, and that object is removed, its entries get tagged as deleted, so it can't be matched by some other file that might crop up while the file is deleted (though this wont happen on most filesystems (ext2/3/reisterfs/xfs), we need to ensure this so that we can work on any filesystem). Then, when the original file is restored by some means, eg.,

mv /tmp/blah /etc/passwd
touch /etc/passwd
mknod /etc/passwd
mkdir /etc/passwd

It checks the real filename, so that this new file gets the previous policy for /etc/passwd. While the updates are done, a write lock is held that prevents any lookups into object/subject tables, thus stopping the possiblity of a race condition immediately after recreation.

I've done some regression tests and debugging on my end to check it, and I've not seen any problems.

Did gradm -R change anything?

-Brad

I believe my version is +-5 days within current. I had tried upgrading to the 16th one and it wouldnt compile so i backrev'd fine to newest stable. It appears to be working fine.

From the version I was having problems with, I had been doing a lot of work with the ACL and permissions at the time. I'm sure I had done a combination of -R's and -D's and was still having the problem. I didnt try rebooting though.

I had also been adding/deleting users which would have been changing/overwriting the /etc/passwd.

Sorry this isnt a lot of help but I was in a rush to get things fixed because people were losing email. Is the cvs working again with gcc? I can do an upgrade late at night and see if i can reproduce the probs I was having.

-TGK

Yes, CVS is actually tagged for 1.9.9g. I'm just waiting on some updates to the gentoo secure acls so I can release it and gradm 1.9.9g together.


-Brad