On Sunday, November 28, 2010 05:40:41 pm brett mm wrote: > In reality, I am not at all sure that a quantum leap in complexity > adds to security at all. Any proper use of old-school group > permissions can give as finely-grained a security policy as you would > like. No, it won't. Suppose I'm running CentOS on a workstation, and have a need to access a corporate webapp written in Flash, read corporate documents in PDF, and use other applications written in Java. So I'm going to be living in my browser for most things corporate. How can I prevent a compromised PDF from gaining an attacker access to my entire home directory? More to the point, how to I prevent that PDF from gaining WRITE access to files in my home directory (say, .bashrc for instance)? With SELinux I can set files and whole hierachies to not allow Acrobat Reader access of various types, while still alllowing access to those areas it needs. Voila! Acrobat Reader vulnerabilities and the PDF's that exploit them no longer have any power to exploit my system. Same with Flash, Java, and Firefox itself. If firefox has no need to write into my Documents directory, then I can lock out my Documents directory to firefox (even when it's running with the right uid:gid that would defeat old-school uid:gid based perms) and not worry about a malicious website exploiting a firefox zero-day modifying any of my files in Documents. Old-school permissions are user and group ID based; mandatory access controls are not. They can be process-based and file-based (and socket-based, too). They give you the ability to make root not able to touch every file, for instance, unless the process has the right security context (even making it possible to put /usr/bin, /bin, /lib, /usr/lib, the kernel, etc, off-limits for overwriting by root unless the controlling process is in the right security context). SELinux controls can prevent botnet worms from opening network ports for listening; or even for outgoing access. On a stable server, where the configuration is production-ready, it shouldn't be hard to determine a normal security footprint to write policy to; lock down the security contexts and the number of successful exploits will go down. What needs to improve are the admin tools to make those sorts of decisions easy. While the selinux configuration tool in Fedora (and thus RHEL as it gets the improvements backported) has improved, it can stand more improvement. Yes, this sort of thing adds a little complexity (like, for instance, when you want to change ssh to listen to a non-default port; you need to remember three configuration steps: 1.) sshd needs to listen there; 2.) iptables needs to allow the incoming; 3.) and selinux policy needs to allow sshd to bind the port for listening. Previous selinux configuration tools didn't make 3.) as easy as it could be; current Fedora tools at least make it as easy as steps 1 and 2. On the server side, suppose you're running Plone and Moodle together, and have some integration. You'll want to profile the security footprint, write the policy to it, and implement. If the proper selinux procedures are followed it will survive updates and relabels just fine, and when Moodle and Plone exploits are found, they will prevent remote privilege escalation. Or, in other words: follow the various mailing lists to see what the most common exploits are actually out there in the wild; then analyze those to see if the old-school techniques would prevent them without convoluted and massive groups. In the Plone instance a PDF exploit might even be something to guard against, since Plone content types for automatic insertion of content from various upload forms is supported. Ie, check to see what's happening in the real world of 2010, not the real world of 1980.