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/ -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
