Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

[Casey Schaufler <casey@schaufler-ca.com>]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Wed, 2007-12-12 at 11:44 -0800, Casey Schaufler wrote:
> > --- David Howells <dhowells@redhat.com> wrote:
> > 
> > > Casey Schaufler <casey@schaufler-ca.com> wrote:
> > > 
> > > > What sort of authorization are you thinking of? I would expect
> > > > that to have been done by cachefileselinuxcontext (or
> > > > cachefilesspiffylsmcontext) up in userspace. If you're going to
> > > > rely on userspace applications for policy enforcement they need
> > > > to be good enough to count on after all.
> > > 
> > > It can't be done in userspace, otherwise someone using the cachefilesd
> > > interface can pass an arbitrary context up.
> > 
> > Yes, but I would expect that interface to be protected (owned by root,
> > mode 0400). If /dev/cachefiles has to be publicly accessable make it
> > a privileged ioctl.
> 
> Uid 0 != CAP_MAC_OVERRIDE if you configure file caps and such.

Yes, but we're talking about writing the configuration information
to the kernel, not actually making any access checks with it. I
think. What I think we're talking about (and please correct me David
if I've stepped into the wrong theatre) is getting the magic
secctx that cachefiles will use instead of the secctx that the task
would have otherwise. I don't think we're talking about recomputing
it on every access, I think David is looking for the blunderbuss
secctx that he can use any time he needs one.

And it would be CAP_MAC_ADMIN, since you're changing the MAC
characteristics of the system, not doing an access check.

Casey Schaufler
casey@schaufler-ca.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/