2.4.18 +grsec (high security) + acl cause segfault :/

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

2.4.18 +grsec (high security) + acl cause segfault :/

Postby Sea-you » Thu Apr 11, 2002 12:57 pm

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
Sea-you
 
Posts: 10
Joined: Thu Apr 11, 2002 12:48 pm

logs?

Postby michaeld » Fri Apr 12, 2002 2:09 am

Can you supply us with the logs from one of your segmentation faults?
michaeld
 
Posts: 37
Joined: Mon Feb 25, 2002 12:32 am

Logs :)

Postby Sea-you » Fri Apr 12, 2002 10:49 am

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
Sea-you
 
Posts: 10
Joined: Thu Apr 11, 2002 12:48 pm

Just a guess

Postby michaeld » Sat Apr 13, 2002 4:31 am

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
michaeld
 
Posts: 37
Joined: Mon Feb 25, 2002 12:32 am

Postby Sea-you » Mon Apr 15, 2002 10:43 am

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 ? :)
Sea-you
 
Posts: 10
Joined: Thu Apr 11, 2002 12:48 pm

Work around....

Postby mwimer » Thu May 02, 2002 2:50 pm

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
mwimer
 
Posts: 13
Joined: Mon Mar 04, 2002 1:54 pm

wtf

Postby michaeld » Thu May 02, 2002 8:39 pm

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
 
Posts: 37
Joined: Mon Feb 25, 2002 12:32 am

re: wtf

Postby mwimer » Thu May 02, 2002 8:56 pm

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
mwimer
 
Posts: 13
Joined: Mon Mar 04, 2002 1:54 pm

hmm

Postby michaeld » Sat May 04, 2002 1:45 am

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
michaeld
 
Posts: 37
Joined: Mon Feb 25, 2002 12:32 am


Return to grsecurity support