Re: implement-file-posix-capabilities.patch

[Serge E. Hallyn]

Quoting Chris Wright (chrisw@xxxxxxxxxxxx):
> [folks, this is getting much too long-winded to stay a private thread]
> 
> * Serge E. Hallyn (serue@xxxxxxxxxx) wrote:
> > Quoting Chris Wright (chrisw@xxxxxxxxxxxx):
> > > * Andrew Morgan (morgan@xxxxxxxxxx) wrote:
> > > > I share Casey's view that what's in the kernel now appears to have
> > > > evolved because of the absence of filesystem capabilities and not in
> > > > preparation for them. I'm not at all clear that they offer any real
> > > > improvement over the more macroscopic, but much simpler to understand,
> > > > superuser model.
> > > 
> > > Presently they offer next to nothing.  From the POV of kernel code,
> > > they've added an extremely coarse grained way to check privs for
> > > actions (CAP_SYS_ADMIN renders much of this useless for least priv).
> > > >From userspace POV, there's basically one well-known program that uses
> > > the existing crippled model to drop privs.  And from end-users' POV,
> > > there's no end of frustrated attempts to make something useful out
> > > of it.  From a security POV, there's missing functionality (which has
> > > been addressed in Andrew's older patches and Serge's current patchset).
> > 
> > I'm sorry I'm not sure what your conclusion is then.  Are you saying
> > that my patch does add functionality, or arguing that it shouldn't be
> > included?
> 
> It does add functionality, it is existing capabilities which are not
> particularly useful.

Ah, ok.

> > > > I think the implementation (the patch) adds support for storing
> > > > capabilities in the filesystem. But, I don't believe it is as a step
> > > > towards 'POSIX' capability support, but just adding another incrementa
> > > > twist to the Linux capability implementation - its hard to reason about
> > > > such a thing, in terms of security or otherwise. (Have you thought about
> > > > whether LD_LIBRARY_PATH is ignored by capability aware, but non-setuid-0
> > > > programs? To voice one example. There are many system consequences to
> > > > this model that will only become apparent when people start to seriously
> > > > implement and use it.)
> > > 
> > > The classic argument has been one of administration.  Tools know how to
> > > search for setuid programs,
> > 
> > Sure, but 'find' plus a 5-line program to check for security.capability
> > xattrs will find capability programs, right?
> 
> Yes.  I'm not 100% sold on the administration issue, but it is real, and
> unfortunately the extra 5-line program isn't a great solution.

It might not be :), but surely once people see what the actual
administration challenges turn out to be, they/we can write the tools to
satisfy those needs?  I don't believe they will be insurmountable.

You had in the past played with caps quite a bit, do you already have a
sense of what kinds of admin problems people will have?

> > Are there popular gui's in
> > widespread use which depend on programs granting extra privilege doing
> > so using setuid?
> > 
> > > and mainline MAC is not adding caps based on
> > > security domain during exec, etc.
> > 
> > I don't understand what you're saying - could you explain?  Which
> > 'mainline MAC', what sort of domains (TE?)?
> 
> mainline MAC meaning basically SELinux.  IOW, while LIDS and Apparmor
> had/have models for handling capabilities (don't recall if it was grant
> or restrict only), SELinux is just now talking about doing something
> like this, but nothing is upstream and in wide distribution.
> 
> > > My biggest concern is leaking caps to
> > > programs which are meant to be unprivileged.
> > 
> > Would it help if we place CONFIG_SECURITY_FILE_CAPABILITIES under
> > CONFIG_EXPERIMENTAl for a bit?
> 
> Would not hurt ;-)

Ok, here's a patch on top of 2.6.22-rc4-mm2 to do so,

thanks,
-serge