Messages in this thread | | | Date | Mon, 24 Apr 2006 16:08:31 +0200 | From | Olivier Galibert <> | Subject | Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks) |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |