No more selinux-policy-*-sources
Stephen Smalley
sds at tycho.nsa.gov
Tue Mar 14 17:30:08 UTC 2006
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
More information about the devel
mailing list