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 515F5C388F9 for ; Sat, 21 Nov 2020 07:00:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1C64B2225B for ; Sat, 21 Nov 2020 07:00:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="NAf9nl2J" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726596AbgKUHAY (ORCPT ); Sat, 21 Nov 2020 02:00:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726397AbgKUHAY (ORCPT ); Sat, 21 Nov 2020 02:00:24 -0500 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 B0E8DC061A4D for ; Fri, 20 Nov 2020 23:00:23 -0800 (PST) Received: by mail-lj1-x241.google.com with SMTP id h23so12389882ljg.13 for ; Fri, 20 Nov 2020 23:00:23 -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=X7o0m3hQXVmVofbCR6L473p8htdBcLYyTWc2pJqZOUM=; b=NAf9nl2J7IrdmpQMU2t/+SODdOjUjzxQqsSksle5M3l6Ywri6/LWuLY60ItJmETxox z2485qDtzcZq4U8ptX5mV32Ds+iGsHITL/G++mgluYxor/atna2PNO96gnuZ9eSDli3A 5YrOYozkM2esFvaUNe2lQ0jxlcdKo64nZZ8pWX8rKG3JIFhXACukB9nxastIxuNvxQwi m72FEnkLoHzVUECvi7NKtdHoiQma263Ss/twJenvsetmtxc+Fz3/ib+Kowi86tegJZ9T L5IzUl6TiURt6iNTyUYZjfH9tlL3oH6hVOmtT19/HgNgWR2EhrXZODwaZrS85DwyHUuy aGmw== 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=X7o0m3hQXVmVofbCR6L473p8htdBcLYyTWc2pJqZOUM=; b=oJvFte6offFIiPfX3MZiHOcLuasw6PtU3kMgWoXyeOw3HXcw4CVEYJPG6Br6wqLG9N upW+NiQ31HKFTk42l8M5BFpyr0SGqvpB9JJ86+R5uJkWXp/JbQ5SEYvZkEIZQnIhFw5y QQ2FA4QUopj/zaJrV3qQcZKoPJRQ1hIsJ6wDOgQMjwP/viRPs6TEMUCq4o+GQAervl0a ompyVGk8ABn6R3DaaMcO0pGm0XNHAGNwd2neINqtnmd89IJmfkfWogcjvecIw4BbtFGr lKZ620Ur1JwYJDs6kYGlAN1R1CtdhVpS1ZoDOLyYE2ZIujGJ5k0tPIVvbhtYTIkaKTVa phfw== X-Gm-Message-State: AOAM530Bl+CGfT0xxDT3obS5cnJMFdRWT1j175Tq7gy2mwREvumQdc9j 4PAbH2K2uXZYgtmEfGWSIL6GhxFIm7B/I6N/qiXhmA== X-Google-Smtp-Source: ABdhPJyQlluKPoz0OIWNJejUmA2oBeD6J48fIKEWng63DXZFe9Wj5F7lo9xUW1sQakHx3A+Zc/rgyFU8fgOEwoYO4Ic= X-Received: by 2002:a2e:8350:: with SMTP id l16mr9449286ljh.47.1605942021665; Fri, 20 Nov 2020 23:00:21 -0800 (PST) MIME-Version: 1.0 References: <20201112205141.775752-1-mic@digikod.net> <20201112205141.775752-2-mic@digikod.net> In-Reply-To: <20201112205141.775752-2-mic@digikod.net> From: Jann Horn Date: Sat, 21 Nov 2020 08:00:00 +0100 Message-ID: Subject: Re: [PATCH v24 01/12] landlock: Add object 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-arch@vger.kernel.org On Thu, Nov 12, 2020 at 9:51 PM Micka=C3=ABl Sala=C3=BCn = wrote: > A Landlock object enables to identify a kernel object (e.g. an inode). > A Landlock rule is a set of access rights allowed on an object. Rules > are grouped in rulesets that may be tied to a set of processes (i.e. > subjects) to enforce a scoped access-control (i.e. a domain). > > Because Landlock's goal is to empower any process (especially > unprivileged ones) to sandbox themselves, we cannot rely on a > system-wide object identification such as file extended attributes. > Indeed, we need innocuous, composable and modular access-controls. > > The main challenge with these constraints is to identify kernel objects > while this identification is useful (i.e. when a security policy makes > use of this object). But this identification data should be freed once > no policy is using it. This ephemeral tagging should not and may not be > written in the filesystem. We then need to manage the lifetime of a > rule according to the lifetime of its objects. To avoid a global lock, > this implementation make use of RCU and counters to safely reference > objects. > > A following commit uses this generic object management for inodes. > > Cc: James Morris > Cc: Kees Cook > Cc: Serge E. Hallyn > Signed-off-by: Micka=C3=ABl Sala=C3=BCn > Reviewed-by: Jann Horn Still looks good, except for one comment: [...] > + /** > + * @lock: Guards against concurrent modifications. This lock mig= ht be > + * held from the time @usage drops to zero until any weak referen= ces > + * from @underobj to this object have been cleaned up. > + * > + * Lock ordering: inode->i_lock nests inside this. > + */ > + spinlock_t lock; Why did you change this to "might be held" (v22 had "must")? Is the "might" a typo?