Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp365211pxj; Thu, 20 May 2021 11:05:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxNDkLCawzYcovyjXRZF+KXP00BWfHo+THCSc0JO9+nfQP4uFqHUfoKq6TINcIVqxYsbICq X-Received: by 2002:a92:d18a:: with SMTP id z10mr5538921ilz.70.1621533914073; Thu, 20 May 2021 11:05:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621533914; cv=none; d=google.com; s=arc-20160816; b=dVXezEQui5E+E4JD1jiU4KNXlge9k8ZR3kqgEN5+jczzoRyxiXIwUG89oP3kBJPa4Y 2pemwWrT153Po811WDmevqgDtfAGr7Zmfh+s/w1T0YFulInb7pZkPDo3Go/6bRsdnF8U vdRqRIwW4cAItPNvVvskCZ0Hn02PW9XdIRZR5JnDnEEKaZLvHMl4yuBzShbM2I/pimhZ monACuYIvSSVwkaYDtUInM3ZXobHIUrdckAsDyfeiBcYIszh2a8y8VLebKQC97dUuXw3 IKHtFcztXrDnTypjJ8XaKp+Lu9ztzzEZk5O+pvlVUnqHyYkHRJt+aAzO4iW2pjNomLA7 f//g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=vynvmWGhcWiod2G1tP72HZGMwfBrQWgT1XUMHF3UbZ0=; b=adjl1oPReZdAxIPO+s8givGqPXZ9HVG4t5YL0+JHorKGutM4R8tCmXdj+beLkZKNj+ /3/7QJ+Q0EE8q/Bo/cJA/LpCnhp9xedkX5CNOKYt38w8PI8KSs0L3eN5D4A2Foqr7Ws/ HN/bfiIzS/2pxZtyiZ6PPX23ZfNRFLtm7esU2SWtMAy35yOOnPXpTLFoDrR8qTOm84/U VQy/PAzFP9GathFwva7SFL42tPMZTt5uJbAldmj46/uWB0wZZ5sVkAC185oDVXq48JXn gf7GEFVOj4ZGIPYmSmdMS9oozhPz/3z8WpHPpqeszk/rAOC9DAkXEA0WkKv6MPneiq/s 0leQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j24si3117376jad.22.2021.05.20.11.04.58; Thu, 20 May 2021 11:05:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234843AbhETKNE (ORCPT + 99 others); Thu, 20 May 2021 06:13:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:37280 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235585AbhETKFY (ORCPT ); Thu, 20 May 2021 06:05:24 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 09C3D61353; Thu, 20 May 2021 09:41:08 +0000 (UTC) Date: Thu, 20 May 2021 11:41:05 +0200 From: Christian Brauner To: Roberto Sassu Cc: zohar@linux.ibm.com, mjg59@srcf.ucam.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/7] ima: Introduce template fields mntuidmap and mntgidmap Message-ID: <20210520094105.x2k3bc53xejfl5b2@wittgenstein> References: <20210520085701.465369-1-roberto.sassu@huawei.com> <20210520085701.465369-4-roberto.sassu@huawei.com> <20210520093659.oeeytegx2tvzp33e@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210520093659.oeeytegx2tvzp33e@wittgenstein> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.