Wed Feb 23 10:27:47 PST 2011
identifiers uid, gid, capabilities, security keys?, security labels?
logically belong to the user namespace.
Which means in implementing there are two pieces of work in implementing
the user namespace.
- Find all of the interesting comparisons and change them from
"if (id == id)" to "if (userns == userns) && (id == id)".
- Potentially define and handle what happens when you mix user
I think for the first round of this we simply want to define lsms
and the user namespace as not mixing or the lsm interfaces only being
visible if you are in the initial user namespace. Thus reserving the
definition of what happens when you have lsms and multiple user
namespaces as something we can define later. I expect the proper
definition is something that would allow nested lsm policy.
Regardless. The namespaces are all about making the identifiers that
processes deal with local to the namespace, while the underlying object
manipulations should not care.
The big advantage of the user namespace is that it is the only way I can
see to get us out of the bind we are in with suid root executables,
where we can not enable new features to untrusted applications that can
change the environment for a suid root executable, because it might
confuse those suid root executables to misusing their power. Once
inside a user namespace nothing has dangerous powers because even a
root owned process with a full set of capabilities is less powerful than
a guest user outside of the namespace. No process having dangerous
powers allows us to enable unsharing of other namespaces and potentially
other things that today are restricted with capabilities only because
they can be used to confuse a privileged executable to do something
More information about the Containers