Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp885474pxb; Wed, 13 Jan 2021 19:27:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJwg0wIlU/N6jRayzabwVhquxM1pXQnSiMO9fSCCgO6RYHIPUqbNfh8CBlqxabI+zDzHz2ux X-Received: by 2002:a17:906:60c3:: with SMTP id f3mr3729109ejk.65.1610594827067; Wed, 13 Jan 2021 19:27:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610594827; cv=none; d=google.com; s=arc-20160816; b=m9m7ZwB5lE+1AASWFnut1OWFM1iISaN5jZMBn68tN6EUWEeeLesdG1LR7tVWz0B6iC agFOsvW8HH6EmuJVWo69MEXXkQ89UnSro+vJ7TuXJxb3GlBcz9w/ix7ORwGB+Q5GScwK 86ESjOnX3LlMcist1KpRsiMfNBk7ILlteCH9s6lB6mZ3v/gmeijybYvDTydI3QSGE6ZI VyPauAvFal2U4yNC0lbWTEQEV5cgw9Y4HTNw3WN/Ccq8Rw4J9CCgtCOJ6vOFheThYZVX J5NYVMm6w73fFoaY4V52Cu+gEF45ORjdIm1mR1PwkZNBSy4mvl+CRXlOl8c69euzFYk4 8PUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=zTCVvJXagfoiZ6eSiel9WcBpW8eVcBj2VTu0FoIa1B0=; b=XT8UyK5QRAQJPn7B+Z41H4+iVQn68I1QagR7t8YzS76rprfwuWRJDwa/v88jWqS7AT kEiCPirfNM1JDKF2oUjF7oah026Zj/2siC9f20+Sarc2B20POhAHne6olQQ+ge80O21o fAIb0ar5Tn97lJm1DpNUOwkMNqzTTgsKqKWbPo6tLNBTwVoOTfUjsFkqyugssbdsxfGP A/EZmBvzfj5vTowOWw28qcCvNNqhmxZKxMvpr6JnNZfWIEINzV1cWilM5uKRjl/t+nD2 nQ+XmlRtlIPHOa6tg44VJCF6WVgwdhYIOyY58/SV6TCgERMt62841T2U1e+BH8cifbm3 uDwA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=JiYDr2Vn; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r23si604366ejs.503.2021.01.13.19.26.44; Wed, 13 Jan 2021 19:27:07 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=JiYDr2Vn; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728118AbhANDX1 (ORCPT + 99 others); Wed, 13 Jan 2021 22:23:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34744 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727943AbhANDXW (ORCPT ); Wed, 13 Jan 2021 22:23:22 -0500 Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 31922C0617BA for ; Wed, 13 Jan 2021 19:22:29 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id p13so4954726ljg.2 for ; Wed, 13 Jan 2021 19:22:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zTCVvJXagfoiZ6eSiel9WcBpW8eVcBj2VTu0FoIa1B0=; b=JiYDr2VnqULMIy70Nb0fBwWiEy/uDdJG1fCUhZvvNsD562Bf3IBEyl7o6j2JQZmsTN EJTEtoIluw9iIvZ0MgmGLsp46TfjFR5z5tTm+A7cOaOTUHgsgWtUJpoKIfYVWVBuio1c v96AeWPCRX/2IrcIpq0WVjZ1J92LDRLgwNLFFdTcZUKRXgQ8Vdg5fbWWMyFBpmo9rEGL Lifl9OsukLAL7boxX5/8SSplzTlUkQDRml6XDCxTbUnjKde1OF3TAQy6OoQnSt4kSUkP x6ycb8D1DXdMgoeALx/O5hxSdayZvSnStvJFm1qKec2R3+0D0y6CEUIzMwm5k072M4pL ptnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zTCVvJXagfoiZ6eSiel9WcBpW8eVcBj2VTu0FoIa1B0=; b=fF1yRxx3iS+n6x9ZyF5FOgFX/PejnT5RVF1G/vJdBeaV7y1dwrnsDGdJnG/G5Ceidv SYUY93mXt1ALbB/JugZn1QnhFt+6W8gkQVS1DmyYWT3jL7weYAvKQaNEw3m0VxHcEotr OAjKmoy/7FTz5+VEoJM/SrbVi0GZPrBgZ+RmSnH0obbo9iKYN2OQIk/L7T7ZNjiMKw6F Y2I3iprHGB9wkxpBS1gHJnMJL3RGs9/WOnBDcZvIDawm28yvG3pWXrV9V70HXJ9tFlzb n7B+5UUM5jxNKs/5NjTSFowh7QGoq00LQNzgeIYdKf22DOOJ85NJSy4TGfY10E+nOdkR 6tTg== X-Gm-Message-State: AOAM530jyN+LKznME/Q/wqr8sUxgXYYbSWXSyUhZPkPrNeFvcYSKiPfA oCQ4VhpAclyIgguffHk+wHdTE/lgYbgwsWD5GxvgtQ== X-Received: by 2002:a2e:8745:: with SMTP id q5mr2118434ljj.77.1610594547372; Wed, 13 Jan 2021 19:22:27 -0800 (PST) MIME-Version: 1.0 References: <20201209192839.1396820-1-mic@digikod.net> <20201209192839.1396820-8-mic@digikod.net> In-Reply-To: <20201209192839.1396820-8-mic@digikod.net> From: Jann Horn Date: Thu, 14 Jan 2021 04:22:01 +0100 Message-ID: Subject: Re: [PATCH v26 07/12] landlock: Support filesystem access-control To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= 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?B?TWlja2HDq2wgU2FsYcO8bg==?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 9, 2020 at 8:28 PM Micka=C3=ABl Sala=C3=BCn w= rote: > 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 r= ule > + * encountered on the pathwalk grants the access, regardless of t= heir > + * 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 =3D 0; i < rule->num_layers; i++) { > + const struct landlock_layer *const layer =3D &rule->layer= s[i]; > + const u64 layer_level =3D BIT_ULL(layer->level - 1); > + > + if (!(layer_level & *layer_mask)) > + continue; > + if ((layer->access & access_request) !=3D access_request) > + return false; > + *layer_mask &=3D ~layer_level; Hmm... shouldn't the last 5 lines be replaced by the following? if ((layer->access & access_request) =3D=3D access_request) *layer_mask &=3D ~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? > + } > + return true; > +}