Hi! And before you scream "races", take a look. It does not actually add them: > > > 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. > > > > > In particular, to layer AppArmor on top of SELinux, the following > > problems must be addressed: > > > > * New files: when a file is created, it is labeled according to the > > type of the creating process and the type of the parent directory. > > Applications can also use libselinux to use application logic to > > relabel the file, but that is not 'mandatory' policy, and fails in > > cases like cp and mv. AppArmor lets you create a policy that e..g > > says "/home/*/.plan r" to permit fingerd to read everyone's .plan > > file, should it ever exist, and you cannot emulate that with SELinux. > > A daemon using inotify can "instantly"[1] detect this and label the file > properly if it shows up. Or just create the files with restrictive labels by default. That way you "fail closed". > > * Renamed Files: Renaming a file changes the policy with respect to > > that file in AA. To emulate this in SELinux, you would have to > > have a way to instantly re-label the file upon rename. > > Same daemon can do the re-label. ...and no, race there is not important. Attacker may have opened the file under old name and is keeping open file descriptor. So this does not add a new race relative to AA. > > * Renamed Directory trees: The above problem is compounded with > > directory trees. Changing the name at the top of a large, bushy > > tree can require instant relabeling of millions of files. > > Same daemon can do this. And yes, it might take a ammount of time, but > the times that this happens in "real-life" on a "production" server is > quite small, if at all. And now, if you move a tree, there will be old labels for a while. But this does not matter, because attacker could be keeping file descriptors. Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay. Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that "when madly moving trees we sometimes construct path file never ever had". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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
