Re: [RFC] Capabilities still can't be inherited by normal programs

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

On 12/5/2012 2:20 PM, Serge Hallyn wrote:
> Quoting Andy Lutomirski (luto@amacapital.net):
>> On Wed, Dec 5, 2012 at 1:05 PM, Serge Hallyn <serge.hallyn@canonical.com> wrote:
>>> Quoting Andy Lutomirski (luto@amacapital.net):
>>>> On Tue, Dec 4, 2012 at 5:54 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
>>>>> Quoting Andy Lutomirski (luto@amacapital.net):
>>>>>>>> d) If I really wanted, I could emulate execve without actually doing
>>>>>>>> execve, and capabilities would be inherited.
>>>>>>> If you could modify the executable properties of the binary that has
>>>>>>> the privilege to wield a privilege then you are either exploiting an
>>>>>>> app bug, or doing something the privileged binary has been trusted to
>>>>>>> do.
>>>>>> That's not what I mean.  I would:
>>>>>>
>>>>>> fork()
>>>>>> munmap everything
>>>>>> mmap ld.so
>>>>>> set up a fake initial stack and the right fd or mapping or whatever
>>>>>> just to ld-linux.so
>>>>>>
>>>>>> That's almost execve, and privilege inheritance works.
>>>>> But of course that is why you only want to fill fI on programs you trust
>>>>> not to do that.  What you are arguing is that you want to give fI on
>>>>> programs you don't trust anyway, and so heck why not just give it on
>>>>> everything.
>>>>>
>>>> Huh?  I'd set fP on a program I expect to do *exactly* that (or use
>>>> actual in-kernel capability inheritance, which I would find vastly
>>>> more pleasant).  If I give a program a capability (via fP or fI & pI),
>>>> then I had better trust it not to abuse that capability.  Having it
>>>> pass that capability on to a child helper process would be just fine
>>>> with me *because it already has that capability*.
>>>>
>>>> The problem with the current inheritance mechanism is that it's very
>>>> difficult to understand what it means for an fI bit or a pI bit to be
>>>> set.  Saying "set a pI bit using pam if you want to grant permission
>>>> to that user to run a particular program with fI set" is crap -- it
>>>> only works if there is exactly one binary on the system with that bit
>>>> set.  In any case, a different administrator or package might use it
>>>> for something different.
>>>>
>>>> Suppose I use the (apparently) current suggested approach: I install a
>>>> fI=cap_net_raw copy of tcpdump somewhere.  Then I write a helper that
>>>> has fP=cap_new_raw and invokes that copy of tcpdump after appropriate
>>>> validation of parameters.  All is well.
>>> Since you're writing a special helper, you can surely have it validate
>>> the userid and make it so the calling user doesn't have to have
>>> cap_net_raw in pI?
>> I can and did.
> Oh, oops, I mis-understood what you meant was the problem.
>
> Yup, that is a real limitation.
>
> Yes, with the posix file caps you will be disappointed unless you see
> pI=X as "this user may run any program which is Inh-trusted with X" and
> fI=X as "this program may be run with X by any user Inh-trusted with X".
>
> It almost makes me want to say that there should be an execve-analogue
> to prctl(PR_SET_KEEPCAPS), which says caps will remain unchanged for one
> execve.  Or perhaps an intermediate securebits state between
> !SECBIT_NOROOT and SECBIT_NOROOT, which automatically transitions after
> the first execve to SECBIT_NOROOT.
>
>> The mere presence of a cap_net_raw+i tcpdump binary is more or less
>> equivalent to saying that users with cap_net_raw in pI can capture
>> packets.  I've just prevented pI=cap_net_raw from meaning anything
>> less than "can capture packets".  So I think we should bite the bullet
>> and just let programs opt in (via some appropriately careful
>> mechanism) to real capability inheritance.
> By real you mean more precise.  I think it'd be very interesting to get
> together with Markku and learn more from the N9 experiment!
>
> Markku, are there any post-mortem analysis papers we can read for
> starters?  Andy would not be trying to restrict root in general, so
> the ramification you cited may not necessarily be relevant.
>
> -serge

http://wt.tuxomania.net/publications/posix.1e/download.html

Everyone should read the capabilities rationale. It answers most
of the questions on this thread, and a bunch more. The capabilities
mechanism has to support what are currently setuid-root programs
without change and allow for new programs that use the mechanism
wisely and fully.


> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>