Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

From: Pavel Machek
Date: Fri Jun 15 2007 - 16:07:39 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/