grsecurity forums

Hi,

After last software update, these messages started to appear in logs:

Code: Select all

Jan  7 13:52:53 local grsec: (root:U:/) denied access to hidden file /dev/initctl by /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0, parent /[swapper:0] uid/euid:0/0 gid/egid:0/0
Jan  7 13:52:53 local grsec: (root:U:/) denied access to hidden file /dev by /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0, parent /[swapper:0] uid/euid:0/0 gid/egid:0/0
Jan  7 13:52:53 local grsec: (root:U:/) denied access to hidden file /dev/initctl by /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0, parent /[swapper:0] uid/euid:0/0 gid/egid:0/0
Jan  7 13:53:01 local grsec: (root:U:/) denied access to hidden file /dev/initctl by /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0, parent /[swapper:0] uid/euid:0/0 gid/egid:0/0
Jan  7 13:53:01 local grsec: (root:U:/) denied access to hidden file /dev by /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0, parent /[swapper:0] uid/euid:0/0 gid/egid:0/0


Subject /sbin/init exists in my ACL, and has permissions to access the device nodes above. But after updating to newer versions, these subjects are completely ignored and all of them are identified as "/" (main subject). Disabling/enabling or reloading grsec will not fix this.

Any way to fix this problem without rebooting? Normally, after update of some software, i need to restart chpax for grsec to accept it and stop writing errors regarding it(reboot helps too here, but it is the worst way)
Unfortunately, it doesn't work for init. Also, how do i create ACL for "swapper"?

Does the subject for /sbin/init exist within the root role?

-Brad

Yes, here it is, just under / (default) subject:

Code: Select all

subject /sbin/init op {
/ h
/bin rx
/dev r
/dev/console rw
/dev/grsec h
/dev/initctl rw
/dev/kmem h
/dev/log rw
/dev/mem h
/dev/port h
/etc/localtime r
/lib64/ld-2.3.6.so rx
/sbin rx
/sbin/agetty rx
/usr/bin rx
/usr/lib64 rx
/usr/sbin rx
/usr/share/zoneinfo r
/var/run/utmp rw
/var/log/wtmp rw
-CAP_ALL
bind disabled
connect disabled
}

Note: this error doesn't appear since i rebooted so i assume grsec is doing some checksums of binaries and this checksum is remembered while the process is running regardless whether grsec acl system is on or off. When the process attemts to access an object, this checksum is compared to the new one generated from binary file (so updating init to new version caused a mismatch - new binary vs. old running process). As these checksums differ, subject /sbin/init was not treated as the one belonging to the process(running older version of init). Here is another example: httpd process is also treated as "/"(so giving similar errors) after update unless i do [stop grsec -> chpax restart -> httpd restart -> start grsec]. This wasn't a problem as i always restarted any daemon after its update, but it is clear that it will be not so easy for init in HA production environment.

Are you using the latest test patch? This problem could have occurred in earlier versions but should be fixed in the latest. It involves subject/object recreation if binaries are updated in a particular way.

-Brad

I admit I used quite old version on kernel 2.6.16, refusing to upgrade because some unusual netfilter modules are unavailable on newer. Luckily, I was able to rewrite them so now I will move to newer kernel with latest grsec patch. I'll try it and see what's new.