linux-kernel - RE: [PATCH 3/7] ima: Introduce template fields mntuidmap and mntgidmap

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: <f3dfccf2aa5f4c5b96ff6c55a222b7dd@huawei.com>
Date:   Thu, 20 May 2021 11:54:08 +0000
From:   Roberto Sassu <roberto.sassu@...wei.com>
To:     Christian Brauner <christian.brauner@...ntu.com>
CC:     "zohar@...ux.ibm.com" <zohar@...ux.ibm.com>,
        "mjg59@...f.ucam.org" <mjg59@...f.ucam.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 3/7] ima: Introduce template fields mntuidmap and
 mntgidmap

> From: Christian Brauner [mailto:christian.brauner@...ntu.com]
> Sent: Thursday, May 20, 2021 11:41 AM
> On Thu, May 20, 2021 at 11:37:07AM +0200, Christian Brauner wrote:
> > On Thu, May 20, 2021 at 10:56:57AM +0200, Roberto Sassu wrote:
> > > This patch introduces the new template fields mntuidmap and mntgidmap,
> > > which include respectively the UID and GID mappings of the idmapped
> mount,
> > > if the user namespace is not the initial one.
> > >
> > > These template fields, which should be included whenever the iuid and the
> > > igid fields are included, allow remote verifiers to find the original UID
> > > and GID of the inode during signature verification. The iuid and igid
> > > fields include the mapped UID and GID when the inode is in an idmapped
> > > mount.
> > >
> > > This solution has been preferred to providing always the original UID and
> > > GID, regardless of whether the inode is in an idmapped mount or not, as
> > > the mapped UID and GID are those seen by processes and matched with
> the IMA
> > > policy.
> >
> > Hm, looking at the code this doesn't seem like a good idea to me. I
> > think we should avoid that and just rely on the original uid and gid.
> 
> It'd be ok to include the mapped uid/gid but don't copy the mapping
> itself.

Uhm, we would need a way to obtain the original UID and GID to
verify the portable signature.

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli