selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Paul Moore <paul@paul-moore.com>
Cc: SElinux list <selinux@vger.kernel.org>,
	LSM List <linux-security-module@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] SELinux fixes for v5.15 (#1)
Date: Thu, 23 Sep 2021 08:53:12 -0700	[thread overview]
Message-ID: <CAHk-=wivxthY49NPyPG0QG302dmH_hrioE7NdDKMR1Fus0GHow@mail.gmail.com> (raw)
In-Reply-To: <CAHC9VhTtz_aNY6MOCM6ypbz+SHvS30hx42PWjXJhG1Z=t5jpBw@mail.gmail.com>

On Thu, Sep 23, 2021 at 8:43 AM Paul Moore <paul@paul-moore.com> wrote:
>
> However, we have the LSM framework because there is never one way to
> solve a problem,

The thing is, the lockdown patches were merged because they were allegedly sane.

As far as I can tell, this is purely a SELinux internal bug.

SELinux did something wrong. Stop doing it. Stop sending patches to
then screw up the generic security layer, and violate the rules under
which these patches were accepted.

We have now this week have two discussions about the selinux doing
completely invalid and incorrect things, and both were related to just
thinking that it's ok to just randomly access thread data.

At some point, you just have to look at the SELinux code and say
:"this does something wrong".

Instead of this kind of "no, everybody else is wrong, I will modify
them to do what I mistakenly did".

IOW, just make the patch be

   diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
   index 6517f221d52c..4e93bf5dc8ef 100644
   --- a/security/selinux/hooks.c
   +++ b/security/selinux/hooks.c
   @@ -7016,7 +7016,8 @@ static void selinux_bpf_prog_free(struct
bpf_prog_aux *aux)
    static int selinux_lockdown(enum lockdown_reason what)
    {
        struct common_audit_data ad;
   -    u32 sid = current_sid();
   +    /* Lockdown requests come in non-thread context, can't use
'current_sid()' */
   +    u32 sid = SECINITSID_UNLABELED;
        int invalid_reason = (what <= LOCKDOWN_NONE) ||
                             (what == LOCKDOWN_INTEGRITY_MAX) ||
                             (what >= LOCKDOWN_CONFIDENTIALITY_MAX);

and stop accessing random security ID's from random contexts.

And stop thinking it's ok for SELinux to just do bad things.

               Linus

  reply	other threads:[~2021-09-23 15:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-17  1:14 [GIT PULL] SELinux fixes for v5.15 (#1) Paul Moore
2021-09-22 17:57 ` Paul Moore
2021-09-22 20:55   ` Linus Torvalds
2021-09-22 21:10     ` Linus Torvalds
2021-09-22 21:40       ` Paul Moore
2021-09-22 23:43         ` Linus Torvalds
2021-09-23 15:43           ` Paul Moore
2021-09-23 15:53             ` Linus Torvalds [this message]
2021-09-23 17:13               ` Paul Moore
2021-09-23 17:29                 ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=wivxthY49NPyPG0QG302dmH_hrioE7NdDKMR1Fus0GHow@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).