From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-190a.mail.infomaniak.ch (smtp-190a.mail.infomaniak.ch [185.125.25.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5450DDDAD for ; Sat, 8 Mar 2025 18:57:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.125.25.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741460238; cv=none; b=hrSePqE491slqs40GpcTlYK+WU6n4TMjJEt15GCRkCYJSrmWjnjQVg2CJYt1V6D98mWR0trupUnuD7gMfoF536jtNVaD3/gEmUWw4Lz9Gdp+d5Y/vARHQDzeX6hvpMIt5vS81zLoln+AVeF4nKfY8xS67L/8J42PlOQHgO9uajI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741460238; c=relaxed/simple; bh=gukEbJdIrNo8TUJiZWYqSy4aqoaDDcj8Y9luVRYS4Qs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EvxwyMwZ5M3N1+MaV8Al8z272/tw4JpIYGYqcVFl/DJ2QP4tfjR2iyvUXU4IQUdUVyxsxFqYyl9S77Y1Tex/aujgF+fbwXBZurxaQmWczO5nOc2DD3EwA6qTBuCp9VI3Rt7sODAW3eKeOJ6c0g7a7k5ftCWtpVyxWwB5nBeJiPk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net; spf=pass smtp.mailfrom=digikod.net; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b=Uo+pXjYW; arc=none smtp.client-ip=185.125.25.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=digikod.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b="Uo+pXjYW" Received: from smtp-3-0001.mail.infomaniak.ch (smtp-3-0001.mail.infomaniak.ch [10.4.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4Z9C7t3YB4zV4m; Sat, 8 Mar 2025 19:57:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digikod.net; s=20191114; t=1741460234; bh=wN0FXOm2E/56qbhYEzbybQfDtSOz1RXoy+kYKm4jync=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Uo+pXjYWr6tOlOaB0PAeSOOHy2v15fZUvnsckilyi0e9fYG4I7LwqN/6QW5Pwc7fZ imkdgwxT3BOTE+pv4h130e+sMI1epOejqwKAEYToW5tIc5Fp0uLhaGK90/LJGyE0Rz VRj1PEwQ704HLsVQqBGZaZ3p0APyObEtBJUaPYrY= Received: from unknown by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4Z9C7s70lLz3Kv; Sat, 8 Mar 2025 19:57:13 +0100 (CET) Date: Sat, 8 Mar 2025 19:57:13 +0100 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Tingmao Wang Cc: =?utf-8?Q?G=C3=BCnther?= Noack , Jan Kara , linux-security-module@vger.kernel.org, Amir Goldstein , Matthew Bobrowski , linux-fsdevel@vger.kernel.org, Tycho Andersen , Christian Brauner , Kees Cook , Jann Horn , Andy Lutomirski Subject: Re: [RFC PATCH 2/9] Refactor per-layer information in rulesets and rules Message-ID: <20250306.aeth4Thaepae@digikod.net> References: <6e8887f204c9fbe7470e61876bc597932a8f74d9.1741047969.git.m@maowtm.org> <20250304.aiGhah9lohh5@digikod.net> <4e0ed692-50e7-4665-962b-3cc1694e441a@maowtm.org> Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4e0ed692-50e7-4665-962b-3cc1694e441a@maowtm.org> X-Infomaniak-Routing: alpha On Thu, Mar 06, 2025 at 02:58:01AM +0000, Tingmao Wang wrote: > On 3/4/25 19:49, Mickaël Salaün wrote: > > > We could indeed have a pointer in the landlock_hierarchy and have a > > dedicated bit in each layer's access_masks to indicate that this layer > > is supervised. This should simplify the whole patch series. > > That seems sensible. I did consider using the landlock_hierarchy, but chose > the current way as it initially seemed more sensible, but on second thought > this means that we have to carefully increment all the refcounts on domain > merge etc. On the other hand storing the supervisor pointer in the > hierarchy, if we have an extra bit in struct access_masks then we can > quickly determine if supervisors are involved without effectively walking a > linked list, which is nice. Right > > Actually, just to check, is the reason why we have the access_masks FAM in > the ruleset purely for performance? Initially I wasn't sure if each layer > correspond 1-to-1 with landlock_hierarchy, since otherwise it seemed to me > you could just put the access mask in the hierarchy too. Yes, we could put the access rights in the hierarchy, but that would involve walking through the hierarchy to know if Landlock should actually handle (i.e. allow or potentially deny) an access request. Landlock is designed in a way that makes legitimate/allowed access as fast as possible (there is still room for improvement though). In the case of the supervisor feature, it should mainly be used to dynamically allow access which are statically denied for one layer. And because it will require a round trip to user space anyway, the performance impact of putting the supervisor pointer in landlock_hierarchy is negligible. Initially the purpose of landlock_hierarchy was to be able to compare domains (for ptrace and later scope restrictions), whereas the landlock_ruleset is to store immutable data (without references) when used as a domain. With the audit feature, the landlock_hierarchy will also contain domain's shared/mutable states and pointers that should only be rarely accessed (i.e. only for denials). So, in a nutshell landlock_ruleset as a domain should stay minimal and improve data locality to speed up allowed access requests. We could decorrelate the current content of landlock_hierarchy from the shared data, but I think it would only be meaningful if this data is significant (see the landlock_details pointer in the audit patch series). > In other words, is it right to assume that, if a domain has 3 layers, for > example, then domain->hierarchy correspond to the third layer, > domain->hierarchy->parent correspond to the second, and > d->h->parent->parent would be the first layer's hierarchy? Yes, that is always the case for a domain. If we create the supervisor FD with landlock_restrict_self(2), then we'll not have to add a new pointer to landlock_ruleset, but only directly to landlock_hierarchy.