From: "Serge E. Hallyn" <serge.hallyn@canonical.com> To: Vasiliy Kulikov <segoon@openwall.com> Cc: Serge Hallyn <serge@hallyn.com>, akpm@osdl.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, containers@lists.linux-foundation.org, dhowells@redhat.com, ebiederm@xmission.com, rdunlap@xenotime.net, kernel-hardening@lists.openwall.com Subject: Re: [PATCH 01/15] add Documentation/namespaces/user_namespace.txt (v3) Date: Tue, 27 Sep 2011 08:21:57 -0500 [thread overview] Message-ID: <20110927132157.GB3111@sergelap> (raw) In-Reply-To: <20110926191737.GA4562@albatros> Quoting Vasiliy Kulikov (segoon@openwall.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
WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serge.hallyn@canonical.com> To: Vasiliy Kulikov <segoon@openwall.com> Cc: Serge Hallyn <serge@hallyn.com>, akpm@osdl.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, containers@lists.linux-foundation.org, dhowells@redhat.com, ebiederm@xmission.com, rdunlap@xenotime.net, kernel-hardening@lists.openwall.com Subject: [kernel-hardening] Re: [PATCH 01/15] add Documentation/namespaces/user_namespace.txt (v3) Date: Tue, 27 Sep 2011 08:21:57 -0500 [thread overview] Message-ID: <20110927132157.GB3111@sergelap> (raw) In-Reply-To: <20110926191737.GA4562@albatros> Quoting Vasiliy Kulikov (segoon@openwall.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
next prev parent reply other threads:[~2011-09-27 13:22 UTC|newest] Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-09-02 19:56 user namespaces v3: continue targetting capabilities Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-02 19:56 ` (unknown), Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn [not found] ` <1314993400-6910-3-git-send-email-serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> 2011-09-02 23:49 ` missing [PATCH 01/15] Eric W. Biederman 2011-09-02 23:49 ` Eric W. Biederman [not found] ` <m11uvyld2d.fsf_-_-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org> 2011-09-03 1:09 ` Serge E. Hallyn 2011-09-03 1:09 ` Serge E. Hallyn 2011-09-02 19:56 ` [PATCH 01/15] add Documentation/namespaces/user_namespace.txt (v3) Serge Hallyn 2011-09-07 22:50 ` Andrew Morton [not found] ` <20110907155024.42e3fe27.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> 2011-09-09 13:10 ` Serge E. Hallyn 2011-09-09 13:10 ` Serge E. Hallyn [not found] ` <1314993400-6910-4-git-send-email-serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> 2011-09-07 22:50 ` Andrew Morton 2011-09-26 19:17 ` Vasiliy Kulikov 2011-09-26 19:17 ` [kernel-hardening] " Vasiliy Kulikov 2011-09-27 13:21 ` Serge E. Hallyn [this message] 2011-09-27 13:21 ` Serge E. Hallyn 2011-09-27 15:56 ` Vasiliy Kulikov 2011-09-27 15:56 ` [kernel-hardening] " Vasiliy Kulikov 2011-10-01 17:00 ` Serge E. Hallyn 2011-10-01 17:00 ` [kernel-hardening] " Serge E. Hallyn 2011-10-03 1:46 ` Eric W. Biederman 2011-10-03 1:46 ` [kernel-hardening] " Eric W. Biederman 2011-10-03 19:53 ` Eric W. Biederman 2011-10-03 19:53 ` [kernel-hardening] " Eric W. Biederman 2011-10-03 20:04 ` Serge E. Hallyn 2011-10-03 20:04 ` [kernel-hardening] " Serge E. Hallyn 2011-09-02 19:56 ` [PATCH 07/15] user namespace: use net->user_ns for some capable calls under net/ Serge Hallyn 2011-09-02 19:56 ` [PATCH 08/15] af_netlink.c: make netlink_capable userns-aware Serge Hallyn [not found] ` <1314993400-6910-1-git-send-email-serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> 2011-09-02 19:56 ` (unknown), Serge Hallyn 2011-09-02 19:56 ` [PATCH 01/15] add Documentation/namespaces/user_namespace.txt (v3) Serge Hallyn 2011-09-02 19:56 ` [PATCH 02/15] user ns: setns: move capable checks into per-ns attach helper Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-04 1:51 ` Matt Helsley [not found] ` <20110904015140.GB32295-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org> 2011-09-09 14:56 ` Serge E. Hallyn 2011-09-09 14:56 ` Serge E. Hallyn [not found] ` <1314993400-6910-5-git-send-email-serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> 2011-09-04 1:51 ` Matt Helsley 2011-09-02 19:56 ` [PATCH 03/15] keyctl: check capabilities against key's user_ns Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-02 19:56 ` [PATCH 04/15] user_ns: convert fs/attr.c to targeted capabilities Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-02 19:56 ` [PATCH 05/15] userns: clamp down users of cap_raised Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-02 19:56 ` [PATCH 06/15] user namespace: make each net (net_ns) belong to a user_ns Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-02 19:56 ` [PATCH 07/15] user namespace: use net->user_ns for some capable calls under net/ Serge Hallyn 2011-09-02 19:56 ` [PATCH 08/15] af_netlink.c: make netlink_capable userns-aware Serge Hallyn 2011-09-02 19:56 ` [PATCH 09/15] user ns: convert ipv6 to targeted capabilities Serge Hallyn 2011-09-02 19:56 ` [PATCH 10/15] net/core/scm.c: target capable() calls to user_ns owning the net_ns Serge Hallyn 2011-09-02 19:56 ` [PATCH 11/15] userns: make some net-sysfs capable calls targeted Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-02 19:56 ` [PATCH 12/15] user_ns: target af_key capability check Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-02 19:56 ` Serge Hallyn 2011-09-02 19:56 ` [PATCH 13/15] userns: net: make many network capable calls targeted Serge Hallyn 2011-09-02 19:56 ` [PATCH 14/15] net: pass user_ns to cap_netlink_recv() Serge Hallyn 2011-09-02 19:56 ` [PATCH 15/15] make kernel/signal.c user ns safe (v2) Serge Hallyn 2011-09-02 19:56 ` [PATCH 09/15] user ns: convert ipv6 to targeted capabilities Serge Hallyn 2011-09-02 19:56 ` [PATCH 10/15] net/core/scm.c: target capable() calls to user_ns owning the net_ns Serge Hallyn 2011-09-02 19:56 ` [PATCH 13/15] userns: net: make many network capable calls targeted Serge Hallyn 2011-09-02 19:56 ` [PATCH 14/15] net: pass user_ns to cap_netlink_recv() Serge Hallyn 2011-09-02 19:56 ` [PATCH 15/15] make kernel/signal.c user ns safe (v2) Serge Hallyn 2011-09-13 14:43 ` user namespaces v3: continue targetting capabilities Serge E. Hallyn
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20110927132157.GB3111@sergelap \ --to=serge.hallyn@canonical.com \ --cc=akpm@osdl.org \ --cc=containers@lists.linux-foundation.org \ --cc=dhowells@redhat.com \ --cc=ebiederm@xmission.com \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-kernel@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=rdunlap@xenotime.net \ --cc=segoon@openwall.com \ --cc=serge@hallyn.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.