Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp259007pxx; Thu, 29 Oct 2020 01:45:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyEDXDYKvK5bKuTRl2kN+CB3Aro+4cHFsp6z08FSNA93UThVwYv432swjxGWSUpDY4XBQUK X-Received: by 2002:a17:906:3b43:: with SMTP id h3mr2938059ejf.542.1603961144486; Thu, 29 Oct 2020 01:45:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603961144; cv=none; d=google.com; s=arc-20160816; b=LoUtcPMzDkHy4hi89RZEAANx4n2sScNMwoC5Vl/yhsGzXx/9qMkTPDYuUTrDnC36gq VFiFEldl6nUBEPZ42B9bKlKwzTVBqS4dJJJs+rT1QMj/4oUnGycECyyUXqsWwunnh9Yn +NpcMe3QtbB3z+e8sixkU6OXwGRYI2p0MM0BKG5T/DtMNJUSMUOgcoeXYYAsEyMOzBNR /qedgVUSuChUx+tjYvJ8wIYkCAZLGcdJHgMFv7QgLByC8k4ZaTGQtlNXQdNkPoMbuFNS j4PPtNvI6l9zmrZIk7x0EoLYwrqkLo+qm8pzuz1KqK8ginGp7uiFcGnOCucpYhWUgSHF 6FVQ== 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=bUbdsznkyssxZQUaGiYFef8NyYzvzo9ihU0AaJ53g/g=; b=1AEoOcpUeV8TSo4zjxmtV/G1fi3w7Hy51OG9pjFL3/3ft6d271AY1bt/ip1aVZACHy z8sklSWPHXXjSSJwyJI4Snjvp9IkC+tgtGIVDAnJFWhCaX2Ey1oo68RwXaRLJABdTlqy bw8r8X9QsGXuHBj4OrlQ0/Xl47w8JS+JrJpGPaKcs5qxfRG3iGOElwRjX1dF95T3hPqS rBqObZkIdcbvFT8PAUByCZMRZ1+7hVAT3T3JSbO4weQcRV4PbYRPfCnUhePYa3eSfw/0 PZ9nDsHrJONtxFeVvza9s37IeU1FMp9pW1O/zeIncpQwIYvNb9W45O4I1aehdJ4gpr+4 k1Sg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=BDrxX4f+; 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 p7si1318660ejg.491.2020.10.29.01.45.22; Thu, 29 Oct 2020 01:45:44 -0700 (PDT) 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=BDrxX4f+; 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 S1732335AbgJ2BHk (ORCPT + 99 others); Wed, 28 Oct 2020 21:07:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52808 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404126AbgJ2BGS (ORCPT ); Wed, 28 Oct 2020 21:06:18 -0400 Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88F08C0613D3 for ; Wed, 28 Oct 2020 18:06:16 -0700 (PDT) Received: by mail-lf1-x142.google.com with SMTP id j30so1201975lfp.4 for ; Wed, 28 Oct 2020 18:06:16 -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=bUbdsznkyssxZQUaGiYFef8NyYzvzo9ihU0AaJ53g/g=; b=BDrxX4f+Wgvz7T2nQLENN+0irWwn/eNDmAKCTDCqH7wbKE23tfFJlUZmPAsdIVT6av 1Or1eDLwD4Ua1/VtLB9aLqgums1ThYkU6EoVz66waVy839CCdRQ4/jA5GhhAy7zJx4fP lIOBOse97g1uBe2mm7vsNQdWsRKzB5bSgNBV7JJSa9s1KuspQmNoz02kO+9neBnMrIfH 9p9f4n15YsHkpW5CrApshNR4MlYwwrAZ2bcyzIfJFWhzAWKQIqVwpqwuGuD0xVKFI8YG 73ZcamzLaX7g3KVQHvBjBMxnmz2K2Y3WZoOLFQ4cjIZQPuTwsIYEU7TMMrzclXdPmFDT MJYA== 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=bUbdsznkyssxZQUaGiYFef8NyYzvzo9ihU0AaJ53g/g=; b=XIAgT9gE8GqkfGRtM9Hz24163jsytqa8Xp7m7snsXoNiza0E+0SBfMS8SgMzRRm94a md5KEAAFGWpuHmJUTHkCiNDIjtLVaA7sqBq+CPxWVDlzTbhsd7xmJjfmY1mvlZB3jDZ7 b71FZhDwaTy/U6B3THKKuqFGZV9oq44aAEb6lr9Fs9A3y0sCzh5Kki3P2KYaxmNPm+yS MmMah3K5B6TCLTKgLBmtAtoG44lYWU06LbMJ7PkMPx1cBTU7CUblHqqah3jGvdsb0g65 KJ2ZjdeU35bUYcx6REGzSkvwT7PQlav/LkB0UbDYGRHxYAdYI7p6Hw4HIFZkjV/fW8Du Q7WQ== X-Gm-Message-State: AOAM532wShF/XBdGJrzqa9z0t+GVE84ffHDmMqiEIKFZurHQAA4bgQt1 ehF5n91DnH4rf2+15oaSnQNYUoCKGSrvHEoJTcoFXg== X-Received: by 2002:a05:6512:1054:: with SMTP id c20mr662361lfb.576.1603933574802; Wed, 28 Oct 2020 18:06:14 -0700 (PDT) MIME-Version: 1.0 References: <20201027200358.557003-1-mic@digikod.net> <20201027200358.557003-2-mic@digikod.net> In-Reply-To: <20201027200358.557003-2-mic@digikod.net> From: Jann Horn Date: Thu, 29 Oct 2020 02:05:47 +0100 Message-ID: Subject: Re: [PATCH v22 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 Tue, Oct 27, 2020 at 9:04 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: Jann Horn > Cc: Kees Cook > Cc: Serge E. Hallyn > Signed-off-by: Micka=C3=ABl Sala=C3=BCn Reviewed-by: Jann Horn except for some minor nits: [...] > diff --git a/security/landlock/object.c b/security/landlock/object.c [...] > +void landlock_put_object(struct landlock_object *const object) > +{ > + /* > + * The call to @object->underops->release(object) might sleep e.g= ., s/ e.g.,/, e.g./ > + * because of iput(). > + */ > + might_sleep(); > + if (!object) > + return; [...] > +} > diff --git a/security/landlock/object.h b/security/landlock/object.h [...] > +struct landlock_object { > + /** > + * @usage: This counter is used to tie an object to the rules mat= ching > + * it or to keep it alive while adding a new rule. If this count= er > + * reaches zero, this struct must not be modified, but this count= er can > + * still be read from within an RCU read-side critical section. = When > + * adding a new rule to an object with a usage counter of zero, w= e must > + * wait until the pointer to this object is set to NULL (or recyc= led). > + */ > + refcount_t usage; > + /** > + * @lock: Guards against concurrent modifications. This lock mus= t be s/must be/must be held/ ? > + * from the time @usage drops to zero until any weak references f= rom > + * @underobj to this object have been cleaned up. > + * > + * Lock ordering: inode->i_lock nests inside this. > + */ > + spinlock_t lock; [...] > +}; > + > +struct landlock_object *landlock_create_object( > + const struct landlock_object_underops *const underops, > + void *const underojb); nit: "underobj"