I recently had another interesting conversation with Josh. We always start out having drinks, then one of use (most likely Josh) makes some broad sweeping comments and we spend the next several hours debating the statement. Usually I win. Chris PeBenito (sorry Chris… how’s that for peer pressure to blog?) was there for the beginning but I think he has grown tired of hearing us argue ourselves in circles because, in all seriousness, we are usually both right but we won’t admit it until several more drinks have been served. We finally arrived at an agreement that will be discussed below.

Is SELinux the solution to all security problems?
The answer is a resounding no. We already know that SELinux is capable of meeting the typical information flow security goals (integrity, least privilege, assured pipelines, domain isolation, system hardening, etc), but what about other security goals?
Can SELinux prevent disclosure of information?
SELinux cannot prevent disclosure of data by an exploited application if an information flow already exists. If policy grants a subject access to an object then the subject _always_ has access to that object. If the subject is successfully exploited the application’s domain can be used to gain access to all the resources/objects to which the application had access. Say your application had access to a backend database with a whole bunch of super secret data (say your mom’s recipes). If your application is exploited the attacker will have access to that same data as well and will be cooking up her tortilla soup recipe by the time you find out about the attack.
So does this mean SELinux is worthless?
Absolutely not! You must evaluate your security goals and see if SELinux is the proper solution. The truth of the matter is that domain confinement is capable of meeting the vast majority of security goals and through domain confinement and OS self-protection SELinux is providing the 80% solution.
Are there better alternatives?
Depending on your goals, maybe. But more than likely no there isn’t. AppArmor, LIDS, and gresec are all path based which is broken (for reasons similar to that described in my previous ranting about object tranquility). There are two problems with path-based security: access to a single object can vary depending on how it’s accessed (hardlinks), and access is based on a directory entry, not the object/data itself. Additionally none of these solutions offer fine-grained network controls. PAX and it’s friends offer memory protection — thats it. I’m not going to delve into the ins and outs of each, partly because that would take entirely to much effort at the moment, but mostly because I don’t know the details of each. I’m sure more info will follow though (as we settle down at the bar for a another round of debates).