No more selinux-policy-*-sources

[Arjan van de Ven]

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.