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

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


And before you scream "races", take a look. It does not actually add

> > > 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

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".

(cesky, pictures)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at