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 49811C11F67 for ; Tue, 13 Jul 2021 02:35:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2C7B2611F1 for ; Tue, 13 Jul 2021 02:35:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233642AbhGMChw (ORCPT ); Mon, 12 Jul 2021 22:37:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233762AbhGMChs (ORCPT ); Mon, 12 Jul 2021 22:37:48 -0400 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3926C0613F0 for ; Mon, 12 Jul 2021 19:34:57 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id hr1so38620469ejc.1 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=LAlp3KsVgyHH6MN0qHEk+M8S63n+uYEj5qSAu2b4w1aq/aXvZKMhy/B0CSRb0GgTAi eTcmPbMp9OnqveqKXAyJhZYa/c+W5vURwAy8wfaflXjHerNVy4M67A+6BAkoV87Llwml Tfn7tBZMdZgJG3uNX1IsyignmBfuf8NH0ZkPtKgDE3a66gvE+bOIFOEIVJbQ3eCxuWyD 1EGlFkDtVZqa3fTUfALVEWOrXMtXCRag9DSO3R9a+Sk/3colPFOGmQutvnAjOUUTB+iM Lp207sOb/PnpMxBh6I71dif52M0j/lYKF5mD4rma4QWPw5lf3VGHPEN8a6l132F8QYv2 UUzA== X-Gm-Message-State: AOAM533ffHyvBs6oZ07O56iCu6gfMi/Fi+gPC+GRvTOZQX8e/W7Wwd59 udg06+SNxFqhSFeRnjoh+0cW88aHnBTVf6hbdSSB 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-efi@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