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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 1A09EC4332F for ; Wed, 22 Sep 2021 21:40:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 005F9611C9 for ; Wed, 22 Sep 2021 21:40:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238072AbhIVVlp (ORCPT ); Wed, 22 Sep 2021 17:41:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238136AbhIVVln (ORCPT ); Wed, 22 Sep 2021 17:41:43 -0400 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 281D9C061574 for ; Wed, 22 Sep 2021 14:40:13 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id ee50so15398169edb.13 for ; Wed, 22 Sep 2021 14:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7yUAunh6/B1SSbZrz9wmLc4dr4D+i+n+StWnT5gfwxI=; b=8AMS1OWfH+m8OlWLakX39s9CFCl10Wb1+IQBBz1G9wBBbUxcQTDmbczC0bJ7SlHarh +n8UXbfSyXblRygBYIp/CcSdPPol63rkMONHJCSNkEpnSvN0Cu6oJ5E/pfbKoybDOJkB XzR4PfS/1H0KsVW7mn8xQ+aYfbVJW4RvXIA3AyE4ghg8Bl2CFkyVpTv3K+Aqrh/b4qvL Au15lRofpVsQAWeASOv8XxyuW4fTOfqw/PvXmR2n8YoWsNOnfk0i6Sg4Wuw0UDlT1WEI j1LABZbQhoy04as9QqXfnX6c0v6o6qwGlgAtQGSu3tvPtZE7P4qWv+VHh7Ei873MmqTq 317A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7yUAunh6/B1SSbZrz9wmLc4dr4D+i+n+StWnT5gfwxI=; b=rhefpYUAOOovuv8blvpg4k6Xn+IMhyzV96q/1+ROAY1KmCEJiX4PE8EUps/1KwR0hT lZyMmMtI/hi76HErNSgNM7KZW6chXG8kaRBJEFs6Mug7QsJD3pMKQFpPcEZF1FB+PKTy rR+j8gL6cZkzOif1YzCXyxlsuan3THGHbTQqbISZ/Vzggl2kL6WRFDa6Wqj5gkAgS/BK 87uepiqe2VnkNizbTLZczr1PYEQzqGDDqq7lvB94Oa7WbZV959H9B7ca0aWv0zommrpZ 2hsyV4ZNpXct/R5qgTBNqjPAGb+8EVdKUvMljof1TvF1ahvpLnflXH7uHXFSttx/qPVm rtmg== X-Gm-Message-State: AOAM531sZTo8pYITTtluMeyfz4yLdRkH5tISfYFIbpn6byVaYP/yAy61 4wTpCkZi2987Pbj36v4FJUcLrApKfVvNd5Gc+wQN X-Google-Smtp-Source: ABdhPJw9Jd3adL5gvFPfg8v5tsZxNf8e5DGyBzypEea1X9T7NzGxvH9h8cT+f4Q44+P9M1hCL5QNgsXcobRxjmKV284= X-Received: by 2002:a50:cf48:: with SMTP id d8mr1708015edk.293.1632346811617; Wed, 22 Sep 2021 14:40:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Paul Moore Date: Wed, 22 Sep 2021 17:40:00 -0400 Message-ID: Subject: Re: [GIT PULL] SELinux fixes for v5.15 (#1) To: Linus Torvalds Cc: SElinux list , LSM List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 22, 2021 at 5:10 PM Linus Torvalds wrote: > > On Wed, Sep 22, 2021 at 1:55 PM Linus Torvalds > wrote: > > > > Make the regular security_locked_down() function do that, and add a > > > > if (WARN_ON_ONCE(!in_task())) > > return -EPERM; > > > > so that any bad cases get flagged and refuse to continue. > > Actually, no, I take that back. > > It's not the "!in_task()" case that is the problem. That's just the symptom. > > The real problem is that we clearly have some lock-down rule that > seems to care about credentials and who it is that does the lockdown > query. That seems to be the real issue here. Doing lockdown checks > from interrupts should be fine. The basic idea, or problem from a LSM point of view, is that in some cases you have a user task which is doing the lockdown access check and in others you have the kernel itself; the creds parameter to security_locked_down() hook was intended to be used to indicate if it was a user task (param == current_cred()) or the kernel (param == NULL). There was a discussion about using two different hooks/funcs, e.g. security_locked_down() and security_locked_down_kern(), instead of the creds parameter, but there were more votes for the param variant. As I type this I'm trying to muster something other than indifference towards this patch, but the reality is I just want to be done with it. If you'll merge a revision of this patch that does away with the cred parameter and goes with the two hooks I'm not going to argue against it. During the review of the latest draft of this patch I half-jokingly said it was cursed, perhaps it's time to honestly consider it cursed. -- paul moore www.paul-moore.com