On Mon, 2007-06-04 at 23:03 +0200, Andreas Gruenbacher wrote: > On Tuesday 15 May 2007 11:20, Pavel Machek wrote: > > Hi! > > > > > Pathname matching, transition table loading, profile loading and > > > manipulation. > > > > So we get small interpretter of state machines, and reason we need is > > is 'apparmor is misdesigned and works with paths when it should have > > worked with handles'. > > I assume you mean labels instead of handles. > > AppArmor's design is around paths not labels, and independent of whether or > not you like AppArmor, this design leads to a useful security model distinct > from the SELinux security model (which is useful in its own ways). The > differences between those models cannot be argued away, neither is a subset > of the other, and neither is a misdesign. I would be thankful if you could > stop spreading this lie. I have a hard time distinguishing AppArmor's "model" from its implementation; every time we suggest that one might emulate much of AppArmor's functionality on SELinux (as in SEEdit), someone points to a specific characteristic of the AppArmor implementation that cannot be emulated in this manner. But is that implementation characteristic an actual requirement or just how it happens to have been done to date in AA? And I get the impression that even if we extended SELinux in certain ways to ease such emulation, the AA folks would never be satisfied because the implementation would still differ. Can we separate the desired functionality and actual requirements from the implementation specifics? > > If you solve the 'new file problem', aa becomes subset of selinux. > > And I'm pretty sure patch will be nicer than this. > > You are quite mistaken. 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, - 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. - names are far less tranquil than labels. > So what you advocate for is a hybrid between the SELinux and the AppArmor > model, not a superset. > > It could be that the SELinux folks will solve the issues they are having with > new files using something better than restorecond in the future, perhaps even > an in-kernel mechanism (although I somewhat doubt it). But then again, their > basic model makes sense even without any live file relabeling, and so that's > probably not very high up on the priority list. Live file relabeling (non-tranquility) tends to break one's ability to show anything about preservation of confidentiality or integrity (particularly in the absence of complete revocation support). On the new files issue, it wouldn't be difficult or even a real divergence from our existing model to introduce the component name (not a "full" pathname, but the last component) as an additional input to the decision for labeling new files (along with the existing use of the creating process' label, the parent directory label, and the kind of new file) at creation time, and that would reduce the need somewhat to modify some applications that create files of multiple security contexts in the same directory. That would further help the SEEdit folks in emulating AA on top of SELinux, but as before, I don't get the impression that the AA folks will ever be satisfied with such an emulation, not because of any real requirement but merely because they are tied to their implementation specifics. -- Stephen Smalley National Security Agency - 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
