Message-Id: <1182523778.24664.125.camel@moss-spartans.epoch.ncsc.mil>
Date:	Fri, 22 Jun 2007 10:49:38 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Lars Marowsky-Bree <lmb@...e.de>
Cc:	James Morris <jmorris@...ei.org>, Pavel Machek <pavel@....cz>,
	Crispin Cowan <crispin@...ell.com>, Greg KH <greg@...ah.com>,
	Andreas Gruenbacher <agruen@...e.de>, 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, 2007-06-22 at 09:22 -0400, Stephen Smalley wrote:
> On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote:
> > On 2007-06-22T08:41:51, Stephen Smalley <sds@...ho.nsa.gov> wrote:
> > > Sorry, do you mean the "server" as in the "server system" or as in the
> > > "server daemon"?  For the former, I'd agree - we would want SELinux
> > > policy applied on the server as well as the client to ensure that the
> > > data is being protected consistently throughout and that the server is
> > > not misrepresenting the security guarantees expected by the clients.
> > > Providing an illusion of confinement on each client without any
> > > corresponding protection on the server system would be very prone to
> > > bypass.  For the latter, the kernel can only truly confine application
> > > code, not in-kernel threads, although we can subject the in-kernel nfsd
> > > to permission checking as a robustness check.  We've always noted that
> > > SELinux does depend on the correctness of the kernel.
> > 
> > Oh, you're saying that this threat is out-of-scope? ;-)
> 
> Kernel flaws aren't something we can address (reliably and in general)
> via a kernel mechanism.  Versus a threat that can be addressed by kernel
> mechanism, like providing complete mediation and unambiguous access
> control.  There is a difference.  And we aren't ignoring the kernel
> correctness problem - there is separate work in that space, but it
> requires separate mechanism outside of SELinux itself.
> 
> > Note that here we've already strayed from the focus of the discussion;
> > we're no longer arguing "the implementation is ugly/broken", but you're
> > claiming "doesn't do what I need" - which I'm not disagreeing with. It
> > doesn't do what you want. Which is why you have SELinux, and it's going
> > to stay. Fine.
> > 
> > If we assume that the users who run it do have a need / use case for it
> > which they can't solve differently, we should really get back to the
> > discussion of how those needs can be met or provided by Linux in a
> > feasible way.
> 
> Part of the discussion has been whether those users' needs could be
> solved better via SELinux, whether via improved userspace tools (ala
> seedit possibly with an enhanced restorecond) or via extended kernel
> mechanism (ala named type transitions and some kind of inheritance
> model).  It does however seem like there is a fundamental conflict there
> on renaming behavior; I do not believe that file protections should
> automatically change in the kernel upon rename and should require
> explicit userspace action.  The question though is whether that renaming
> behavior in AA is truly a user requirement or a manufactured (i.e.
> made-up) one, and whether it is truly a runtime requirement or just a
> policy creation time one (the latter being adequately addressed by
> userspace relabeling).

I suppose there is also a question of whether that kind of model
wouldn't be better implemented as an ACL model with implicit
inheritance, e.g. if you specify an ACL on a directory, then all files
accessed via that directory are controlled in accordance with that ACL
unless they have their own more specific ACL, and if you move one of
those files to a different directory, then they automatically pick up
the protection of the new parent.  Doesn't require the kernel to be
matching pathname strings, just walking up the tree to determine the
closest ancestor with an explicit ACL on it.

> 
> If that behavior is truly needed (a point I wouldn't concede), then the
> discussion does reduce down to the right implementation method.  There
> it appears that the primary objection is to regenerating full pathname
> strings and matching them versus some kind of incremental matching
> either during lookup itself or via a reverse match as suggested.  That
> discussion is principally one in which the vfs folks should be engaged,
> not me.
> 
> > > > Your use case mandates complete system-wide mediation, because you want
> > > > full data flow analysis. Mine doesn't.
> > > Then yours isn't mandatory access control, nor is it confinement.  
> > 
> > I apologize for not using the word "confinement" in the way you expect
> > it to be used. I certainly don't want to imply it does do things it
> > doesn't. Keep in mind I'm not a native speaker, so nuances do get lost
> > sometimes; nor do I have long years of experience in the security
> > field. Thanks for clearing this up.
> > 
> > So agreed, it is not confinement nor MAC.
> > 
> > Would it be more appropriate if I used the word "restricts" or
> > "constrains"?
> 
> Yes.  Or simply "controls file accesses and capability usage".
> 
-- 
Stephen Smalley
National Security Agency

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

Powered by blists - more mailing lists