[lkml]   [2011]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectuser namespaces: fix some uid/privilege leaks
The set of patches which I'm currently aiming to get upstream is queued at:;a=shortlog;h=refs/heads/userns

In the below descriptions, it helps to remember that a task can have more
privilege to his own, child, user namespace, than he does in his parent or
the initial user namespace. In fact a task created in a new user namespace
receives all capabilities (within bounding set) in the new user namespace.
So checks for privilege in a task's own user ns can not be safely used in place
of checks against another user ns.

The set includes:

Fix a case where a pid could be referenced after being freed.
(This is in Greg's usb tree, but not yet in Linus' tree; it's
here just to show full context)

Take the user namespace into account when comparing uids when
signals are sent by usb urbs.
(This is in Greg's usb tree, but not yet in Linus' tree; it's
here just to show full context)

This convers the uid for the task sending a signal to the
user namespace of the receiver. It is somewhat analogous
to what is done with the sender's pid.
Waiting on feedback from Oleg, but I believe this patch is

This prevents root in a child user namespace from man-handling
sysctls. With this patch, a task in a child user namespace
will only get the world access rights to sysctls.

This clamps down on cases where privilege to your own user
namespace were checked for access to the initial user namespace.


This adds a struct user_namespace pointer to the net_ns for use
by later patches.

Now that net_ns is owned by a user_ns, cap_netlink_recv() can
target privilege checks to the user_ns owning the resource. The
current check against current_cap() is unsafe.

In scm_send, uids of sender/receiver are being compared without
accounting for different user namespaces. Fix that.

 \ /
  Last update: 2011-10-18 23:59    [W:0.130 / U:4.456 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site