Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1834180pxb; Fri, 20 Nov 2020 23:03:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJy2ykxXZKeW7QV3BsG0XdE5bpBKmigjKF/xz/7aIQ18pO6jLNC/GlfqrsC17EiPvVvQLdJ+ X-Received: by 2002:a17:906:60c4:: with SMTP id f4mr36406277ejk.336.1605942187705; Fri, 20 Nov 2020 23:03:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605942187; cv=none; d=google.com; s=arc-20160816; b=RwpTPeQsFEtHTuQhP2YUHRDCGPTzxGNkdk9FiKosdcsLJCA3HBFI0PAOGlA18V5+Kx +PAQD7AYyK6hKL//9dEMDMSibbZ2ghWfB+cmOjKQ0PnBbDXUwfre0MHRx7DwKUvng5WE GFpElHKvZ7l5jHYKXlTWL+Ssd2hEJeFa9laiS2M2Ia9p/vOJKkBgeoqC5UmwfP7xigQt ZFZUH7t8KU1CNOjBHVEBAdTpk37FIg4MKmgHQffbSkOYFIcPbgbzReZiUaHtzL8PzsIq 4w/qNt94mdFI7ba17EX3vaycCl059Ygr2IBijM+a+NA/y/GkzoHUoKwot09UrCcC625M R4Xg== 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=X7o0m3hQXVmVofbCR6L473p8htdBcLYyTWc2pJqZOUM=; b=Scklz2t4HQ7H3PPSTKNfANvF12ELwl56+A00ygXsoiM1TaM9iAWiYxrGKKoTPB5P2a cyp++ZJmJ73VC1OLyjNBv45iEKV08djqfDKdqheUbi2DfY9PboIi/aVY3DwKy5Y4yyi0 lk0REFWuk3f2OdwUFt/eqiuyjClx/xO7a06Fqa0En+eLjny8l+iV2PbgJDPIFrwK6NPG qcnNKTNHyTe6PvFIE9TLm6RAo1VBvKI+axWNJWLAcY6BgEHf46ztlPNq78WUw8HjxExz oBnM9CHDUIPKxGHGSfGRghwgHYT65qk/gSwQ17RpQSWm3OBruam1AhI4uoM4VjdlEFDD t7NA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=NAf9nl2J; 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 i8si3117938edt.264.2020.11.20.23.02.45; Fri, 20 Nov 2020 23:03: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=NAf9nl2J; 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 S1726329AbgKUHAZ (ORCPT + 99 others); Sat, 21 Nov 2020 02:00:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44382 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726454AbgKUHAY (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 A8C05C061A4C for ; Fri, 20 Nov 2020 23:00:23 -0800 (PST) Received: by mail-lj1-x241.google.com with SMTP id i17so12445765ljd.3 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=LfRBUWJ/0ttmoH+lv8N5MCe2zrWlPhApIOFmagxCCDpx4ezaRLWczNVaWdWQELCM3v xE36S3vOfLA15TuO4h53VakiAKsnqD+/glGZoTGtCw0faB7+dhwEVeSN07C1BuyneAQ6 EA1QaIIaHyIXY1DU/mGLP9Xl0sCZm5+d+CxGnArwIqkdO5FNUmEB09E9lI+GHz/OX/Cw jO/OvznRf4EMDFkdFvkLgUiIiQahlVgv0Q/f342yYMtgXycZFu30LFP+y0riCRAjTz/s Nt5I7UdQmXreKX/00i644BugpKRagJggJoPi2A6xBVodAWHvfbSDByOrd2nPXrxsmnPE gqTw== X-Gm-Message-State: AOAM533d6SzyTdwj6FIeAqacTokE8y31AdYszaXOqAH+Ng4A7170DO31 GjLr/E6Us5UJIylvR1h+gIuFRq5oy49pRpdvkOiFVA== 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-kernel@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?