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=-9.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 D5A35C2D0A3 for ; Thu, 29 Oct 2020 11:38:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 906E0207BC for ; Thu, 29 Oct 2020 11:38:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725890AbgJ2Liq (ORCPT ); Thu, 29 Oct 2020 07:38:46 -0400 Received: from smtp-42ac.mail.infomaniak.ch ([84.16.66.172]:59013 "EHLO smtp-42ac.mail.infomaniak.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725849AbgJ2Lid (ORCPT ); Thu, 29 Oct 2020 07:38:33 -0400 Received: from smtp-2-0001.mail.infomaniak.ch (unknown [10.5.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4CMNjx2wM5zlkXcn; Thu, 29 Oct 2020 12:38:29 +0100 (CET) Received: from ns3096276.ip-94-23-54.eu (unknown [94.23.54.103]) by smtp-2-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4CMNjv2kl6zlh8TS; Thu, 29 Oct 2020 12:38:27 +0100 (CET) Subject: Re: [PATCH v22 12/12] landlock: Add user and kernel documentation 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: <20201027200358.557003-1-mic@digikod.net> <20201027200358.557003-13-mic@digikod.net> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: Date: Thu, 29 Oct 2020 12:38:26 +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-kernel@vger.kernel.org On 29/10/2020 02:07, Jann Horn wrote: > On Tue, Oct 27, 2020 at 9:04 PM Mickaël Salaün wrote: >> This documentation can be built with the Sphinx framework. >> >> Cc: James Morris >> Cc: Jann Horn >> Cc: Kees Cook >> Cc: Serge E. Hallyn >> Signed-off-by: Mickaël Salaün >> Reviewed-by: Vincent Dagonneau > [...] >> diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst > [...] >> +Landlock rules >> +============== >> + >> +A Landlock rule enables to describe an action on an object. An object is > > s/enables to describe/describes/ OK. > >> +currently a file hierarchy, and the related filesystem actions are defined in >> +`Access rights`_. A set of rules is aggregated in a ruleset, which can then >> +restrict the thread enforcing it, and its future children. >> + >> +Defining and enforcing a security policy >> +---------------------------------------- >> + >> +We first need to create the ruleset that will contain our rules. For this >> +example, the ruleset will contain rules which only allow read actions, but >> +write actions will be denied. The ruleset then needs to handle both of these >> +kind of actions. To have a backward compatibility, these actions should be >> +ANDed with the supported ones. > > This sounds as if there is a way for userspace to discover which > actions are supported by the running kernel; but we don't have > anything like that, right? Right, it dates from the landlock_get_features(2), which is now gone but may be replaced by something else in the future. I'll remove that. > > If we want to make that possible, we could maybe change > sys_landlock_create_ruleset() so that if > ruleset_attr.handled_access_fs contains bits we don't know, we clear > those bits and then copy the struct back to userspace? And then > userspace can retry the syscall with the cleared bits? Or something > along those lines? Yes, but I would prefer clear syscall which don't read and write from/to the same argument. I'm working on a more generic solution. It should not be an issue for now. > > [...] >> +We can now add a new rule to this ruleset thanks to the returned file >> +descriptor referring to this ruleset. The rule will only enable to read the > > s/enable to read/allow reading/ OK. > >> +file hierarchy ``/usr``. Without another rule, write actions would then be >> +denied by the ruleset. To add ``/usr`` to the ruleset, we open it with the >> +``O_PATH`` flag and fill the &struct landlock_path_beneath_attr with this file >> +descriptor. > [...] >> +Inheritance >> +----------- >> + >> +Every new thread resulting from a :manpage:`clone(2)` inherits Landlock domain >> +restrictions from its parent. This is similar to the seccomp inheritance (cf. >> +:doc:`/userspace-api/seccomp_filter`) or any other LSM dealing with task's >> +:manpage:`credentials(7)`. For instance, one process's thread may apply >> +Landlock rules to itself, but they will not be automatically applied to other >> +sibling threads (unlike POSIX thread credential changes, cf. >> +:manpage:`nptl(7)`). >> + >> +When a thread sandbox itself, we have the grantee that the related security > > s/sandbox/sandboxes/ > s/grantee/guarantee/ OK. > >> +policy will stay enforced on all this thread's descendants. This enables to >> +create standalone and modular security policies per application, which will > > s/enables to create/allows creating/ OK. > > >> +automatically be composed between themselves according to their runtime parent >> +policies.