[kernel-hardening] Re: [PATCH 01/15] add Documentation/namespaces/user_namespace.txt (v3)

["Serge E. Hallyn" <serge.hallyn@canonical.com>]

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