Re: [RFC] Capabilities still can't be inherited by normal programs
From: Andy Lutomirski
Date: Wed Dec 05 2012 - 16:46:41 EST
On Wed, Dec 5, 2012 at 1:05 PM, Serge Hallyn <serge.hallyn@xxxxxxxxxxxxx> wrote:
> Quoting Andy Lutomirski (luto@xxxxxxxxxxxxxx):
>> On Tue, Dec 4, 2012 at 5:54 AM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote:
>> > Quoting Andy Lutomirski (luto@xxxxxxxxxxxxxx):
>> >> >> 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.
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.
--Andy
--
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/