linux-kernel - Re: [PATCH v4] Introduce v3 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: <20170613204612.uztqywc7topa6g2h@smitten>
Date:   Tue, 13 Jun 2017 14:46:12 -0600
From:   Tycho Andersen <tycho@...ker.com>
To:     James Bottomley <James.Bottomley@...senPartnership.com>
Cc:     Stefan Berger <stefanb@...ux.vnet.ibm.com>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        containers@...ts.linux-foundation.org,
        LKML <linux-kernel@...r.kernel.org>, xiaolong.ye@...el.com,
        "Eric W. Biederman" <ebiederm@...ssion.com>, lkp@...org
Subject: Re: [PATCH v4] Introduce v3 namespaced file capabilities

On Tue, Jun 13, 2017 at 10:45:02AM -0700, James Bottomley wrote:
> On Tue, 2017-06-13 at 11:14 -0600, Tycho Andersen via Containers wrote:
> > Hi Stefan,
> > 
> > On Tue, Jun 13, 2017 at 11:47:26AM -0400, Stefan Berger wrote:
> > > On 05/08/2017 02:11 PM, Serge E. Hallyn wrote:
> > > > Root in a non-initial user ns cannot be trusted to write a 
> > > > traditional security.capability xattr.  If it were allowed to do 
> > > > so, then any unprivileged user on the host could map his own uid 
> > > > to root in a private namespace, write the xattr, and execute the 
> > > > file with privilege on the host.
> > > > 
> > > > However supporting file capabilities in a user namespace is very
> > > > desirable.  Not doing so means that any programs designed to run 
> > > > with limited privilege must continue to support other methods of
> > > > gaining and dropping privilege.  For instance a program installer 
> > > > must detect whether file capabilities can be assigned, and assign 
> > > > them if so but set setuid-root otherwise.  The program in turn 
> > > > must know how to drop partial capabilities, and do so only if
> > > > setuid-root.
> > > 
> > > Hi Serge,
> > > 
> > > 
> > >   I have been looking at patch below primarily to learn how we 
> > > could apply a similar technique to security.ima and security.evm 
> > > for a namespaced IMA. From the paragraphs above I thought that you 
> > > solved the problem of a shared filesystem where one now can write 
> > > different security.capability xattrs by effectively supporting for 
> > > example security.capability[uid=1000] and
> > > security.capability[uid=2000] written into the filesystem. Each
> > > would then become visible as security.capability if the userns 
> > > mapping is set appropriately.
> > 
> > One disadvantage of this approach is that whoever is setting up the
> > container would need to go touch the security.ima attribute for each
> > file in the contianer, which would slow down container creation time.
> > For capabilities this makes sense, because you might want the file to
> > have different capabilities in different namespaces, but for IMA,
> > since the file hash will be the same in every namespace,
> 
> Actually, this isn't necessarily true: IMA may have the hash, you're
> right, but I suspect in most container use cases it will have the
> signature.  It's definitely a use case that the container will be using
> a different keyring from the host, so different signatures are surely
> possible for the same underlying image file.
> 
> One might imagine doing the above via overlays, because the new
> signature should override the old.

Yes, good point, thanks. Assuming the container and the host are using
the same keyring, we could design it in such a way that the container
engine doesn't need to touch every file on creation, which would be
very nice.

Tycho