On Mon, 30 Mar 2015, Andy Lutomirski wrote:
> I'll submit a new version this week with the securebits. Sorry for the delay.
Are we going to get a new version?
On Thu, 9 Apr 2015, Christoph Lameter wrote:
> > I'll submit a new version this week with the securebits. Sorry for the delay.
> Are we going to get a new version?
Replying to my own here. Cant we simply use the SETPCAP approach as per
the patch I posted?
Quoting Christoph Lameter ([email protected]):
> On Thu, 9 Apr 2015, Christoph Lameter wrote:
>
> > > I'll submit a new version this week with the securebits. Sorry for the delay.
> > Are we going to get a new version?
>
> Replying to my own here. Cant we simply use the SETPCAP approach as per
> the patch I posted?
Andy had objections to that, but it seems ok to me.
-serge
On Fri, Apr 24, 2015 at 10:53 AM, Serge Hallyn <[email protected]> wrote:
> Quoting Christoph Lameter ([email protected]):
>> On Thu, 9 Apr 2015, Christoph Lameter wrote:
>>
>> > > I'll submit a new version this week with the securebits. Sorry for the delay.
>> > Are we going to get a new version?
>>
>> Replying to my own here. Cant we simply use the SETPCAP approach as per
>> the patch I posted?
>
> Andy had objections to that, but it seems ok to me.
>
I object because CAP_SETPCAP is very powerful whereas
CAP_NET_BIND_SERVICE, for example, isn't. I'm fine with having a
switch to turn off ambient caps, but requiring the "on" state to give
processes superpowers seems unfortunate.
Sorry for the huge delay. I got caught up with travel and the merge
window. Here's a sneak peek:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=cap_ambient
I need to write the user code to go with it and test it a bit before
sending it out for real.
--Andy
Quoting Andy Lutomirski ([email protected]):
> On Fri, Apr 24, 2015 at 10:53 AM, Serge Hallyn <[email protected]> wrote:
> > Quoting Christoph Lameter ([email protected]):
> >> On Thu, 9 Apr 2015, Christoph Lameter wrote:
> >>
> >> > > I'll submit a new version this week with the securebits. Sorry for the delay.
> >> > Are we going to get a new version?
> >>
> >> Replying to my own here. Cant we simply use the SETPCAP approach as per
> >> the patch I posted?
> >
> > Andy had objections to that, but it seems ok to me.
> >
>
> I object because CAP_SETPCAP is very powerful whereas
> CAP_NET_BIND_SERVICE, for example, isn't. I'm fine with having a
> switch to turn off ambient caps, but requiring the "on" state to give
Would only really be needed for the initial 'enable ambient caps for this
process tree', though. Once that was set, add/remove'ing caps from the
ambient set wouldn't need to be required.
> processes superpowers seems unfortunate.
>
> Sorry for the huge delay. I got caught up with travel and the merge
> window. Here's a sneak peek:
>
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=cap_ambient
>
> I need to write the user code to go with it and test it a bit before
> sending it out for real.
Ok, thanks
-serge
On Fri, 24 Apr 2015, Serge Hallyn wrote:
> > I object because CAP_SETPCAP is very powerful whereas
> > CAP_NET_BIND_SERVICE, for example, isn't. I'm fine with having a
> > switch to turn off ambient caps, but requiring the "on" state to give
>
> Would only really be needed for the initial 'enable ambient caps for this
> process tree', though. Once that was set, add/remove'ing caps from the
> ambient set wouldn't need to be required.
Exactly. Its much simpler than alternate approaches. And its convoluted
enough.
On Fri, Apr 24, 2015 at 12:09 PM, Serge Hallyn <[email protected]> wrote:
> Quoting Andy Lutomirski ([email protected]):
>> On Fri, Apr 24, 2015 at 10:53 AM, Serge Hallyn <[email protected]> wrote:
>> > Quoting Christoph Lameter ([email protected]):
>> >> On Thu, 9 Apr 2015, Christoph Lameter wrote:
>> >>
>> >> > > I'll submit a new version this week with the securebits. Sorry for the delay.
>> >> > Are we going to get a new version?
>> >>
>> >> Replying to my own here. Cant we simply use the SETPCAP approach as per
>> >> the patch I posted?
>> >
>> > Andy had objections to that, but it seems ok to me.
>> >
>>
>> I object because CAP_SETPCAP is very powerful whereas
>> CAP_NET_BIND_SERVICE, for example, isn't. I'm fine with having a
>> switch to turn off ambient caps, but requiring the "on" state to give
>
> Would only really be needed for the initial 'enable ambient caps for this
> process tree', though. Once that was set, add/remove'ing caps from the
> ambient set wouldn't need to be required.
That's sort of what my patch does -- you need CAP_SETPCAP to switch
the securebit.
But Christoph's patch required it to add caps to the ambient set, right?
--Andy
On Fri, 24 Apr 2015, Andy Lutomirski wrote:
> That's sort of what my patch does -- you need CAP_SETPCAP to switch
> the securebit.
>
> But Christoph's patch required it to add caps to the ambient set, right?
Yes but you seem to be just adding one additional step without too much of
a benefit because you still need CAP_SETPCAP.
On Fri, Apr 24, 2015 at 1:13 PM, Christoph Lameter <[email protected]> wrote:
> On Fri, 24 Apr 2015, Andy Lutomirski wrote:
>
>> That's sort of what my patch does -- you need CAP_SETPCAP to switch
>> the securebit.
>>
>> But Christoph's patch required it to add caps to the ambient set, right?
>
> Yes but you seem to be just adding one additional step without too much of
> a benefit because you still need CAP_SETPCAP.
>
No, because I set the default to on :)
Also, in my model you can do:
$ sudo capset cap_whatever=eip something
$ ./something
and the program can make its cap be ambient and run a helper. In the
CAP_SETPCAP model, that doesn't work.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
On Fri, Apr 24, 2015 at 01:18:44PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 24, 2015 at 1:13 PM, Christoph Lameter <[email protected]> wrote:
> > On Fri, 24 Apr 2015, Andy Lutomirski wrote:
> >
> >> That's sort of what my patch does -- you need CAP_SETPCAP to switch
> >> the securebit.
> >>
> >> But Christoph's patch required it to add caps to the ambient set, right?
> >
> > Yes but you seem to be just adding one additional step without too much of
> > a benefit because you still need CAP_SETPCAP.
> >
>
> No, because I set the default to on :)
Right - I definately prefer
. default off
. CAP_SETPCAP required to turn it on (for self and children)
. once on, anyone can copy bits from (whatever we decided) to pA.
> Also, in my model you can do:
>
> $ sudo capset cap_whatever=eip something
> $ ./something
>
> and the program can make its cap be ambient and run a helper. In the
> CAP_SETPCAP model, that doesn't work.
>
> --Andy
>
> --
> Andy Lutomirski
> AMA Capital Management, LLC
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Apr 24, 2015 2:15 PM, "Serge E. Hallyn" <[email protected]> wrote:
>
> On Fri, Apr 24, 2015 at 01:18:44PM -0700, Andy Lutomirski wrote:
> > On Fri, Apr 24, 2015 at 1:13 PM, Christoph Lameter <[email protected]> wrote:
> > > On Fri, 24 Apr 2015, Andy Lutomirski wrote:
> > >
> > >> That's sort of what my patch does -- you need CAP_SETPCAP to switch
> > >> the securebit.
> > >>
> > >> But Christoph's patch required it to add caps to the ambient set, right?
> > >
> > > Yes but you seem to be just adding one additional step without too much of
> > > a benefit because you still need CAP_SETPCAP.
> > >
> >
> > No, because I set the default to on :)
>
> Right - I definately prefer
>
> . default off
> . CAP_SETPCAP required to turn it on (for self and children)
> . once on, anyone can copy bits from (whatever we decided) to pA.
>
Why default off? If there's some weird reason that switching it on
could cause a security problem, then I'd agree, but I haven't spotted
a reason yet.
--Andy
Quoting Andy Lutomirski ([email protected]):
> On Apr 24, 2015 2:15 PM, "Serge E. Hallyn" <[email protected]> wrote:
> >
> > On Fri, Apr 24, 2015 at 01:18:44PM -0700, Andy Lutomirski wrote:
> > > On Fri, Apr 24, 2015 at 1:13 PM, Christoph Lameter <[email protected]> wrote:
> > > > On Fri, 24 Apr 2015, Andy Lutomirski wrote:
> > > >
> > > >> That's sort of what my patch does -- you need CAP_SETPCAP to switch
> > > >> the securebit.
> > > >>
> > > >> But Christoph's patch required it to add caps to the ambient set, right?
> > > >
> > > > Yes but you seem to be just adding one additional step without too much of
> > > > a benefit because you still need CAP_SETPCAP.
> > > >
> > >
> > > No, because I set the default to on :)
> >
> > Right - I definately prefer
> >
> > . default off
> > . CAP_SETPCAP required to turn it on (for self and children)
> > . once on, anyone can copy bits from (whatever we decided) to pA.
> >
>
> Why default off? If there's some weird reason that switching it on
> could cause a security problem, then I'd agree, but I haven't spotted
> a reason yet.
Cause it's less scary?
I'll just wait for the new patchset :)
On Fri, 24 Apr 2015, Andy Lutomirski wrote:
> Also, in my model you can do:
>
> $ sudo capset cap_whatever=eip something
> $ ./something
>
> and the program can make its cap be ambient and run a helper. In the
> CAP_SETPCAP model, that doesn't work.
Dont see too much difference in setting caps and CAP_SETPCAP on
"./something" to allow it to set the ambient caps.