From cf0c8d3b8cdd969da4947216fbdf8ab22f2e5a9d Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Wed, 20 Jun 2018 22:02:57 +0200 Subject: [PATCH] SELINUX: Also call is_selinux_enabled as a check for selinux child Resolves: https://pagure.io/SSSD/sssd/issue/3796 The SSSD selinux management routines were only checking if SELinux is managed on the system. If it is managed, the code tries to proceed and set the login context, otherwise an error is returned which SSSD handles gracefully. But this is not enough, in some cases SELinux might be disabled, but managed and in these cases SSSD was returning strange errors, which might have prevented login with selinux provider in effect. We got this hint form the RH SELinux maintainer: """ libsemanage is for managing SELinux infrastructure. generally if there's /etc/selinux/config where libsemanage can read SELINUXTYPE and SELinux module store - /etc/selinux//active (or /var/lib/selinux//active) - is available, libsemanage can manage it even when SELinux is disabled. I'm not sure if selinux_child doesn any is_selinux_enabled() checks but it could help to avoid such situations. "" --- src/util/sss_semanage.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/util/sss_semanage.c b/src/util/sss_semanage.c index 7b0eef2233..bcce57b603 100644 --- a/src/util/sss_semanage.c +++ b/src/util/sss_semanage.c @@ -82,6 +82,10 @@ static int sss_is_selinux_managed(semanage_handle_t *handle) return EINVAL; } + if (!is_selinux_enabled()) { + return ERR_SELINUX_NOT_MANAGED; + } + ret = semanage_is_managed(handle); if (ret == 0) { DEBUG(SSSDBG_TRACE_FUNC, "SELinux policy not managed via libsemanage\n");