grsecurity forums

Well troops, while some lazy bums were out boozing it up over spring break I was working hard on the acl autogernation code. What i have is a first pass.

Firstly, here are the file.acl and proc.acl files that i started with.


/ rwx
/etc r
/etc/rc.d rx
/etc/passwd r
/etc/shadow r
/var/log/wtmp rw
/var/log ar
/tmp rw
/etc/grsec hr
/boot r
/lib rx
/usr rx
/etc/lilo.conf r
/bin rx
/sbin rx
/dev r
/dev/null rw
/dev/zero rw

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

/usr/sbin/sshd {
/ rwx
/etc/shadow ro
/var/log/lastlog rwo
+CAP_NET_BIND_SERVICE
}

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

/usr/bin/sudo {
/ rwx
/etc/shadow ro
}

/usr/bin/passwd {
/ rwx
/etc/shadow 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
}


And after about a week of running in "access collection" mode (basically watching all the access) my Quasimoto perl code was able to generate this set of acls:

/etc/grsec hr
/boot r
/etc/rc.d rx
/etc r
/etc/lilo.conf r
/etc/passwd r
/etc/ld.so.cache xr
/sbin rx
/etc/shadow r
/bin rx
/dev/null rw
/var/log ar
/tmp rw
/dev/tty rw
/ rwx
/dev r
/var/log/wtmp rw
/dev/zero rw
/lib rx
/usr rx

/usr/sbin/vipw {
/ rwx
/etc row
}

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

/usr/bin/sudo {
/ rwx
/etc/shadow ro
}

/usr/sbin/logrotate {
/ rwx
/var/log ow
}

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

/bin/view {
/ rwx
/etc/.ptmp.swp row
/etc/.ptmp.swpx row
}

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

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

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

/usr/lib/gcc-lib/i386-redhat-linux/2.96/cpp0 {
/ rwx
/tmp/vmware-config0/vmmon-only xo
}

/bin/sed {
/ rwx
/etc/sysconfig/i18n xro
}
/bin/rm {
/ rwx
/var/log/sa ow
}

/bin/ps {
/ rwx
/boot/System.map-2.4.9-grsec-1.9.4 xro
}

/sbin/ldconfig {
/etc/ld.so.cache~ row
/ rwx
/etc row
}

/usr/bin/vmware-config.pl {
/ rwx
/etc/vmware/locations roa
}

/usr/bin/run-parts {
/ rwx
/etc xro
}

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


In summary, the proc.acl file was bloated the most with simple things like sed being able to access i18n files. But file.acl was only lengthened by /dev/tty and /etc/ld.conf.so.cache.

Just a suggestion guys:

while putting / rwx in a process acl is not the worst thing ever, it would be better to list all the files the program
accesses and be as specific as possible.

If you give a process rwx access to / it can r/w/x
any file, save those protected by file acls (because,
citing acl documentation, only processes with the (o)verride
mode specified in their acl can override file acls).

So it would be more secure if you limited it to those files
that it must access, rather than /, just in case your
file acls do not adequately protect every single file.
Also why the rwx? Why not rw. If you allow it to execute
anything, it could execute a program for which no acl
is associated, causing that program to be limited only
by file acls. Again, with good file acls this would not
represent a breach of security, but paranoia is always
good:). Be sure to let me know what you guys think. Also,
does anyone have any ideas on how to simplify acl creation,
I'd love to hear them. I think the system could use
simplification, just not at the cost of its robust
feature set. Later

Michael

Michael,

Everything you say is correct. Given the difficulty of acl autogeneration--its a balancing act involving a tight rope, polar bears and goloshes--the current gracld calibration code is simplified by the / rwx so that i can wrap my mind around the problem. In the future the calibration should be able to create a more restrictive cage around software, unlike the current algorithm which starts with a restrictive ruleset and grows the playground for any software that would fail if it had to execute within the original list of access controls.

And, unfortunatly i have a deadline that i have to meet for the middle of this month. After that i will be able to work through some higher powered algorithms that should be able to accomplish the goals you have laid out.

Michael, on a side note, i have been reworking gradm to control the kernel as well as control gracld. I would like gradm to check the password before sending commands to gracld and before letting the user run the do_setup() code if the system is currently enabled. With that the case, i will need to determine, securely, if the system is enabled. How would i do that?

Well..you could test to see if something failed an acl
check or try init mode and see if it succeeds/fails.
Hmmm...you know what, adding a "status" option wouldn't
be a bad idea at all, I think I'll add that in 1.9.5.

Well, i found my bug, the evil vile bug that caused my kernel to crash like a drunk fratbrat on a firday night drinking binge at a kegger. It was in my hardware. It seems that my machine, lovingly named Lard, had severe braindamage. So i suspect, based on its creative math--its not wrong for top to display 45393.67% idle, just very curious--i will have to have to put it down.

My packaging guy, bbassett.net of debian fortune fame, is currently working on making a release of the gracld code base as well as redhat packages. Our redhat kernel with KIP(kip.sf.net, for those interested in instrumentation) and grsecurity should be available shortly, i'm still waiting to hear back from imsure about his patch, but even if it isn't ready for release i have my patch which is very close to being perfect (whatever.)

Btw, anyone that missed me ranting and frothing at the mouth over my "bug" let me make it perfectly clear that nothing can be as frusterating as a hardware bug crashing the kernel, so always be sure to check your hardware if you run into problems that cannot be explained any other way.

Lastly, i hate you all, love,
Matt

Hello again guys. Gracld is late by a few days, go figure. The reason is we are experiencing some difficulties with our autogened acls.

When we login at the console we get a crash in the prune_dcache () function. This is with the 1.9.4-2.4.18 kernel with the d_path () bug in sched.h removed. Also, this is NOT our redhat port.


Here are the acls for you guys to look at.

file.acl

/boot r
/bin rx
/etc/ld.so.cache rx
/usr rx
/dev/tty rw
/dev/tty1 rw
/etc/passwd r
/etc r
/lib rx
/etc/rc.d rx
/tmp rw
/sbin rx
/ rwx
/var/log/wtmp rw
/etc/grsec rh
/var/log ra
/etc/lilo.conf r
/dev/zero rw
/var/www r
/dev r
/etc/shadow r
/dev/null rw



proc.acl


/bin/bash {
/etc rxo
/var/www/html/last300.txt rxo
/var/www/html/banned.txt rxo
/usr/local/etc/tmp rxo
/ rwx
}

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

/bin/ps {
/boot/System.map-2.4.9-gr1.9.4-cs1.2.3 rxo
/ rwx
}

/bin/rm {
/usr/local/etc/tmp rxo
/ rwx
}

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

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

/usr/sbin/httpd {
/var/www/html rxo
/var/log/httpd rxo
/ rwx
}

/sbin/gracld p {
/dev/grsec rwo
/etc/grsec rwxho
/ rwx
}

/usr/sbin/watcher pkv {
/etc rxo
/ rwx
}

/usr/sbin/watcher-guard k {
/ rwx
}

/usr/local/bin/logtail {
/var/log rxo
/ rwx
}

/usr/bin/sudo {
/etc/shadow ro
/ rwx
}

/usr/sbin/logrotate {
/var/log/pacct rxo
/ rwx
}

/bin/gzip {
/var/log/pacct.1.gz rxo
/var/log/pacct.1 rxo
/ rwx
}

/etc/cron.daily/rpm {
/var/log/rpmpkgs ro
/ rwx
}

/etc/rc.d/rc kv {
/ rwx
+CAP_SYS_ADMIN
+CAP_NET_ADMIN
}

/bin/sed {
/tmp/makewhatistMJbOL/w rxo
/ rwx
}

/usr/sbin/sshd {
/etc/shadow ro
/var/log/lastlog rwo
/dev/ptmx rxo
/dev/pts/1 rxo
/ rwx
+CAP_NET_BIND_SERVICE
}

/sbin/gradm kv {
/etc/grsec rwxho
/ rwx
}

/usr/bin/perl {
/etc/mrtg rxo
/ rwx
}

/sbin/init {
/dev/console rxo
/ rwx
}

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

/usr/sbin/sendmail {
/etc/mail/statistics rxo
/ rwx
}