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 a
Quoting Andy Lutomirski (l...@amacapital.net):
> On Apr 24, 2015 2:15 PM, "Serge E. Hallyn" 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 wrote:
> > > > On Fri, 24 Apr 2015, Andy Lutomirski wrote:
> > > >
>
On Apr 24, 2015 2:15 PM, "Serge E. Hallyn" 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 wrote:
> > > On Fri, 24 Apr 2015, Andy Lutomirski wrote:
> > >
> > >> That's sort of what my patch does -- you need CAP_SET
On Fri, Apr 24, 2015 at 01:18:44PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 24, 2015 at 1:13 PM, Christoph Lameter 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 pa
On Fri, Apr 24, 2015 at 1:13 PM, Christoph Lameter 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
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 beca
On Fri, Apr 24, 2015 at 12:09 PM, Serge Hallyn wrote:
> Quoting Andy Lutomirski (l...@amacapital.net):
>> On Fri, Apr 24, 2015 at 10:53 AM, Serge Hallyn
>> wrote:
>> > Quoting Christoph Lameter (c...@linux.com):
>> >> On Thu, 9 Apr 2015, Christoph Lameter wrote:
>> >>
>> >> > > I'll submit a new
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
Quoting Andy Lutomirski (l...@amacapital.net):
> On Fri, Apr 24, 2015 at 10:53 AM, Serge Hallyn
> wrote:
> > Quoting Christoph Lameter (c...@linux.com):
> >> On Thu, 9 Apr 2015, Christoph Lameter wrote:
> >>
> >> > > I'll submit a new version this week with the securebits. Sorry for
> >> > > th
On Fri, Apr 24, 2015 at 10:53 AM, Serge Hallyn wrote:
> Quoting Christoph Lameter (c...@linux.com):
>> 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?
>>
>> Replyi
Quoting Christoph Lameter (c...@linux.com):
> 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
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?
--
To unsubscribe from this list:
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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma
On Mon, 30 Mar 2015, Andy Lutomirski wrote:
> > Would this suffice? It puts the CAP_SETPCAP limitation back to how it
> > was in my earlier patch.
> I really don't like that variant. CAP_SETPCAP is dangerous and so
> absurdly powerful that people really shouldn't hand it out.
According to
On Mar 30, 2015 7:55 AM, "Christoph Lameter" wrote:
>
> On Sat, 14 Mar 2015, Andrew G. Morgan wrote:
>
> >
> > I thought I did. Please implement a lockable secure bit and I will
>
> Would this suffice? It puts the CAP_SETPCAP limitation back to how it
> was in my earlier patch.
>
I really don't l
On Sat, 14 Mar 2015, Andrew G. Morgan wrote:
>
> I thought I did. Please implement a lockable secure bit and I will
Would this suffice? It puts the CAP_SETPCAP limitation back to how it
was in my earlier patch.
Subject: ambient caps: Allow disabling with SETPCAP
Do not allow setting ambient c
On Sat, Mar 14, 2015 at 3:55 PM, Andy Lutomirski wrote:
> It occurs to me that my previous reply was unnecessarily long and
> missed the point. Trying again:
>
> On Sat, Mar 14, 2015 at 3:17 PM, Andrew G. Morgan wrote:
>> On Sat, Mar 14, 2015 at 2:45 PM, Andy Lutomirski wrote:
>>> On Sat, Mar 1
It occurs to me that my previous reply was unnecessarily long and
missed the point. Trying again:
On Sat, Mar 14, 2015 at 3:17 PM, Andrew G. Morgan wrote:
> On Sat, Mar 14, 2015 at 2:45 PM, Andy Lutomirski wrote:
>> On Sat, Mar 14, 2015 at 2:09 PM, Andrew G. Morgan wrote:
>>> My Nack remains t
On Sat, Mar 14, 2015 at 3:17 PM, Andrew G. Morgan wrote:
> On Sat, Mar 14, 2015 at 2:45 PM, Andy Lutomirski wrote:
>> On Sat, Mar 14, 2015 at 2:09 PM, Andrew G. Morgan wrote:
>>> On Fri, Mar 13, 2015 at 10:57 AM, Andy Lutomirski
>>> wrote:
On Mar 13, 2015 6:24 AM, "Andrew G. Morgan" wrot
On Sat, Mar 14, 2015 at 2:45 PM, Andy Lutomirski wrote:
> On Sat, Mar 14, 2015 at 2:09 PM, Andrew G. Morgan wrote:
>> On Fri, Mar 13, 2015 at 10:57 AM, Andy Lutomirski
>> wrote:
>>> On Mar 13, 2015 6:24 AM, "Andrew G. Morgan" wrote:
> It's to preserve the invariant that pA is always
On Sat, Mar 14, 2015 at 2:09 PM, Andrew G. Morgan wrote:
> On Fri, Mar 13, 2015 at 10:57 AM, Andy Lutomirski wrote:
>> On Mar 13, 2015 6:24 AM, "Andrew G. Morgan" wrote:
>>>
>>> > It's to preserve the invariant that pA is always a subset of pI.
>>>
>>> But since a user can always raise a bit in
On Fri, Mar 13, 2015 at 10:57 AM, Andy Lutomirski wrote:
> On Mar 13, 2015 6:24 AM, "Andrew G. Morgan" wrote:
>>
>> > It's to preserve the invariant that pA is always a subset of pI.
>>
>> But since a user can always raise a bit in pI if it is present in pP,
>> what does this invariant add to you
On Fri, Mar 13, 2015 at 12:03 PM, Andy Lutomirski wrote:
> On Fri, Mar 13, 2015 at 11:52 AM, Kees Cook wrote:
>>
>> All this said, almost half of the capabilities, if passed to flawed
>> children with attacker controlled execution, can be elevated to full
>> root privileges pretty easily[1], so I
On Fri, Mar 13, 2015 at 11:52 AM, Kees Cook wrote:
>
> All this said, almost half of the capabilities, if passed to flawed
> children with attacker controlled execution, can be elevated to full
> root privileges pretty easily[1], so I think any documentation around
> this feature should include so
On Fri, 13 Mar 2015, Andy Lutomirski wrote:
> > The functionalty here depends on CAP_SETPCAP. That was intended as some
> > point to be off by default? You can have distros/kernels with that being
> > off.
>
> Not in my version. I don't want to further encourage people to hand
> out CAP_SETPCAP.
On Fri, Mar 13, 2015 at 10:57 AM, Andy Lutomirski wrote:
> On Mar 13, 2015 6:24 AM, "Andrew G. Morgan" wrote:
>> I think it is safe to say that naive privilege inheritance has a fair
>> track record of being exploited orders of magnitude more frequently
>> than this. After all, these are the reas
On Fri, Mar 13, 2015 at 9:06 AM, Christoph Lameter wrote:
> On Fri, 13 Mar 2015, Andrew G. Morgan wrote:
>
>> > prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, CAP_SYS_ADMIN);
>> > system("/bin/bash");
>>
>> Let's call the above two lines [a] and [b]. With this patch, you are
>> encouraging folk to wr
On Mar 13, 2015 6:24 AM, "Andrew G. Morgan" wrote:
>
> > It's to preserve the invariant that pA is always a subset of pI.
>
> But since a user can always raise a bit in pI if it is present in pP,
> what does this invariant add to your model other than inconvenience?
The useful part is that droppi
On Fri, 13 Mar 2015, Andrew G. Morgan wrote:
> > prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, CAP_SYS_ADMIN);
> > system("/bin/bash");
>
> Let's call the above two lines [a] and [b]. With this patch, you are
> encouraging folk to write programs that contain a line like [a]
> already. So, yes, I am
> It's to preserve the invariant that pA is always a subset of pI.
But since a user can always raise a bit in pI if it is present in pP,
what does this invariant add to your model other than inconvenience?
>> I'm also unclear how you can turn off this new 'feature' for a process
>> tree? As it is
On Thu, Mar 12, 2015 at 3:10 PM, Andrew G. Morgan wrote:
> I'm unclear why you refer to the inheritable set in this test:
>
> + } else {
> + if (arg2 == PR_CAP_AMBIENT_RAISE &&
> + (!cap_raised(current_cred()->cap_permitted, arg3)
> ||
I'm unclear why you refer to the inheritable set in this test:
+ } else {
+ if (arg2 == PR_CAP_AMBIENT_RAISE &&
+ (!cap_raised(current_cred()->cap_permitted, arg3) ||
+!cap_raised(current_cred()->cap_inherita
On Thu, Mar 12, 2015 at 11:08 AM, Andy Lutomirski wrote:
> Credit where credit is due: this idea comes from Christoph Lameter
> with a lot of valuable input from Serge Hallyn. This patch is
> heavily based on Christoph's patch.
>
> = The status quo =
>
> On Linux, there are a number of ca
33 matches
Mail list logo
