[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070615235041.GC15056@kroah.com>
Date: Fri, 15 Jun 2007 16:50:41 -0700
From: Greg KH <greg@...ah.com>
To: James Morris <jmorris@...ei.org>
Cc: Pavel Machek <pavel@....cz>, 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 05:42:08PM -0400, James Morris wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
>
> > > 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?
>
> This is entirely controllable via policy. That is, you specify that newly
> create files are labeled to something safe (enforced atomically at the
> kernel level), and then your userland relabeler would be invoked via
> inotify to relabel based on your userland pathname specification.
>
> This labeling policy can be as granular as you wish, from the entire
> filesystem to a single file. It can also be applied depending on the
> process which created the file and the directory its created in, ranging
> from all processes and all directories, to say, just those running as
> user_t in directories labeled as public_html_t (or whatever).
Oh great, then things like source code control systems would have no
problems with new files being created under them, or renaming whole
trees.
So, so much for the "it's going to be too slow re-labeling everything"
issue, as it's not even required for almost all situations :)
thanks for letting us know.
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/
Powered by blists - more mailing lists