linux-toradex.git/kernel/user_namespace.c, branch v3.8.12

userns: Changing any namespace id mappings should require privileges

2013-04-25T19:51:23+00:00

commit 41c21e351e79004dbb4efa4bc14a53a7e0af38c5 upstream.

Changing uid/gid/projid mappings doesn't change your id within the
namespace; it reconfigures the namespace.  Unprivileged programs should
*not* be able to write these files.  (We're also checking the privileges
on the wrong task.)

Given the write-once nature of these files and the other security
checks, this is likely impossible to usefully exploit.

Signed-off-by: Andy Lutomirski 
Signed-off-by: Greg Kroah-Hartman

userns: Check uid_map's opener's fsuid, not the current fsuid

2013-04-25T19:51:23+00:00

commit e3211c120a85b792978bcb4be7b2886df18d27f0 upstream.

Signed-off-by: Andy Lutomirski 
Signed-off-by: Greg Kroah-Hartman

userns: Don't let unprivileged users trick privileged users into setting the id_map

2013-04-25T19:51:23+00:00

commit 6708075f104c3c9b04b23336bb0366ca30c3931b upstream.

When we require privilege for setting /proc//uid_map or
/proc//gid_map no longer allow an unprivileged user to
open the file and pass it to a privileged program to write
to the file.

Instead when privilege is required require both the opener and the
writer to have the necessary capabilities.

I have tested this code and verified that setting /proc//uid_map
fails when an unprivileged user opens the file and a privielged user
attempts to set the mapping, that unprivileged users can still map
their own id, and that a privileged users can still setup an arbitrary
mapping.

Reported-by: Andy Lutomirski 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Andy Lutomirski 
Signed-off-by: Greg Kroah-Hartman

userns: Restrict when proc and sysfs can be mounted

2013-04-05T16:26:02+00:00

commit 87a8ebd637dafc255070f503909a053cf0d98d3f upstream.

Only allow unprivileged mounts of proc and sysfs if they are already
mounted when the user namespace is created.

proc and sysfs are interesting because they have content that is
per namespace, and so fresh mounts are needed when new namespaces
are created while at the same time proc and sysfs have content that
is shared between every instance.

Respect the policy of who may see the shared content of proc and sysfs
by only allowing new mounts if there was an existing mount at the time
the user namespace was created.

In practice there are only two interesting cases: proc and sysfs are
mounted at their usual places, proc and sysfs are not mounted at all
(some form of mount namespace jail).

Acked-by: Serge Hallyn 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Greg Kroah-Hartman

userns: Don't allow creation if the user is chrooted

2013-04-05T16:26:01+00:00

commit 3151527ee007b73a0ebd296010f1c0454a919c7d upstream.

Guarantee that the policy of which files may be access that is
established by setting the root directory will not be violated
by user namespaces by verifying that the root directory points
to the root of the mount namespace at the time of user namespace
creation.

Changing the root is a privileged operation, and as a matter of policy
it serves to limit unprivileged processes to files below the current
root directory.

For reasons of simplicity and comprehensibility the privilege to
change the root directory is gated solely on the CAP_SYS_CHROOT
capability in the user namespace.  Therefore when creating a user
namespace we must ensure that the policy of which files may be access
can not be violated by changing the root directory.

Anyone who runs a processes in a chroot and would like to use user
namespace can setup the same view of filesystems with a mount
namespace instead.  With this result that this is not a practical
limitation for using user namespaces.

Acked-by: Serge Hallyn 
Reported-by: Andy Lutomirski 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Greg Kroah-Hartman

userns: Don't allow CLONE_NEWUSER | CLONE_FS

2013-03-14T18:26:37+00:00

commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71 upstream.

Don't allowing sharing the root directory with processes in a
different user namespace.  There doesn't seem to be any point, and to
allow it would require the overhead of putting a user namespace
reference in fs_struct (for permission checks) and incrementing that
reference count on practically every call to fork.

So just perform the inexpensive test of forbidding sharing fs_struct
acrosss processes in different user namespaces.  We already disallow
other forms of threading when unsharing a user namespace so this
should be no real burden in practice.

This updates setns, clone, and unshare to disallow multiple user
namespaces sharing an fs_struct.

Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

userns: Fix typo in description of the limitation of userns_install

2012-12-15T02:36:36+00:00

Acked-by: Serge Hallyn 
Signed-off-by: "Eric W. Biederman"

proc: Usable inode numbers for the namespace file descriptors.

2012-11-20T12:19:49+00:00

Assign a unique proc inode to each namespace, and use that
inode number to ensure we only allocate at most one proc
inode for every namespace in proc.

A single proc inode per namespace allows userspace to test
to see if two processes are in the same namespace.

This has been a long requested feature and only blocked because
a naive implementation would put the id in a global space and
would ultimately require having a namespace for the names of
namespaces, making migration and certain virtualization tricks
impossible.

We still don't have per superblock inode numbers for proc, which
appears necessary for application unaware checkpoint/restart and
migrations (if the application is using namespace file descriptors)
but that is now allowd by the design if it becomes important.

I have preallocated the ipc and uts initial proc inode numbers so
their structures can be statically initialized.

Signed-off-by: Eric W. Biederman

userns: For /proc/self/{uid,gid}_map derive the lower userns from the struct file

2012-11-20T12:18:55+00:00

To keep things sane in the context of file descriptor passing derive the
user namespace that uids are mapped into from the opener of the file
instead of from current.

When writing to the maps file the lower user namespace must always
be the parent user namespace, or setting the mapping simply does
not make sense.  Enforce that the opener of the file was in
the parent user namespace or the user namespace whose mapping
is being set.

Acked-by: Serge E. Hallyn 
Signed-off-by: "Eric W. Biederman"

userns: Implement unshare of the user namespace

2012-11-20T12:18:14+00:00

- Add CLONE_THREAD to the unshare flags if CLONE_NEWUSER is selected
  As changing user namespaces is only valid if all there is only
  a single thread.
- Restore the code to add CLONE_VM if CLONE_THREAD is selected and
  the code to addCLONE_SIGHAND if CLONE_VM is selected.
  Making the constraints in the code clear.

Acked-by: Serge Hallyn 
Signed-off-by: "Eric W. Biederman"