linux-kernel - Re: [GIT PULL] SELinux fixes for v5.15 (#1)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhSZp1-Qi7ApoQHauaFXDgoNaFTwFEieEFFuBtdPqAtXQg@mail.gmail.com>
Date:   Wed, 22 Sep 2021 17:40:00 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     SElinux list <selinux@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] SELinux fixes for v5.15 (#1)

On Wed, Sep 22, 2021 at 5:10 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Wed, Sep 22, 2021 at 1:55 PM Linus Torvalds
> <torvalds@...ux-foundation.org> 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