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=-11.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 BFB14C433E5 for ; Fri, 19 Mar 2021 18:41:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 96A0D6198A for ; Fri, 19 Mar 2021 18:41:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230365AbhCSSke (ORCPT ); Fri, 19 Mar 2021 14:40:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53136 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231228AbhCSSkW (ORCPT ); Fri, 19 Mar 2021 14:40:22 -0400 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CFAE2C061762 for ; Fri, 19 Mar 2021 11:40:21 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id v23so3359067ple.9 for ; Fri, 19 Mar 2021 11:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=3u9mAxNEw9z6za6KFcOo+uHqgiwiwZM5DCTyyspgn/o=; b=Yg6m4KOAXpRmtJyRDoH2yl2CHKC+3drp9u+T3OirmqRro1Mir6CpDUGmJiH6P/z7Kv 6KqrLz2fDgze6egHZS4RwPVSKmftmVpcaI/zzQassSY0Au1qSOniGyFwnlpaKbGukS1B 5ia9D9yVB+s3iHhoKPejUMLE1dxUY8uW3AgWA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=3u9mAxNEw9z6za6KFcOo+uHqgiwiwZM5DCTyyspgn/o=; b=AFiHzmWtQFYx6tY0CpeK/IzY4suuuMbEmzSzDNMFZs3FahCShEnY2ZZ4gxYIobss9L Gw/H/wy5fX9XvfiYMiJKFk2jJoB9F/FGK2+fcy44ell+FgnGVQLyKGOAT4h6dpRDapRW wFVx8Nui48IFIqMNviqB+l8gInBmODcpDLhNCJlQLcHggjpJr5jTbfBKCe69y17VPOG+ PilIr6LCS1x2ClC6Qc2k/BarpDzLH5V3kMYFR2seJdZI7QOYKboou+xhuMA+XnqbCRT3 Rd/Al2sZKI1S3xPC4x1qheXEc5uG75E3YKXFqmf3bRiYdnVgAOmhgXSgtQPbaCjBnr66 lsYA== X-Gm-Message-State: AOAM5333s7rOb+euqAKnENGVgKDc0CwzLYvAAxAvgUvGdwQtQ89j2gj9 NSnXZ5ZLlsDzqKlhPVs6ESAjGw== X-Google-Smtp-Source: ABdhPJw6vg1JHhR2dRDHudF/k8t7iI2PJ2EYrpqaNdHYFuKnjDOkJMrYPpYmCpqtqBVqRL+QAvirUw== X-Received: by 2002:a17:902:ea0e:b029:e4:81d4:ddae with SMTP id s14-20020a170902ea0eb02900e481d4ddaemr15830817plg.12.1616179221292; Fri, 19 Mar 2021 11:40:21 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id i62sm6034208pgc.11.2021.03.19.11.40.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Mar 2021 11:40:20 -0700 (PDT) Date: Fri, 19 Mar 2021 11:40:19 -0700 From: Kees Cook To: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= Cc: James Morris , Jann Horn , "Serge E . Hallyn" , Al Viro , Andrew Morton , Andy Lutomirski , Anton Ivanov , Arnd Bergmann , Casey Schaufler , David Howells , Jeff Dike , Jonathan Corbet , Michael Kerrisk , Richard Weinberger , Shuah Khan , Vincent Dagonneau , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-security-module@vger.kernel.org, x86@kernel.org, =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= Subject: Re: [PATCH v30 02/12] landlock: Add ruleset and domain management Message-ID: <202103191114.C87C5E2B69@keescook> References: <20210316204252.427806-1-mic@digikod.net> <20210316204252.427806-3-mic@digikod.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210316204252.427806-3-mic@digikod.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 16, 2021 at 09:42:42PM +0100, Mickaël Salaün wrote: > From: Mickaël Salaün > > 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 > Signed-off-by: Mickaël Salaün > Acked-by: Serge Hallyn > Link: https://lore.kernel.org/r/20210316204252.427806-3-mic@digikod.net (Aside: you appear to be self-adding your Link: tags -- AIUI, this is normally done by whoever pulls your series. I've only seen Link: tags added when needing to refer to something else not included in the series.) > [...] > +static void put_rule(struct landlock_rule *const rule) > +{ > + might_sleep(); > + if (!rule) > + return; > + landlock_put_object(rule->object); > + kfree(rule); > +} I'd expect this to be named "release" rather than "put" since it doesn't do any lifetime reference counting. > +static void build_check_ruleset(void) > +{ > + const struct landlock_ruleset ruleset = { > + .num_rules = ~0, > + .num_layers = ~0, > + }; > + > + BUILD_BUG_ON(ruleset.num_rules < LANDLOCK_MAX_NUM_RULES); > + BUILD_BUG_ON(ruleset.num_layers < LANDLOCK_MAX_NUM_LAYERS); > +} This is checking that the largest possible stored value is correctly within the LANDLOCK_MAX_* macro value? > [...] The locking all looks right, and given your test coverage and syzkaller work, it's hard for me to think of ways to prove it out any better. :) Reviewed-by: Kees Cook -- Kees Cook