Created attachment 24612 [details] [review] verify enforcing mode before denying access If SELinux is in permissive mode and dbus is running in an invalid domain, avc_has_perm will return -1 and dbus will deny access. It is fairly difficult to get dbus into an invalid domain, but it can happen. If refpolicy trunk is installed on a system that uses upstart, such as Ubuntu, and the init_upstart boolean is set to off, the problem is very apparent because there is no keyboard of mouse response once the system reaches the GDM login screen. Dbus can also get into an invalid domain on RHEL 5 by booting into single user mode, starting dbus by hand, and then continuing the boot process. Attached is a patch that makes sure the system is in enforcing before denying access. NOTE: The system must be in permissive to get an invalid domain. AVC denials will not appear in the log, however security messages about the invalid context will.
Hmmm. Shouldn't this be in libselinux in some form? Are similar patches being made for X and other userspace programs?
To elaborate on my concern a bit, I think what we really want here is that the policy does not break, rather than expand the meaning of "enforcing" to also include coping with invalid state. For the first situation you mentioned it's an instance of the very common case of the base OS configuration not matching the SELinux policy. There are an infinite number of these kinds of situations. The right way to fix them is to work harder to avoid getting in them in the first place, using e.g. regression tests. As for single user mode, I'd say this is a case where you'd want identical behavior from the kernel AVC and all libselinux-based userspace programs as well, not a dbus-specific patch.
c.f. thread here http://marc.info/?l=selinux&m=123979801918475&w=2 Stephen says this should be changed in libselinux or kernel if anywhere, so closing here.
(In reply to comment #3) > c.f. thread here http://marc.info/?l=selinux&m=123979801918475&w=2 > > Stephen says this should be changed in libselinux or kernel if anywhere, so > closing here. > The thread recommends that DBUS at least report the correct error in the logs based on the errno. It would have made debugging the problem we found significantly easier if this was applied. Patch from Eamon Walsh: FWIW, the following patch to D-Bus should help: bfo21072 - Log SELinux denials better by checking errno for the cause Note that this does not fully address the bug report since EINVAL can still be returned in permissive mode. However the log messages will now reflect the proper cause of the denial. Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov> diff --git a/bus/selinux.c b/bus/selinux.c index c0f6f4d..46a18a9 100644 --- a/bus/selinux.c +++ b/bus/selinux.c @@ -433,8 +433,18 @@ bus_selinux_check (BusSELinuxID *sender_sid, SELINUX_SID_FROM_BUS (bus_sid), target_class, requested, &aeref, auxdata) < 0) { - _dbus_verbose ("SELinux denying due to security policy.\n"); - return FALSE; + switch (errno) + { + case EACCES: + _dbus_verbose ("SELinux denying due to security policy.\n"); + return FALSE; + case EINVAL: + _dbus_verbose ("SELinux denying due to invalid security context.\n"); + return FALSE; + default: + _dbus_verbose ("SELinux denying due to: %s\n", _dbus_strerror (errno)); + return FALSE; + } } else return TRUE;
Applied.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.