No more selinux-policy-*-sources

[Stephen Smalley]

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