On Thu, Sep 23, 2021 at 8:43 AM Paul Moore <paul@xxxxxxxxxxxxxx> 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
