grsecurity forums

Hello ;)

I compiled a new 2.4.18 kernel together with high security option enabled under grsecurity, everything was succesful until I enabled the ACL. Now everything causes segfault :/ What should be the problem ? :)

proc.acl:

/usr/sbin/sshd {
+CAP_NET_BIND_SERVICE
/dev/tty row
/ rwx
/var/log/lastlog rwo
/dev/ptmx xrow
/etc/shadow ro
/dev/pts row
}

/usr/bin/ssh {
/ rwx
+CAP_NET_BIND_SERVICE
}

/bin/su {
/ rwx
/etc/shadow ro
}

/bin/login {
/ rwx
/etc/shadow ro
/var/log/lastlog rwo
}

/etc/rc.d/init.d/halt vk {
/ rwx
+CAP_SYS_ADMIN
+CAP_SYS_RAWIO
+CAP_NET_ADMIN
}
/etc/rc.d/rc vk {
/ rwx
+CAP_SYS_ADMIN
+CAP_NET_ADMIN
}

/usr/lib/postfix/master {
/ rwx
+CAP_NET_BIND_SERVICE
}

/usr/bin/passwd {
/ rwx
/etc/shadow rwo
}

file.acl:

/ rwx
/etc/rc.d rx
/etc/passwd r
/etc/shadow r
/var/log/wtmp rw
/var/log rw
/var/log/httpd wr
/tmp rw
/etc/grsec hr
/boot r
/lib rx
/usr rx
/usr/src rwx
/etc/lilo.conf r
/bin rx
/sbin rx

Can you supply us with the logs from one of your segmentation faults?

Thanks for your help Here are the logs:

nero:~# ps
grsec: attempt to mmap 40238 769 executableby (ps:19059) UID(0) EUID(0), parent (bash:21672) UID(0) EUID (0)
grsec: more mmap exec attempts, logging disabled for 30 seconds
grsec: signal 11 sent to (ps:19059) UID(0) EUID (0), parent (bash:21672) UID(0) EUID (0)
Segmentation Fault

Would the file associated with that inode(the first of the two numbers) happen to be the inode of the file itself?
You can ls -ali to see a file's inode or find / -inum <num>
to find the pathname of the file associated with inode <num>.
Thanks

Michael

Hello, im not sure if I get you right Here it is:

nero:/home/seayou# ls -ali /bin/ps
40238 -rwxr-xr-x 1 root root 58412 Oct 27 23:27 /bin/ps

so the inode is 40238 as you should see at the log files. Any idea ?

Well, guys the boys here at Cylant have found a work around to this problem. It's not pretty but it does make it so that the acls work.

In kernel/gracl.c
<pre>

else if(gr_status & GR_1ST)
{
if(grsecurity_init() || grsecurity_reload())
error = -EINVAL;
security_alert("Loaded %s","loaded "
"grsecurity",GR_VERSION);
gr_status &= ~GR_1ST;
gr_status |= GR_READY;
break;
}
</pre>

Notice the additional "|| grsecurity_reload()."

We also had to add the grsecurity_reload () in the other else clause.
<pre>
if(grsecurity_reload())
error = -EINVAL;
security_alert("%.32s already loaded, re-enabling","",GR_VERSION);

</pre>

This for some reason fixes the memmap bug causing our programs to crash. From what we are seeing, it is quite unexplainable why this actually helps.

You can also do a gradm -R at boot up if you don't want to change the kernel code. I hope that helps you. Sorry it took so long to get back to you but it did take us some time to issolate this bug and come up with a work around. Because we are uncertain why this works for us, you milage my vary.


Another other problem, thought, is the kernel still crashes in fs_may_remount_ro () function. If spender or michael want to take a look at why the kernel crashes in this function at reboot time we might be able to figure out what is really causing these bugs.


-matt wimer

Not sure why that fix cylant was works. Rather than
find out, I'm just going to make sure that this isn't
present in 1.9.5. So everyone, either implement my solution
,add the binary itself as mode rx in its own acl :

/bin/foo {
...
/bin/foo rx
..
}

OR wait for 1.9.5, which will not require you to do this
any longer, as well as providing a number of enhancements,
and config file examination to show you any errors you have.

michaeld,

We tried that here at cylant, but that didn't actually fix the bug.

doing a reload was the only thing that actually fixed it.

--matt wimer

contact me on aim or e-mail about this. 1.9.5 will resolve
this regardless, it has a couple of fixes for 1.9.4 that
may have caused this problem. Would you guys be interested
in testing the fixes and seeing if that helps? My AIM and such is in my profile. Later