On Wednesday 06 June 2007 15:26, Stephen Smalley wrote: > On Mon, 2007-06-04 at 23:03 +0200, Andreas Gruenbacher wrote: > > [...] SELinux turns pathnames into labels when it > > initially labels all files (when a policy is rolled out), whereas > > AppArmor computes the "label" of each file when a file is opened. The two > > models start to diverge as soon as files are renamed: in SELinux, labels > > stick with the files. In AppArmor, "labels" stick with the names. > > I'd argue a bit with that characterization, given that: > - in the case of SELinux, the pathname is never used as a basis for > decisions by the kernel, 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. > - under AA, each file may have an arbitrary set of "labels" or > "policies" applied to it depending on what programs are accessing it and > what names are being used to reference it - there is no system view of > the subjects and objects and thus no way to identify the overall system > policy for a given file. 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. > - names are far less tranquil than labels. 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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
