Hi!

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

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

quoted text
> >     * 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.

quoted text
> >     * 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-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html