From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80FD4C433E6 for ; Thu, 14 Jan 2021 19:02:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5791523B31 for ; Thu, 14 Jan 2021 19:02:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729731AbhANTCC (ORCPT ); Thu, 14 Jan 2021 14:02:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729282AbhANTCC (ORCPT ); Thu, 14 Jan 2021 14:02:02 -0500 X-Greylist: delayed 386 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Thu, 14 Jan 2021 11:01:16 PST Received: from smtp-190e.mail.infomaniak.ch (smtp-190e.mail.infomaniak.ch [IPv6:2001:1600:4:17::190e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB5CCC061575 for ; Thu, 14 Jan 2021 11:01:16 -0800 (PST) Received: from smtp-3-0001.mail.infomaniak.ch (unknown [10.4.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4DGtls2KsZzMq8XJ; Thu, 14 Jan 2021 19:54:49 +0100 (CET) Received: from ns3096276.ip-94-23-54.eu (unknown [23.97.221.149]) by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4DGtlp18bWzlh8T2; Thu, 14 Jan 2021 19:54:46 +0100 (CET) Subject: Re: [PATCH v26 07/12] landlock: Support filesystem access-control To: Jann Horn Cc: James Morris , "Serge E . Hallyn" , Al Viro , Andy Lutomirski , Anton Ivanov , Arnd Bergmann , Casey Schaufler , Jeff Dike , Jonathan Corbet , Kees Cook , Michael Kerrisk , Richard Weinberger , Shuah Khan , Vincent Dagonneau , Kernel Hardening , Linux API , linux-arch , "open list:DOCUMENTATION" , linux-fsdevel , kernel list , "open list:KERNEL SELFTEST FRAMEWORK" , linux-security-module , the arch/x86 maintainers , =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= References: <20201209192839.1396820-1-mic@digikod.net> <20201209192839.1396820-8-mic@digikod.net> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: Date: Thu, 14 Jan 2021 19:54:36 +0100 User-Agent: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On 14/01/2021 04:22, Jann Horn wrote: > On Wed, Dec 9, 2020 at 8:28 PM Mickaël Salaün wrote: >> Thanks to the Landlock objects and ruleset, it is possible to identify >> inodes according to a process's domain. To enable an unprivileged >> 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. >> >> This commit adds a minimal set of supported filesystem access-control >> which doesn't enable to restrict all file-related actions. This is the >> result of multiple discussions to minimize the code of Landlock to ease >> review. Thanks to the Landlock design, extending this access-control >> without breaking user space will not be a problem. Moreover, seccomp >> filters can be used to restrict the use of syscall families which may >> not be currently handled by Landlock. > [...] >> +static bool check_access_path_continue( >> + const struct landlock_ruleset *const domain, >> + const struct path *const path, const u32 access_request, >> + u64 *const layer_mask) >> +{ > [...] >> + /* >> + * An access is granted if, for each policy layer, at least one rule >> + * encountered on the pathwalk grants the access, regardless of their >> + * position in the layer stack. We must then check not-yet-seen layers >> + * for each inode, from the last one added to the first one. >> + */ >> + for (i = 0; i < rule->num_layers; i++) { >> + const struct landlock_layer *const layer = &rule->layers[i]; >> + const u64 layer_level = BIT_ULL(layer->level - 1); >> + >> + if (!(layer_level & *layer_mask)) >> + continue; >> + if ((layer->access & access_request) != access_request) >> + return false; >> + *layer_mask &= ~layer_level; > > Hmm... shouldn't the last 5 lines be replaced by the following? > > if ((layer->access & access_request) == access_request) > *layer_mask &= ~layer_level; > > And then, since this function would always return true, you could > change its return type to "void". > > > As far as I can tell, the current version will still, if a ruleset > looks like this: > > /usr read+write > /usr/lib/ read > > reject write access to /usr/lib, right? If these two rules are from different layers, then yes it would work as intended. However, if these rules are from the same layer the path walk will not stop at /usr/lib but go down to /usr, which grants write access. This is the reason I wrote it like this and the layout1.inherit_subset test checks that. I'm updating the documentation to better explain how an access is checked with one or multiple layers. Doing this way also enables to stop the path walk earlier, which is the original purpose of this function. > > >> + } >> + return true; >> +}