On Mon, Nov 17, 2014 at 2:11 PM, Eric W.Biederman <ebiederm@xxxxxxxxxxxx> wrote:
>
>
> On November 17, 2014 1:07:30 PM EST, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>>On Nov 17, 2014 3:37 AM, "One Thousand Gnomes"
>><gnomes@xxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>> > optional), I can do that too. The security model of "having a
>>group
>>> > gives you less privilege than not having it" seems crazy, but
>>> > nonetheless I can see a couple of easy ways that we can avoid
>>breaking
>>>
>>> It's an old pattern of use that makes complete sense in a traditional
>>> Unix permission world because it's the only way to do "exclude
>>{list}"
>>> nicely. Our default IMHO shouldn't break this.
>>>
>>> > that pattern, no_new_privs being one of them. I'd like to make
>>sure
>>> > that nobody sees any other real-world corner case that unprivileged
>>> > setgroups would break.
>>>
>>> Barring the usual risk of people doing improper error checking I
>>don't
>>> see one immediately.
>>>
>>> For containers I think it actually makes sense that the sysctl can be
>>> applied per container anyway.
>>
>>We'll probably need per container sysctls some day.
>
> We already have a mess of per network namespace sysctls,
> as well as few for other namespaces.
>
> We have the infrastructure it is just a matter of using it for whatever purpose we need.
>
A list of group id ranges that it's permissible to drop would do the
trick, both for setgroups and for unshare. The downside would be that
users in those groups (i.e. everyone by default) would not be able to
unshare their user ns.
Better ideas welcome.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
