> > I'm over-simplifying, but the main source of complexity in the current > SELinux environment is its comprehensive nature. None of the security > models currently used in SELinux is particularly complex. The MLS > security model is counter-intuitive, but it's also not currently used > ;-P As it stands, the confusing areas of SELinux itself mostly reside > at the intersection between the different models (i.e. how DAC identity > and SELinux identity interact, how roles and types relate, etc.) and > with the myriad of object classes and associated permissions. 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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
