linux-kernel - Re: [RFC] Implement ambient capability set.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 4 Feb 2015 13:31:47 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Christoph Lameter <cl@...ux.com>,
	"Andrew G. Morgan" <morgan@...nel.org>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Jonathan Corbet <corbet@....net>,
	Aaron Jones <aaronmdjones@...il.com>,
	"Ted Ts'o" <tytso@....edu>,
	LSM List <linux-security-module@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...uxfoundation.org>
Subject: Re: [RFC] Implement ambient capability set.

On Wed, Feb 4, 2015 at 1:27 PM, Serge E. Hallyn <serge@...lyn.com> wrote:
> Quoting Andy Lutomirski (luto@...capital.net):
>> On Wed, Feb 4, 2015 at 1:16 PM, Serge E. Hallyn <serge@...lyn.com> wrote:
>> > Quoting Andy Lutomirski (luto@...capital.net):
>> >> On Wed, Feb 4, 2015 at 10:49 AM, Christoph Lameter <cl@...ux.com> wrote:
>> >> > +
>> >> > +               if (!cap_valid(arg2))
>> >> > +                       return -EINVAL;
>> >> > +
>> >> > +               new =prepare_creds();
>> >> > +               if (arg3 == 0)
>> >> > +                       cap_lower(new->cap_ambient, arg2);
>> >> > +               else
>> >> > +                       cap_raise(new->cap_ambient, arg2);
>> >> > +               return commit_creds(new);
>> >> > +
>> >>
>> >> This let you add capabilities you don't even have to cap_ambient.  I'm
>> >> fine with that as long as the cap evolution rule changes, as above.
>> >
>> > How about if instead we do restrict it to what's in pP?  I don't
>> > want CAP_SETPCAP to become a cheap way to get all caps back.  With
>> > or without NNP.
>>
>> We'd also have to modify everything that can change pP to change pA as
>> well if we went this route.  I'd be okay with that, but it would make
>> the patch much larger, and I'm not entirely sure I see the benefit.
>> It would keep the number of possible states smaller, which could be
>> nice.
>
> Do you mean if we didn't require NNP?  I'm suggesting that even if
> we require NNP we should restrict any new bits added to pA to be
> in pP at the prctl call.  Then whether or not to drop them from
> pA when they are dropped from pP, I'm not yet certain.

I mean regardless of whether we require NNP.

I think that, unless we change the evolution rule, we would need to
drop from pA when bits are dropped from pP to preserve the idea that
dropping bits from pP drops them for good (as long as ruid != 0 or
some securebit is set).

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/