linux-kernel - Re: [PATCH 0/3] Enable namespaced file capabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOQ4uxj=_Riih1K+QOYasZU8vZKCSrsg393f=17mJ2O-909e=Q@mail.gmail.com>
Date:   Fri, 23 Jun 2017 10:01:46 +0300
From:   Amir Goldstein <amir73il@...il.com>
To:     Stefan Berger <stefanb@...ux.vnet.ibm.com>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Linux Containers <containers@...ts.linux-foundation.org>,
        lkp@...org, xiaolong.ye@...el.com,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Tycho Andersen <tycho@...ker.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        christian.brauner@...lbox.org, Vivek Goyal <vgoyal@...hat.com>,
        LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 0/3] Enable namespaced file capabilities

On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
<stefanb@...ux.vnet.ibm.com> wrote:
> 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@...=1000 for root mapped to uid 1000 on the host.
> When listing the xattrs on the host, the existing security.capability
> as well as the security.capability@...=1000 will be shown. Inside the
> namespace only 'security.capability', with the value of
> security.capability@...=1000, is visible.
>

Am I the only one who thinks that suffix is perhaps not the best grammar
to use for this namespace?
xattrs are clearly namespaced by prefix, so it seems right to me to keep
it that way - define a new special xattr namespace "ns" and only if that
prefix exists, the @uid suffix will be parsed.
This could be either  ns.security.capability@...=1000 or
ns@...=1000.security.capability. The latter seems more correct to me,
because then we will be able to namespace any xattr without having to
protect from "unprivileged xattr injection", i.e.:
setfattr -n "user.whatever.foo@...=0"

Amir.