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

[Andy Lutomirski <luto@amacapital.net>]

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.

--Andy