Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1583442pxb; Wed, 10 Feb 2021 11:43:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJxz/XJK1K8K3ZqpfXRpDao1n7mQ/pyAJ+M3oTWfPq21psHBcNlbFb40Q4by6ZrES96/z4gg X-Received: by 2002:a17:906:3719:: with SMTP id d25mr4700943ejc.256.1612986186394; Wed, 10 Feb 2021 11:43:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612986186; cv=none; d=google.com; s=arc-20160816; b=T2ERxWJ+TzbbMaZvNd14p1WtvVpZw8GXe2vGcwuCZce4wdm/W7j4+XfP4195LerEc1 UPDhg/ff7/xMWC1k5/AUEfeJPPD8Uda+NiQuBlT715V2pTrA3rU8yTBW5mk9P8lTmmfQ gMEq+eEe9tHWL34Lp9DNus6Xu6EhO00ZRrNgbxsJdnurZSE6ubeq8cFsm0wm7yyLSwfh rJADgphA3GX8P2e7s1C1PBM/xQfseX0arHmugUvDoCJEbPBQasoVmV0z3UA0FT7y9BrC dSIFc6gljeNToR8Bw3/+CTr99Suvl5qBCjoTgOL2s242ZjDBNKhR5uzZqr3LtCxvE99B BpQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=QwMKf1gE3Xp1G/iZd99CrH1Z11TOflLRbU0Az9K/eOQ=; b=vbi6U0ne9iGYeDP7fr9O1VdtHBLAPU8AkLtiTKU+PSLBlU2ZV6Lra1DEqAsAbMSO+a gT94eojuj2oTvl65qQT7ccNrEvoA4Z0pcGRAolq0udjj8h/SDpk+EG5U8T7uK2pOcLOS Q9zlUWiIciI0TEWsQcT2B/j2kU7eN9FMtIzWjyZGiWG/4UiaEfrDaW5eMG1yylmgrnbb xrMsJBWwKDwSIv5+onkcTPByvOyzQcmjTxcEc1qaIz3hD1FZFSBb6ViGK+DSi1szG3Je RCJXXeUHBtvWzzCShjQGuSSgjtNk5XyxMSq4+4nskW8++VfC5HFgKEyYoWm/QbIuYnN4 O1uw== 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 jx12si1929155ejb.247.2021.02.10.11.42.42; Wed, 10 Feb 2021 11:43:06 -0800 (PST) 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 S232292AbhBJTjk (ORCPT + 99 others); Wed, 10 Feb 2021 14:39:40 -0500 Received: from mail.hallyn.com ([178.63.66.53]:33140 "EHLO mail.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232012AbhBJTh0 (ORCPT ); Wed, 10 Feb 2021 14:37:26 -0500 Received: by mail.hallyn.com (Postfix, from userid 1001) id 8C5F421B; Wed, 10 Feb 2021 13:36:24 -0600 (CST) Date: Wed, 10 Feb 2021 13:36:24 -0600 From: "Serge E. Hallyn" To: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= Cc: James Morris , Jann Horn , "Serge E . Hallyn" , Al Viro , Andrew Morton , Andy Lutomirski , Anton Ivanov , Arnd Bergmann , Casey Schaufler , Jeff Dike , Jonathan Corbet , Kees Cook , Michael Kerrisk , Richard Weinberger , Shuah Khan , Vincent Dagonneau , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-security-module@vger.kernel.org, x86@kernel.org, =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= Subject: Re: [PATCH v28 07/12] landlock: Support filesystem access-control Message-ID: <20210210193624.GA29893@mail.hallyn.com> References: <20210202162710.657398-1-mic@digikod.net> <20210202162710.657398-8-mic@digikod.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210202162710.657398-8-mic@digikod.net> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 02, 2021 at 05:27:05PM +0100, Micka?l Sala?n wrote: > From: Micka?l Sala?n > > Thanks to the Landlock objects and ruleset, it is possible to identify > inodes according to a process's domain. To enable an unprivileged This throws me off a bit. "identify inodes according to a process's domain". What exactly does it mean? "identify" how ? > process to express a file hierarchy, it first needs to open a directory > (or a file) and pass this file descriptor to the kernel through > landlock_add_rule(2). When checking if a file access request is > allowed, we walk from the requested dentry to the real root, following > the different mount layers. The access to each "tagged" inodes are > collected according to their rule layer level, and ANDed to create > access to the requested file hierarchy. This makes possible to identify > a lot of files without tagging every inodes nor modifying the > filesystem, while still following the view and understanding the user > has from the filesystem. > > Add a new ARCH_EPHEMERAL_INODES for UML because it currently does not > keep the same struct inodes for the same inodes whereas these inodes are > in use. -serge