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=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,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 29DD8C388F9 for ; Sat, 21 Nov 2020 07:01:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E3E3122226 for ; Sat, 21 Nov 2020 07:01:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="QTrvEtnW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727228AbgKUHBg (ORCPT ); Sat, 21 Nov 2020 02:01:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44618 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727164AbgKUHBf (ORCPT ); Sat, 21 Nov 2020 02:01:35 -0500 Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04C6CC061A48 for ; Fri, 20 Nov 2020 23:01:35 -0800 (PST) Received: by mail-lf1-x143.google.com with SMTP id t6so503608lfl.13 for ; Fri, 20 Nov 2020 23:01:34 -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=3f33ZbSviSsNDuxIsWsq/8c0yuXyzvCPrqPtP0RGi80=; b=QTrvEtnWrrcbOEs5U2zsXrELZY0joXKYt35ttFIfE3ljFGqVTsE2HaDPetDIzNV0Z+ SNm0nIBKP392yJ/12exSP2lHAsN3IW99XL9OvKJShdVvhx6hWk5FMgqMLPmf5TLsXGFG +iHnXGnR267ovUqsrTD7TknzGTTVMN0JBhDcMHYa6hy9vumiKnlHEoByxwYUqFCeOJcH 8ci6aX3IWWZAS35E7ZUq2QiVC5E+16bSvaDHHgcz3hRf5R5Sqdh41qyVdf7c65t3ii9K kE9FBm0MLZ2YAKu0t3JfnrIMbZ8lpvjGGU8/1aoQSH1X5Qz/sPTU1Mx00P4k2W69USLS xiIw== 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=3f33ZbSviSsNDuxIsWsq/8c0yuXyzvCPrqPtP0RGi80=; b=bsIA0p+OW+5FDAw6HlECBgY4U1yrBFzR8Pq/P8GctCIzMb9Nto231RFoomeb4BbhJ0 MXh3BZDu8CrvPCqNsXjRCvltnNfpmB6gzqOdJjHnHamIdYywr8ut55oTW4Ggn/oSEqDj NwB3w4mJwh9zzJmsh8q1jdMuInUf4A11c65Wu+GDB3BOOzsPGMtQvsU3Xey4MQR6iM2W covgF6Etlg6dbF1BsdGqSdo3yNnqqz/w667q/vqgdkzC7itBx0Q72oa3v9RvAgEt1LT2 Fqife9JMvVUYk4o/8hcI3zw9hztALiw5oxhVHwSHy63Nep9XJ1I6ttg1Tr2Wh1KaS0NC ozBA== X-Gm-Message-State: AOAM533u8z9hXxlPEUamIsAx65BaucmyB7G/UJDGxKF1TOTbxSkS5sBD vnO6DQzdD+nwW5h4X8/xPar6bvAWlxgaBcuR+rxPQg== X-Google-Smtp-Source: ABdhPJyH6REifnL9YUZNnFhyFBr7a5RSsJd6XuGMTDWn4PlB6riGiZRNf+nR+kcYWzMs0Zs7hbAeG+15z4SfiIciuC8= X-Received: by 2002:a19:4b48:: with SMTP id y69mr9985268lfa.576.1605942093292; Fri, 20 Nov 2020 23:01:33 -0800 (PST) MIME-Version: 1.0 References: <20201112205141.775752-1-mic@digikod.net> <20201112205141.775752-3-mic@digikod.net> In-Reply-To: <20201112205141.775752-3-mic@digikod.net> From: Jann Horn Date: Sat, 21 Nov 2020 08:00:00 +0100 Message-ID: Subject: Re: [PATCH v24 02/12] landlock: Add ruleset and domain management 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 Thu, Nov 12, 2020 at 9:51 PM Micka=C3=ABl Sala=C3=BCn = wrote: > A Landlock ruleset is mainly a red-black tree with Landlock rules as > nodes. This enables quick update and lookup to match a requested > access, e.g. to a file. A ruleset is usable through a dedicated file > descriptor (cf. following commit implementing syscalls) which enables a > process to create and populate a ruleset with new rules. > > A domain is a ruleset tied to a set of processes. This group of rules > defines the security policy enforced on these processes and their future > children. A domain can transition to a new domain which is the > intersection of all its constraints and those of a ruleset provided by > the current process. This modification only impact the current process. > This means that a process can only gain more constraints (i.e. lose > accesses) over time. > > Cc: James Morris > Cc: Jann Horn > Cc: Kees Cook > Cc: Serge E. Hallyn > Signed-off-by: Micka=C3=ABl Sala=C3=BCn > --- > > Changes since v23: > * Always intersect access rights. Following the filesystem change > logic, make ruleset updates more consistent by always intersecting > access rights (boolean AND) instead of combining them (boolean OR) for > the same layer. This seems wrong to me. If some software e.g. builds a policy that allows it to execute specific libraries and to open input files specified on the command line, and the user then specifies a library as an input file, this change will make that fail unless the software explicitly deduplicates the rules. Userspace will be forced to add extra complexity to work around this. > This defensive approach could also help avoid user > space to inadvertently allow multiple access rights for the same > object (e.g. write and execute access on a path hierarchy) instead of > dealing with such inconsistency. This can happen when there is no > deduplication of objects (e.g. paths and underlying inodes) whereas > they get different access rights with landlock_add_rule(2). I don't see why that's an issue. If userspace wants to be able to access the same object in different ways for different purposes, it should be able to do that, no? I liked the semantics from the previous version.