On Tue, 2006-03-14 at 12:30 -0500, Stephen Smalley wrote: > On Tue, 2006-03-14 at 17:45 +0100, Arjan van de Ven wrote: > > which is because the policy design seems to keep starting from the wrong > > place. That policy design is aimed for a "strict" policy. Even the so > > called targeted policy tries to work in a strict way. > > > > With this I mean it tries to be too fine grained. Far too fine grained. > > > > But that is easy to say without having to say what it should look like > > then... So maybe something like this: > > > > Create several high level classes for binaries > > > > * CanDoAll: no limitations at all > > (this already exists as unrestricted today) > > * NormalBinary: "modern" normal but simple binary; > > no executable stack, no dlopen allowed, no textrels, > > no writable executable memory > > * NoExec: like "NormalBinary" but doesn't do system/exec to launch > > other applications > > * NoNetworking: like NoExec but application is not doing anything > > network-ish (eg connect/bind/accept etc) > > > > these last 2 classes I bet will cover 95% of /usr/bin already. > > What is more, most of the requirements can be validated at build time > > (just by looking at which glibc functions get called) > > > > You can argue that this doesn't cover the hard cases, like ssh and > > apache. And you know what, that would be right. Apache is just a really > > really complex beast, given that it accepts 3rd party plugins and has a > > near-turing-complete configurability. > > > > To me the later means that any attempt to in detail describe what the > > application is allowed to do for the general population is doomed from > > the start. That leaves 3 options > > 1) Have a policy generator that reads httpd.conf and based on that > > creates the policy > > 2) Give apache very broad permissions > > 3) Work from the other angle, forbid it to do certain bad things. So > > instead of enumerating all the possible things you can do, you enumerate > > the things it cannot do. The traditional argument for MAC is "but you > > can't enumerate all the bad things so lets say what it CAN do". My > > counter argument is that you can't enumerate what it can do either, and > > that telling it obvious things it can't do is at least a step forward. > > > > 1) and 3) are not exclusive. > > Go read: > http://www.ranum.com/security/computer_security/editorials/dumb/ So it seems we disagree some ;-) Lets gets some individual statements out then: 1) It's not feasible to enumerate all the bad things that can happen. I think we both agree on this based on your reaction. 2) For something as complex as apache (extremely configurable and used that way in practice all the time, as well as full of plugins with an active 3rd party plugin ecosystem), it is equally impossible to enumerate all the things it needs to be able to do statically and upfront. At least without ending up with an effective "everything goes" policy which is useless. I'm guessing you don't agree with this. 3) If you try anyway, and a situation you didn't think of happens because the admin configures it that way, the complexity of the policy that resulted is such that the admin no longer has a chance to fix it himself. Even when the admin might fix a simple 5 line policy situation (for example by relabling his new app as "does network" from "does no network"), expecting the admin to fix up a highly complex policy without creating wide open holes is a losing battle. Best case is he disables the lot and realizes he needs to keep his apache highly uptodate. Worst case is he thinks he's safe and never updates. I'm guessing you also don't agree with this. So that leaves a few options: * dynamic policy that adjusts to the configuration this is going to be of the same order of complexity as the configuration options are in the first place. * keep the policy simple but allow more than strictly needed, yet disallow things that are highly out of bound. The parallel to firewalls has been made several times. But in fact the linux firewall does exactly this; the "related" ruleset is a dynamic behavior that allows more than strictly would be needed to be allowed, yet it's an effective way to keep things tight when you know they can be. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
