Date: Tue, 27 Sep 2011 08:21:57 -0500 From: "Serge E. Hallyn" <serge.hallyn@...onical.com> To: Vasiliy Kulikov <segoon@...nwall.com> Cc: Serge Hallyn <serge@...lyn.com>, akpm@...l.org, linux-kernel@...r.kernel.org, netdev@...r.kernel.org, containers@...ts.linux-foundation.org, dhowells@...hat.com, ebiederm@...ssion.com, rdunlap@...otime.net, kernel-hardening@...ts.openwall.com Subject: Re: [PATCH 01/15] add Documentation/namespaces/user_namespace.txt (v3) Quoting Vasiliy Kulikov (segoon@...nwall.com): > (cc'ed kernel-hardening) > > > Hi Serge, > > I didn't deeply studied the patches yet (sorry!), but I have some > long-term question about the technique in general. I couldn't find > answers to the questions in the documentation. Great - thanks for your time, Vasiliy. There is documentation at https://wiki.ubuntu.com/UserNamespace, and I was adding a Documentation/namespaces/user_namespace.txt file (which hasn't gone in yet) which you can see here: https://lkml.org/lkml/2011/7/26/351 But those don't answer your questions sufficiently. > First, the patches by design expose much kernel code to unprivileged > userspace processes. This code doesn't expect malformed data (e.g. VFS, > specific filesystems, block layer, char drivers, sysadmin part of LSMs, > etc. etc.). By relaxing permission rules you greatly increase attack > surface of the kernel from unprivileged users. Are you (or somebody > else) planning to audit this code? I had wanted to (but didn't) propose a discussion at ksummit about how best to approach the filesystem code. That's not even just for user namespaces - patches have been floated in the past to make mount an unprivileged operation depending on the FS and the user's permission over the device and target. So I don't know if a combination of auditing and fuzzing is the way to go, or what, and wanted to get input from some people who are more knowledgeable on that topic than me. You're right about other kernel code as well. I'll certainly join in this effort, but don't want to go blindly charging in without some advice/guidance about the best way to do this and, if others are interested, coordinate it. We can start by looking through all code which is currently under ns_capable(), and analyzing that. But what tools do we have available to perform the analysis? Do you think a kernel summit discussion (i suppose given the late timing, a beer bof) would be beneficial? (I wouldn't be there) > Also, will it be possible to somehow restrict what specific kernel > facilities are accessible from users (IOW, what root emulation > limitations are in action)? It is userful from both points of sysadmin, > who might not want to allow users to do such things, and from the > security POV in sense of attack surface reduction. You're probably thinking along different lines, but this is why I've been wanting seccomp2 to get pushed through. So that we can deny a container the syscalls we know it won't need, especially newer ones, to reduce the attack surface available to it. > The patches explicitly enable some features for users on white list > basis. It's possible to do it for simple cases, but what are you going > to do with multiplexing functions where there is a permission check > before the actual multiplexing? FS, networking drivers, etc. Are you > going to do the same thing as net_namespace does? - For each multiplexed > entity create bool ->ns_aware which is false by default for all > "untrusted"/not prepared protocols and is true for audited/prepared > protocols. Or probably you have something else in mind? Ah, I typed the bottom paragraph before realizing what you were actually asking. The filesystems are a good example. In the unprivileged mounts patchsets, for instance, a flag was added to each filesystem indicating if it was safe for unprivileged mounting (turned off for all real block filesystems :). For targeted capabilities, my goal would be simply to make sure that each non-netns-aware entity do a (untargeted) capable() check. Without pointing to a specific example it's hard to say what I will do. It depends on how the code was previously laid out, and what the maintainer of that subsystem prefers. The way we're approaching it right now is that by default everything stays 'capable(X)', so that a non-init user namespace doesn't get the privileges. While some of my patchsets this summer didn't follow this, Eric reminded me that we should first clamp down on the user namespaces as much as possible, and relax permissions in child namespaces later. So the small (1-2 patch sized) sets I've been sending the last few weeks are just trying to fix existing inadequate userid or capability checks. -serge
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.