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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070615211157.GB7337@kroah.com>
Date:	Fri, 15 Jun 2007 14:11:57 -0700
From:	Greg KH <greg@...ah.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Crispin Cowan <crispin@...ell.com>,
	Andreas Gruenbacher <agruen@...e.de>,
	Stephen Smalley <sds@...ho.nsa.gov>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,
	pathname matching

On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> Hi!
> 
> And before you scream "races", take a look. It does not actually add
> them:

Hey, I never screamed that at all, in fact, I completly agree with you
:)

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

>From my limited knowledge of SELinux, this is the default today so this
would happen by default.  Anyone with more SELinux experience want to
verify or fix my understanding of this?

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

Agreed.

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

Agreed.

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

Exactly.

I can't think of a "real world" use of moving directory trees around
that this would come up in as a problem.  Maybe a source code control
system might have this issue for the server, but in a second or two
everything would be working again as the new files would be relabled
correctly.

Can anyone else see a problem with this that I'm just being foolish and
missing?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/