Re: [capabilities] Allow normal inheritance for a configurable set of capabilities

[Andrew G. Morgan]

I'm not generally in favor of this. Mostly because this seems to be a
mini-root kind of inheritance that propagates privilege to binaries
that aren't prepared for privilege. I don't really buy the mmap code
concern because the model as it stands says that you trust the binary
(and all of the various ways it was programmed to execute code) with
specific privileges. If the binary mmap's some code (PAM modules come
to mind) then that is part of what it was programmed to/allowed to do.

That being said, if you really really want this kind of thing, then
make it a single secure bit (with another lock on/off bit) which, when
set, makes: fI default to X.

   pP' = (X & fP) | (pI & fI)

That way the per-process bounding set still works as advertised and
you don't need to worry about the existing semantics being violated.

Cheers

Andrew


On Tue, Feb 3, 2015 at 9:26 AM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote:
> Quoting Christoph Lameter (cl@xxxxxxxxx):
>> On Tue, 3 Feb 2015, Serge E. Hallyn wrote:
>>
>> > We've currently got two proposals.  (Three includig yours;  but I explained my
>> > problem with yours earlier this morning -  do appreciate the proposal and
>> > the patch though, really, thanks)  It's worth digging into the details of
>> > each, but if they end up complicating things then perhaps "dropping
>> > capabilities and going with something new" ought to be another proposal.
>>
>> Ok that is about the binding to a person and executable?
>
> It's about at least making it per-process(-tree).
>
>> So you think there should be a cap_inheritable mask settable in the caps
>> of each file.
>
> No.  I mean,  we have that now.  I just want to require a privileged process
> to fill in the pA in the first place.  If people are currently using file
> caps "as intended" I don't want behavior to change for them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/