Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Olivier Galibert]

On Mon, Apr 24, 2006 at 02:54:10PM +0200, Arjan van de Ven wrote:
> 
> > While that may be true[1], it gets a little annoying when broken is
> > meant to be synonymous to "not the SELinux model".  Especially since
> > there are aspects where SELinux' security can be considered broken,
> > complexity being one of them, crappy failure modes being another,
> > handling of new files a third, handling of namespaces a fourth.
> 
> while I agree with the first three arguments, handling of namespaces
> isn't  fundamental SELinux weakness.

I'm not sure.  It's linked to the "new files" problem.
Object-labelling security (be it inodes, attributes, whatever) are
good to protect specific objects, but it sucks on two points:
- new objects can have an incorrect by-default labels
- applications don't address objects directly, but by one of their
  names, the paths

Path-based security does not protect objects, it protects what you
access through the names, whether there are associated objects or not.
So in practice path security protects the behaviour of applications
against mucking with the filesystem, while object labelling protects
the contents of the files.  They're complementary, they need each
other in practice.


> Maybe the question "is the fragility worth it" is a religious question,
> but the fundamental truth is that an inodes approach is by far more
> robust and beyond such "nothing else" statement.

It's more robust at protecting objects contents, it's less robust at
protecting application behaviour.  A lot like GR and QM, the best
model is somewhere in the middle :-)


> Now that there's a second proposed user, the real evaluation of the
> value of LSM can be made in this regard, and if the consensus is that
> it's fixable, the interfaces can be cleaned up to facilitate both
> SELinux and AppArmor. But I don't think you can a priori say that LSM is
> the right answer, given that AppArmor seems to highly struggle with it,
> nor do I think it HAS to be. I rather have separate interfaces for
> AppArmor and SELinux than one, bad, joint interface that everyone hates.

Heh, now I can agree with that.  I'm a lot more annoyed by the
arguments (not by you in particular) that go more or less:
- LSM should be removed because only SELinux uses it
- Any LSM users that is not SELinux is either broken or should be
  implemented as SELinux policies

For now if I follow correctly the LSM interfaces are decent for
object-based policy implementations, and not decent for path-based
ones.  Maybe the object-based policy hooks should be evolving in the
direction of SELinux' comfort, and additional hooks specifically for
path-based policy added, probably along the lines of what AppArmor
needs.  Then hopefully someday someone will build a security system
that uses the best features from both.  But refusing path-based policy
in the kernel for religious reasons would be annoying.

  OG.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/