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=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,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 C3F9CC11F68 for ; Tue, 13 Jul 2021 02:34:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9CD0461283 for ; Tue, 13 Jul 2021 02:34:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230105AbhGMChr (ORCPT ); Mon, 12 Jul 2021 22:37:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230022AbhGMChr (ORCPT ); Mon, 12 Jul 2021 22:37:47 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB9B3C06178C for ; Mon, 12 Jul 2021 19:34:57 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id c17so38484454ejk.13 for ; Mon, 12 Jul 2021 19:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RBPu6xYIBS0viB5UZS492p6zHqYEhcALtpbidr1sCrU=; b=hAqQVpiv52aQMiILfGaILA7UZ3Vb7hpAEZl5MSyT4Y9giLdF8ZWBqgareVlSQUHWpR ZUrim0on5dre3bqN5EGAiRzVWG6nVeaiF+s6JaGu2Q+54HjtAgU1AvqcqlU5GALyqPc8 J59ZdfyvvWc0CNOaKSGrAuHZon7DtT9jG9x1ueo2PbGCXBvXV9LCEYmPz0NJvuwLKCb4 e5swfb54jlYSJ49YcMdOKdIhN3CYIP2f7H6ObIehgsT00rpoEugEWTcwjWsk6Ijx/OB+ sziXashjbhIgbQwAsqKXq8JHPkE9kbOMVO58+jj4MNa7U/Fp8vQxUrXCiR8DuABY3fmZ DToA== 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; bh=RBPu6xYIBS0viB5UZS492p6zHqYEhcALtpbidr1sCrU=; b=GHnMqzhTL3JJr9eucNnmeYDaAJ5BzIUiZUZo9wlC78oIVkCKPxQH9KNlhi+yfqzMF+ t/U6eiawifqarH14c1ACd9u76Td8k/FFID086LxyoCMGczNT2CSYSPreSaTVo6eEvoNJ WQ3ieizlGzFcD8W0D8zQZXg6jLcG5JHMHBirW9D0Czooj3CFpxUbr9cU2pTvLSd26AgP vDjaZRZK80xSEKr2sQkVGI9o0CtSuVEuA2KgC5cYGv9gNoLQ86NdGgRQYqZepDkqeHec UgQQUya3GHACH59p5pIj1HstFBqVPYinEo14lSHodRbsg/d+3dhMMs+x1HOVFLNw8Wdw 2q1w== X-Gm-Message-State: AOAM531gW6hC0oBi6vQCLzQA0jh4nHp7K8dMn6uz7MrCG6SGN3WYx44w YaEigFSabFKPapwaTdFdrqw+PcrUHOighK+RpWVo X-Google-Smtp-Source: ABdhPJyytdq/CE/wkitIkFTYSvvbb5T4D4KC4bniBQLIKEAC15BXF2YMkUTZuWQQktrfljWaz21U9sH3mGdCEuV7T/M= X-Received: by 2002:a17:907:10d8:: with SMTP id rv24mr2673354ejb.542.1626143695922; Mon, 12 Jul 2021 19:34:55 -0700 (PDT) MIME-Version: 1.0 References: <20210616085118.1141101-1-omosnace@redhat.com> <8735tdiyc1.ffs@nanos.tec.linutronix.de> In-Reply-To: <8735tdiyc1.ffs@nanos.tec.linutronix.de> From: Paul Moore Date: Mon, 12 Jul 2021 22:34:45 -0400 Message-ID: Subject: Re: [PATCH v3] lockdown,selinux: fix wrong subject in some SELinux lockdown checks To: Thomas Gleixner Cc: Ondrej Mosnacek , linux-security-module@vger.kernel.org, James Morris , Steven Rostedt , Ingo Molnar , Steffen Klassert , Herbert Xu , "David S . Miller" , Stephen Smalley , selinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-acpi@vger.kernel.org, linux-cxl@vger.kernel.org, linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, linux-serial@vger.kernel.org, bpf@vger.kernel.org, netdev@vger.kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Casey Schaufler Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Sat, Jun 19, 2021 at 1:00 PM Thomas Gleixner wrote: > On Wed, Jun 16 2021 at 10:51, Ondrej Mosnacek wrote: > > diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c > > index bda73cb7a044..c43a13241ae8 100644 > > --- a/arch/x86/mm/testmmiotrace.c > > +++ b/arch/x86/mm/testmmiotrace.c > > @@ -116,7 +116,7 @@ static void do_test_bulk_ioremapping(void) > > static int __init init(void) > > { > > unsigned long size = (read_far) ? (8 << 20) : (16 << 10); > > - int ret = security_locked_down(LOCKDOWN_MMIOTRACE); > > + int ret = security_locked_down(current_cred(), LOCKDOWN_MMIOTRACE); > > I have no real objection to those patches, but it strikes me odd that > out of the 62 changed places 58 have 'current_cred()' and 4 have NULL as > argument. > > I can't see why this would ever end up with anything else than > current_cred() or NULL and NULL being the 'special' case. So why not > having security_locked_down_no_cred() and make current_cred() implicit > for security_locked_down() which avoids most of the churn and just makes > the special cases special. I might be missing something though. Unfortunately it is not uncommon for kernel subsystems to add, move, or otherwise play around with LSM hooks without checking with the LSM folks; generally this is okay, but there have been a few problems in the past and I try to keep that in mind when we are introducing new hooks or modifying existing ones. If we have two LSM hooks for roughly the same control point it has the potential to cause confusion, e.g. do I use the "normal" or the "no_cred" version? What if I don't want to pass a credential, can I just use "no_cred"? My thinking with the single, always-pass-a-cred function is that callers don't have to worry about choosing from multiple, similar hooks and they know they need to pass a cred which hopefully gets them thinking about what cred is appropriate. It's not foolproof, but I believe the single hook approach will be less prone to accidents ... or so I hope :) -- paul moore www.paul-moore.com