Re: [Ksummit-discuss] [TOPIC] kernel hardening / self-protection / whatever

[ebiederm@xmission.com (Eric W. Biederman)]

Andy Lutomirski <luto@amacapital.net> writes:

> On Tue, Jul 19, 2016 at 8:40 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Jann Horn <jann@thejh.net> writes:
>>
>>> On Sun, Jul 10, 2016 at 09:28:53PM -0700, Andy Lutomirski wrote:
>>>> Are there useful things to discuss in person about hardening? [...]
>>>
>>> I think that an interesting question to discuss might be whether, and
>>> if so, how, it makes sense to add restrictions to namespaces.
>>>
>>> Namespaces, as a concept, aren't very scary when you keep in mind that
>>> they only grant privileges to otherwise unprivileged users when they
>>> interact with things inside their namespaces. However, in their
>>> implementation, they are somewhat scary because they expose code to
>>> unprivileged users that was written as code only root could reach. As
>>> an example, have a look at NCC Group's netfilter bugs (and netfilter
>>> in general; iirc, the filter parsing code has exponential complexity
>>> without process death checks, which afaik shouldn't happen in any
>>> code normal users can reach).
>>>
>>> User namespaces alone are pretty simple. I don't know everything
>>> about mount namespaces, but I think they also don't expose big masses
>>> of kernel code, and IPC, PID and UTS namespaces are pretty simple.
>>
>> Mount namespaces share a lot by default and as such there have been a
>> lot of hard to resolve semantic difficulties that had to be sorted out.
>>
>> I am very grateful right now that the issues we are primary issues we
>> are seeing now are primarily human error.
>>
>>> I think that network namespaces, compared to other namespace types,
>>> expose a lot of code. Grepping for CAP_SYS_ADMIN with
>>> `egrep -R '(ns_capable|netlink_net_capable).*CAP_NET_ADMIN'`
>>> returns a bunch of things, including netlink stuff, netfilter,
>>> sysctls, AF_KEY stuff, bridges, routing, socket repair, ARP and
>>> tunnel devices. At the same time, they are one of the lesser-used
>>> namespace types: Containers need them, but sandboxes don't really
>>> need them for much apart from making abstract unix sockets and
>>> networking in general inaccessible.
>>
>> Sort of.  A lot of the code is already exposed as the networking stack,
>> and is exposed from the underside to packets from random strangers from
>> the internet if not from the control side.
>>
>
> At least when that code was written the authors *knew* it was
> security-sensitive.  The control stuff wasn't security sensitive in
> the past.

True.  I tried to review things to make certain they were safe in user
namespaces when I enabled things but clearly a few things slipped
through the cracks.

Eric