First SELinux impressions [LWN.net]

First SELinux impressions

Posted Apr 8, 2004 17:49 UTC (Thu) by dac (guest, #9260)
In reply to: First SELinux impressions by sward
Parent article: First SELinux impressions

The complexity is a direct result of Linux being complex. There are over 30 object classes (e.g., files, dirs, sockets, etc.) with each one having some subset of the over 120 possible permissions. There is certainly a trade off in providing a system with the granularity to control every single permission for every object class.

SE Linux does not "leave gaping holes" no matter how misconfigured. An SE Linux policy that is wide open and allows all processes access to all objects is no worse than that system would be without SE Linux.

I think the immediate impact it can have on hardening a server is a big benefit. I agree with you somewhat from the perspective of desktop users trying to get a handle on the complexities.

to post comments

First SELinux impressions

Posted Apr 8, 2004 21:01 UTC (Thu) by sward (guest, #6416) [Link]

I'll grant that the "gaping holes" comment was a little over the top, but if you are trusting the system with data that needed that additional protection, and you think that you have hardened it, but have actually misconfigured it in some non-obvious fashion - then you are worse off than if you knew that it could not be trusted with the data.

I'm sure that SELinux will be a great benefit in some areas, but the complexity (necessary as it is) still concerns me. Both from a configuration standpoint (though again, good defaults could go a long way), and from a code-complexity standpoint (more complex code being prone to more bugs).

First SELinux impressions

Posted Apr 12, 2004 15:48 UTC (Mon) by elanthis (guest, #6227) [Link] (1 responses)

The problem is that it's too hard to manage those security attributes. A much better configuration system could hide most of that complexity. Similar to how a desktop like GNOME or KDE hides much of the underlying UNIX complexity. If all I want to do is say that /usr/sbin/apache can't access anything outside of /svr/www, I should be able to say that and have it work. Yes, that would mean a new configuration file format and a much more intelligent "compiler" than m4, but that's what is needed. Imagine being able to open up /etc/security/access.d/apache and putting in:

binary /usr/sbin/apache {
path / deny all
path /etc/apache allow read
path /svr/www/html allow read
path /svr/www/cgi-bin allow read
path /svr/www/tmp allow read,write
}
binary /usr/sbin/apacheconf {
path / deny all
path /etc/apache allow read,write
}

That would generate automatically any domains/types needed, tag files, etc. Very simple configuration input, very easy to read, easy to understand, etc. If you need more than "read" and "write" support, just say so. "read" may well just be a meta-privilege that is an alias for several lower-level capabilities.

First SELinux impressions

Posted Apr 17, 2004 3:25 UTC (Sat) by dotpeople (guest, #20635) [Link]

What happened with the SE Linux patent dispute from a while back?

Have you tried LIDS? It supports a configuration syntax similar to your suggestion.

LIDS + grsecurity (minus the ACL features, which overlap with LIDS) is competitive with SE Linux. Especially in the usability (and therefore practical security) arena. At the least, it's a good sandbox to learn about isolation.

The combination will work in a live linux CD for firewalls, etc.

--
Rich Persaud