If you run selinux_init_load_policy() after a chroot/switch-root, it's
possible that your *previous* root loaded policy, but your *new* root
wants SELinux disabled.
We can't disable SELinux in this case, but we *do* need to make sure
it's permissive. Otherwise we may continue to enforce the old policy.
So, if seconfig = -1, but security_disable() fails, we set *enforce=0,
and then let the existing code handle the security_{get,set}enforce
stuff.
Once that's handled, exit with failure via "goto noload", as before.
---
libselinux/src/load_policy.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/libselinux/src/load_policy.c b/libselinux/src/load_policy.c
index e419f1a..21ee58b 100644
--- a/libselinux/src/load_policy.c
+++ b/libselinux/src/load_policy.c
@@ -417,13 +417,15 @@ int selinux_init_load_policy(int *enforce)
/* Successfully disabled, so umount selinuxfs too. */
umount(selinux_mnt);
fini_selinuxmnt();
+ goto noload;
+ } else {
+ /*
+ * It's possible that this failed because policy has
+ * already been loaded. We can't disable SELinux now,
+ * so the best we can do is force it to be permissive.
+ */
+ *enforce = 0;
}
- /*
- * If we failed to disable, SELinux will still be
- * effectively permissive, because no policy is loaded.
- * No need to call security_setenforce(0) here.
- */
- goto noload;
}
/*
@@ -442,6 +444,9 @@ int selinux_init_load_policy(int *enforce)
}
}
+ if (seconfig == -1)
+ goto noload;
+
/* Load the policy. */
return selinux_mkload_policy(0);
--
1.9.0
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
