grsecurity forums

OK, I'm a very much newby. I compiled and patched a 2.4.27 kernel and gave it the grsecurity options otlined in the starters guide, but when it came time to use gradm it could not open /dev/grsec. So I thought maybe I'd go back to my tried and trued 2.4.26 with the addition of the grsecurity patch-just to get the same results. Gradm seems to compile just fine. /dev/grsec is physically there and at 0622. I looked at the Makefile and manually did a 'mknod -m 0622 /dev/grsec c 1 12' even though the gradm compilation didn't error and made it for me.

The reason for all of this is that I WAS hacked and they came in through mldonkey in a CHROOT jail. This kernel is going in a IPFROG/IPCOP firewall that has a web interface. Grsecurity "breaks" the listing of running processes and modules loaded on the 'information' page-although I can manually get them as root. I would like to try and "fix" this.... If I CAN'T get gradm to work I would at least like to keep some of the security stuff especially the CHROOT jail restrictions. If I were to do this what do I need to lighten up on in the grsecurity part of things in the kernel compilation-without completely giving up on grsecurity entirely. Any help/ideas would be appreciated.

The problem is the proc restrictions; you need to either disable them, or more securely, set a special group which is allowed to view proc and add the user that your CGI runs as to that group.

I took the former approach and all works well. I never could get MIRROR and TARPIT targets to show in the 2.4.27 (yes they patched in and experimental code support was turned on but they simply wouldn't show in the IPTABLES kernel options...I had lots of other probs w/2.4.27!). But 2.4.26 works great. Someday I may try to do it right. But I am a newb.

Aug 19 16:10:13 Sievette kernel: grsec: From 10.1.1.12: exec of /sbin/lsmod (/sbin/lsmod ) by /home/httpd/cgi-bin/status.cgi[status.cgi:19315] uid/euid:99/99 gid/egid:99/99, parent /home/httpd/cgi-bin/status.cgi[status.cgi:5763] uid/euid:99/99 gid/egid:99/99

(I turned on exec logging-for now)...If I changed GID for special group to 99, would that be acceptable?

Yes, that would work. 99 is probably the apache or www-data group, whichever user your web server runs as, so be aware that the web server and all CGI scripts it launches will be able to see into /proc. This may or may not be a problem depending on whether you allow user cgi and on what your security goals are.