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

ebiederm@xmission.com (Eric W. Biederman) writes:

"Serge E. Hallyn" [off-list ref] writes:

quoted

Quoting Vasiliy Kulikov (segoon@openwall.com):

quoted

On Tue, Sep 27, 2011 at 08:21 -0500, Serge E. Hallyn wrote:

quoted

quoted

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.

quoted

quoted

quoted

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
it.  Fuse already has something like a revoke in it's umount -f
implementation.

Eric

Quoting Eric W. Biederman (ebiederm@xmission.com):

ebiederm@xmission.com (Eric W. Biederman) writes:

quoted

"Serge E. Hallyn" [off-list ref] writes:

quoted

Quoting Vasiliy Kulikov (segoon@openwall.com):

quoted

On Tue, Sep 27, 2011 at 08:21 -0500, Serge E. Hallyn wrote:

quoted

quoted

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.

quoted

quoted

quoted

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