On Wednesday 06 June 2007 15:26, Stephen Smalley wrote:
Indeed, the kernel component of SELinux only uses file labels for making file
access decisions and not pathnames. But those labels were initially created
by a trusted process (e.g. restorecon) based on pathnames, and this initial
labeling is an essential part of the SELinux model. So in a sense,
disregarding creation and relabeling of files, one could argue that SELinux
makes decisions based on the pathnames that files had when they were labeled.
In SELinux, labels are the only thing that distinguishes between files. So if
at one point you find that you need to distinguish between files that share a
label, you have to split the label and reclassify the files in addition to
adjusting the policy. Again, the usual approach for reclassifying files will
probably be pathname based.
In contrast, AppArmor does not use labels, and the pathnames at the time of
access distinguish between files. Since files do not have labels, no
relabeling is necessary in order to change policy.
Look at it this way: under SELinux, the set of files that share a label forms
an equivalence class -- they are all treated identically by the system's
security policy. The rules in AppArmor profiles also define equivalence
classes in the sense that they partition the filesystem namespace into sets
of files that are treated identically, but this classification is not
explicit -- the entire rule base contributes to the classification. This
doesn't mean that there is not a global policy, just that the policy is
modeled differently. The equivalence classes are not directly obvious from
the AA profiles.
Contrast this with SEEdit, which compiles AA-style rules into labels (and thus
equivalence classes). The resulting SELinux policy is a static snapshot that
cannot easily accommodate rule base changes, is more limited with respect to
new files (which would likely be fixable), and behaves differently in complex
ways with file renames. What's more, most likely the compiled policy will be
anywhere from very hard to impossible to analyze, so you pretty much lose on
all ends.
I'm not saying that labels are crap and that SELinux is wrong. In fact, labels
are useful for some things like model verification and information flow
analysis. What I'm saying is that AppArmor and SELinux implement different
models, and those models cannot be modeled in terms of each other.
Note that I'm not embarking on implementation aspects here at all, only on the
fundamental model differences.
If I'm getting things right, a tranquil system with respect to labels would be
one that does not permit re-labeling, while a tranquil system with respect to
path names would be one that does not permit renaming. Both approaches would
buy greater analyzability with reduced usability, and both seem unrealistic
to me. SELinux and AppArmor evidently have different goals, and tranquility
is more important to SELinux.
AppArmor is meant to be relatively easy to understand, manage, and customize,
and introducing a labels layer wouldn't help these goals. SELinux is
applicable in areas where AppArmor is not (e.g., MLS), but this comes at a
cost. For me the question is not SELinux or AppArmor, but if AppArmor's
security model is a good solution in common scenarios. In my opinion,
AppArmor is a better answer than SELinux in a number of scenarios. This gives
it value, nonwithstanding the fact that SELinux can be taken further.
Thanks,
Andreas
-
