I agree that the in-kernel implementation could use different abstractions
than user-space, provided that the underlying implementation details can be
hidden well enough. The key phrase here is "if possible", and in fact "if
possible" is much too strong: very many things in software are possible,
including user-space drives and a stable kernel module ABI. Some things make
sense; others are genuinely bad ideas while still possible.
The things in my reply you chose not to quote make up the essential part of
the model, argue why mapping from an AppArmor-like user-space to a
label-based in-kernel model is fundamentally hard, how implementation details
cannot be hidden, and how such a mapping would lead to disadvantages no
matter which way you look at it.
I did not pull all of this out of my hat ad hoc. The AppArmor team spent a
fair amount of time researching various ways how AppArmor-like semantics
could be implemented on top of SELinux, as well as ways how AppArmor could be
implemented better. We *really* tried hard. The reason why we are still
proposing this non-SELinux approach is because none of the alternatives
worked out.
If things were as simple as mapping an AppArmor frontend to the SELinux
backend, even with extensions to the SELinux backend (and I know that it
wouldn't be impossible to extend SELinux in reasonable ways), this would
indeed be nice. The issues that SEEdit is having unfortunately only confirm
what we were already certain to know: it just doesn't work.
There is no need to start all over implementing something from scratch. People
have already tried emulating AppArmor on top of SELinux, and SEEdit is the
current best result. All it takes is the time to understand the SELinux and
AppArmor models. From there it is not hard to see that SEEdit does the best
it can do, and how it is just not a good idea. There are a few things that
could be improved with additional SELinux in-kernel infrastructure, but the
fundamental problems remain. It just remains a very bad idea.
We wrote an AppArmor technical documentation, and it was posted as part of the
last two AppArmor submissions. It describes the model, and how the model is
implemented. If you need a better description of the model, let us know how
we can improve it.
http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
What you'll not find in there is a detailed comparison between AppArmor and
SELinux, and the problems that emulating AppArmor on top of SELinux would
cause -- some details on that can be found in the SEEdit documentation, and
in addition, this LKML thread seems best to me at the moment.
Andreas
-
