On 6/22/2017 1:12 PM, Stefan Berger wrote:

On 06/22/2017 03:59 PM, Casey Schaufler wrote:

quoted

On 6/22/2017 11:59 AM, Stefan Berger wrote:

quoted

This series of patches primary goal is to enable file capabilities
in user namespaces without affecting the file capabilities that are
effective on the host. This is to prevent that any unprivileged user
on the host maps his own uid to root in a private namespace, writes
the xattr, and executes the file with privilege on the host.

We achieve this goal by writing extended attributes with a different
name when a user namespace is used. If for example the root user
in a user namespace writes the security.capability xattr, the name
of the xattr that is actually written is encoded as
security.capability at uid=1000 for root mapped to uid 1000 on the host.

You need to identify the instance of the user namespace for
this to work right on a system with multiple user namespaces.
If I have a shared filesystem mounted in two different user
namespaces a change by one will affect the other.

Two different user namespaces with different uid mappings will not affect each other.

But two namespaces with the same uid mapping will, and I
don't think this meets the principle of least astonishment.
I also object to associating capabilities with UIDs. The
whole point of capabilities is to disassociate UID 0 from
privilege. What you've done is explicitly associate a UID
with the ability to have privilege. That's an architectural
regression.

If root in userns1 mapped to uid 1000 (size 1000) writes security.capability, it will write security.capability at uid=1000 into the fs.
If root in userns2 mapped to uid 2000 (size 1000) writes security.capability, it will write security.capability at uid=2000 into the fs.

Neither of the two will see each other's security.capability, but each will see their own 'security.capability'.

Assume now userns1 has a size of 2000, so overlapping with userns2, it will now see userns2's security.capability at uid=1000 as well as its own 'security.capability'. security.capability at uid=1000 (of userns2) in userns1 will not have an effect on effective file capabilities.

quoted

... unless I'm missing something obvious about namespace behavior.

quoted

When listing the xattrs on the host, the existing security.capability
as well as the security.capability at uid=1000 will be shown. Inside the
namespace only 'security.capability', with the value of
security.capability at uid=1000, is visible.

To maintain compatibility with existing behavior, the value of
security.capability of the host is shown inside the user namespace
once the security.capability of the user namespace has been removed
(which really removes security.capability at uid=1000). Writing to
an extended attribute inside a user namespace effectively hides the
extended attribute of the host.

The general framework that is established with these patches can
be applied to other extended attributes as well, such as security.ima
or the 'trusted.' prefix . Another extended attribute that needed to
be enabled here is 'security.selinux,' since otherwise this extended
attribute would not be shown anymore inside a user namespace.

Regards,
    Stefan & Serge


Stefan Berger (3):
   xattr: Enable security.capability in user namespaces
   Enable capabilities of files from shared filesystem
   Enable security.selinux in user namespaces

  fs/xattr.c               | 472 ++++++++++++++++++++++++++++++++++++++++++++++-
  security/commoncap.c     |  36 +++-
  security/selinux/hooks.c |   9 +-
  3 files changed, 501 insertions(+), 16 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html