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

[Jann Horn <jann@thejh.net>]

[-- Attachment #1: Type: text/plain, Size: 2130 bytes --]

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.

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.

For this reason, I'm wondering whether it might make sense to create
a new global capability set that specifies which capabilities should
be inherited on namespace entry / namespace access from outside
instead of being set unconditionally, and then let distros and/or
system administrators use that to e.g. restrict CAP_NET_ADMIN.  


But I'm not sure whether I'd want to fly over to the US to attend
the summit, and I'm not sure whether a discussion on this would
benefit from happening in person.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]