Messages in this thread | | | Date | Fri, 15 Jun 2007 22:06:23 +0200 | From | Pavel Machek <> | Subject | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
| |
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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |