From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F10C9B4 for ; Wed, 20 Jul 2016 02:15:19 +0000 (UTC) Received: from mail-vk0-f50.google.com (mail-vk0-f50.google.com [209.85.213.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9343D12D for ; Wed, 20 Jul 2016 02:15:18 +0000 (UTC) Received: by mail-vk0-f50.google.com with SMTP id n129so4907452vke.3 for ; Tue, 19 Jul 2016 19:15:18 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87y44xr5zp.fsf@x220.int.ebiederm.org> References: <20160711173329.GA8240@pc.thejh.net> <87y44xr5zp.fsf@x220.int.ebiederm.org> From: Andy Lutomirski Date: Tue, 19 Jul 2016 19:14:58 -0700 Message-ID: To: "Eric W. Biederman" Content-Type: text/plain; charset=UTF-8 Cc: Jann Horn , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [TOPIC] kernel hardening / self-protection / whatever List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, Jul 19, 2016 at 8:40 AM, Eric W. Biederman wrote: > Jann Horn 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