Re: New stacker performance results

From: Colin Walters (walters@private)
Date: Wed May 25 2005 - 15:40:40 PDT


On Wed, 2005-05-25 at 17:33 -0400, Valdis.Kletnieks@private wrote:
> On Wed, 25 May 2005 13:20:06 EDT, Colin Walters said:
> 
> > Why would your security policy specify implementation details like
> > chroot?  A more sensible security policy would be something like "BIND
> > cannot affect the PostgreSQL server". 
> 
> You weren't paying attention - I *granted* it was a silly rule. But every once
> in a while, somebody screws up and lets the auditors get access to some 8x11
> color glossy, and once that happens there's no shifting it. ;)

Errr...if your "auditor" specifies that you need "chroot" without
understanding the issues, then just use SELinux, and tell them you're
using "chroot". Moreover, why would you even let your organization be
audited by someone so clueless in the first place?

> The point is that SELinux is able to do a very good job at controlling access
> via a model where everything is *labelled*.  

Yes.  And it provides plenty of tools for labeling; from fine-grained
xattrs on files to giving all files on a particular mount the same
label.  What's the big deal?

> It however does a *very* poor
> job of making decisions based on *state* - are we chrooted? Are we this,
> are we that?

Now that we have SELinux, using chroot for security is obsolete.  There
is one other use of chroot - virtualization.  But we have Xen for that
now.

So what other interesting "state" types are there?

> A good while ago, I was discussing an LSM based on the OpenWall patches, and
> the reasonable security goal of "don't follow a possibly hostile symlink".  

I remember it well.  I had a sense of deja vu when you posted; again you
were focusing on implementation details and not goals.

> In
> order to actually do it, you'd basically have to use the 'strict' policy,
> give each user their own $USER_u - and then you could add the 5-6 lines of
> policy that did the same as a 15-line LSM exit.  Except the SELinux one
> will have chewed up some 20M worth of avc_node slab entries (which makes a
> noticeable difference if you're trying to secure an older box that only has
> 128M or 256M installed).

What you are forgetting is that I provided a solution for the policy
size: use the constraints.  Thomas Bleher even tested it and found it
worked, IIRC.

> And yes, I *KNOW* the Right Answer there is "Use some other LSM that meets the
> goals needed".  

Nope - we showed in that case SELinux did work, and quite elegantly too.

> The point is that there *DO* exist *real world* security issues
> that the SELinux model is not all that well suited for.

Since we've discounted chroot, I'm awaiting more "*real world*"
examples...






This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 15:42:23 PDT