On Wed, Sep 22, 2021 at 2:40 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
>
> 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
I don't understand. In that case, it would be a boolean for "kernel vs user".
But that's not what it is. It literally seems to care about _which_
user, and looks at cred_sid().
This is what makes no sense to me. If it's about lockdown,. then the
user is immaterial. Either it's locked down, or it's not.
Yeah, yeah, clearly that isn't how it works. Something is very rotten
in the state of lockdown. But that rottenness shouldn't then be
exposed as a horrible interface.
Why has selinux allowed the SID to be an issue for SECCLASS_LOCKDOWN at all?
And why is selinux foceing it's very odd and arguably completely
misguided "lockdown" logic onto the security layer?
Yes, using "current_sid()" in selinux_lockdown() is clearly wrong,
since it's not sensible in an interrupt, but lockdown questions are.
But why isn't that just considered a selinux bug, and that
u32 sid = current_sid();
just replaced with something silly like
// lockdown is lockdown, user labeling isn't relevant
u32 sid = SECINITSID_UNLABELED;
and solve that issue that way? Just say that lockdown cannot depend on
who is asking for it.
Linus
