From: "Serge E. Hallyn" <serge.hallyn@canonical.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Vasiliy Kulikov <segoon@openwall.com>,
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, rdunlap@xenotime.net,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH 01/15] add Documentation/namespaces/user_namespace.txt (v3)
Date: Mon, 3 Oct 2011 15:04:23 -0500 [thread overview]
Message-ID: <20111003200423.GA5880@sergelap> (raw)
In-Reply-To: <m1zkhh3l83.fsf@fess.ebiederm.org>
Quoting Eric W. Biederman (ebiederm@xmission.com):
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
> > "Serge E. Hallyn" <serge.hallyn@canonical.com> writes:
> >
> >> Quoting Vasiliy Kulikov (segoon@openwall.com):
> >>> On Tue, Sep 27, 2011 at 08:21 -0500, Serge E. Hallyn wrote:
> >>> > > 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?
> >
> > Well in theory this codes does expose this code to unprivileged user
> > space in a way that increases the attack surface. However right now
> > there are a lot of cases where because the kernel lacks a sufficient
> > mechanism people are just given root provileges so that can get things
> > done. Network manager controlling the network stack as an unprivileged
> > user. Random filesystems on usb sticks being mounted and unmounted
> > automatically when the usb sticks are inserted and removed.
> >
> > I completely agree that auditing and looking at the code is necessary I
> > think most of what will happen is that we will start directly supporting
> > how the kernel is actually used in the real world. Which should
> > actually reduce our level of vulnerability, because we give up the
> > delusion that large classes of operations don't need careful
> > attention because only root can perform them. Operations which the
> > user space authors turn around and write a suid binary for and
> > unprivileged user space performs those operations all day long.
> >
> >>> > 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.
> >>>
> >>> This is a dangerous operation by itself.
> >>
> >> Of course it is :) And it's been a while since it has been brought up,
> >> but it *was* quite well thought through and throrougly discussed - see
> >> i.e. https://lkml.org/lkml/2008/1/8/131
> >>
> >> Oh, that's right. In the end the reason it didn't go in had to do with
> >> the ability for an unprivileged user to prevent a privileged user from
> >> unmounting trees by leaving a busy mount in a hidden namespace.
> >>
> >> Eric, in the past we didn't know what to do about that, but I wonder
> >> if setns could be used in some clever way to solve it from userspace.
> >
> > Oh. That is a good objection. I had not realized that unprivileged
> > mounts had that problem.
>
> I just re-read the discussion you are referring to and that wasn't
The one I linked was one discussion, but not the final one.
https://lkml.org/lkml/2008/10/6/72 is the one where the need for
revoke is brought up.
> it. Fuse already has something like a revoke in it's umount -f
> implementation.
I'll have to (haven't yet) take a look at it.
-serge
next prev parent reply other threads:[~2011-10-03 20:04 UTC|newest]
Thread overview: 31+ 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 ` (unknown), Serge 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
2011-09-09 13:10 ` Serge E. Hallyn
2011-09-26 19:17 ` Vasiliy Kulikov
2011-09-27 13:21 ` Serge E. Hallyn
2011-09-27 15:56 ` Vasiliy Kulikov
2011-10-01 17:00 ` Serge E. Hallyn
2011-10-03 1:46 ` Eric W. Biederman
2011-10-03 19:53 ` Eric W. Biederman
2011-10-03 20:04 ` Serge E. Hallyn [this message]
[not found] ` <1314993400-6910-1-git-send-email-serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
2011-09-02 19:56 ` [PATCH 02/15] user ns: setns: move capable checks into per-ns attach helper Serge Hallyn
2011-09-04 1:51 ` Matt Helsley
2011-09-09 14:56 ` Serge E. Hallyn
2011-09-02 19:56 ` [PATCH 03/15] keyctl: check capabilities against key's user_ns 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 ` [PATCH 05/15] userns: clamp down users of cap_raised 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 ` [PATCH 11/15] userns: make some net-sysfs capable calls targeted Serge Hallyn
2011-09-02 19:56 ` [PATCH 12/15] user_ns: target af_key capability check 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 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
[not found] ` <1314993400-6910-3-git-send-email-serge@hallyn.com>
2011-09-02 23:49 ` missing [PATCH 01/15] Eric W. Biederman
2011-09-03 1:09 ` Serge E. 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=20111003200423.GA5880@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).