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=-17.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 3992AC55179 for ; Thu, 29 Oct 2020 01:08:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D92C820725 for ; Thu, 29 Oct 2020 01:08:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="MTIV5nTA" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404282AbgJ2BHo (ORCPT ); Wed, 28 Oct 2020 21:07:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404262AbgJ2BHk (ORCPT ); Wed, 28 Oct 2020 21:07:40 -0400 Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E757C0613D3 for ; Wed, 28 Oct 2020 18:07:40 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id k25so1267762lji.9 for ; Wed, 28 Oct 2020 18:07:40 -0700 (PDT) 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=JHdZPPn9wLM8C261Oo5ewV1obQFhVZ5ZdtkoajBWV64=; b=MTIV5nTARTLRBj0lxrRgSzGzRPYNAiPZWMkB9ep/3PqQq96Sbvp39GhCCvD9P7C/9G jSa0WHMFFRSKIlGXwo17x9mJaZSXNA2WyNRoeARNazqPz6DjPLBNsihFZKJM4DFVZ/CQ j3PNJYC6TnyMC9tXn4jy59H788ukVUiTCREIlCJtFaO+tL4gtg47eg+1qCzJX2qAaGf0 OGl7m75eU0hiHajz8+lj34XqRRj/KyofTQfSSo0wWrl+kguZAe7y41ED4NaXCYy9qrEK VBXAJUcNjw8AKl3YDslsCgKie01Tu2Qs1ciqvcEbb3HuzunIQUzDI9drOA7XrORLRfmD yjSg== 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=JHdZPPn9wLM8C261Oo5ewV1obQFhVZ5ZdtkoajBWV64=; b=SYS2PYYcwyrlNsUkl2Hzm3MJ2fYW0qMUoWGE1P5rAXc99/9xaDR8CxmGzX2NPjbEm2 gUv9RAjXH7a5JDXJjbwBMhY1/3zhyk00nfH22nMQCjUFx9DqtlQIKS56mMN1DjfgDqFU K5wGrLvidosGwAqzLoHd/bHucR+4E76gGLctNrV2jHZDS15omX5fZWCYr/CGgmQyXkEY 51ZCmn/YRc4Ru2PMCmYRJD6xTkEXC+K37oXCfHK1KZ5h9XQxDeUmOERB4nxYsbvH3DnK xayHsTuCHYVXtyOQg1sLxWRdYgp0dLUxpVpvNYpMuOJr/N9p1p6DNK/9gWfb43le/JDE 5Wng== X-Gm-Message-State: AOAM5315NagKVtUEsXUCHA30YCmWxIbeQeZbtSaCM7UbTvKF85g7Sb+W pZXZo8dCdafxKdraQ9G3gn3oQttmdB3C8PYYBmqmdQ== X-Google-Smtp-Source: ABdhPJxZF2osDmUJJYFjNdSuFzFlSzMFSQ07MX9iBFABKWDfUCx38EmD5usneiPJrsJhn41DKD8OlPb4Di5oSfLsrWI= X-Received: by 2002:a2e:8816:: with SMTP id x22mr663617ljh.377.1603933658573; Wed, 28 Oct 2020 18:07:38 -0700 (PDT) MIME-Version: 1.0 References: <20201027200358.557003-1-mic@digikod.net> <20201027200358.557003-13-mic@digikod.net> In-Reply-To: <20201027200358.557003-13-mic@digikod.net> From: Jann Horn Date: Thu, 29 Oct 2020 02:07:11 +0100 Message-ID: Subject: Re: [PATCH v22 12/12] landlock: Add user and kernel documentation 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 Tue, Oct 27, 2020 at 9:04 PM Micka=C3=ABl Sala=C3=BCn = 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=C3=ABl Sala=C3=BCn > Reviewed-by: Vincent Dagonneau [...] > diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/use= rspace-api/landlock.rst [...] > +Landlock rules > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > +A Landlock rule enables to describe an action on an object. An object i= s s/enables to describe/describes/ > +currently a file hierarchy, and the related filesystem actions are defin= ed 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 th= is > +example, the ruleset will contain rules which only allow read actions, b= ut > +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? 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? [...] > +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/ > +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 thi= s 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 inheritanc= e (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 secur= ity s/sandbox/sandboxes/ s/grantee/guarantee/ > +policy will stay enforced on all this thread's descendants. This enable= s to > +create standalone and modular security policies per application, which w= ill s/enables to create/allows creating/ > +automatically be composed between themselves according to their runtime = parent > +policies.