[GIT PULL] SELinux fixes for v5.15 (#1)

[Paul Moore]

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