diff options
authorEamon Walsh <>2009-04-21 19:11:22 -0400
committerColin Walters <>2009-05-06 12:51:19 -0400
commitb38c433bf713324b5d17eae626e8c7404bcb6554 (patch)
parent73ec6964d7a14eba3ec7118041e48e0a21438e52 (diff)
libselinux behavior in permissive mode wrt invalid domains
Stephen Smalley wrote: > On Tue, 2009-04-21 at 16:32 -0400, Joshua Brindle wrote: > >> Stephen Smalley wrote: >> >>> On Thu, 2009-04-16 at 20:47 -0400, Eamon Walsh wrote: >>> >>>> Stephen Smalley wrote: >>>> >> <snip> >> >> >>> No, I don't want to change the behavior upon context_to_sid calls in >>> general, as we otherwise lose all context validity checking in >>> permissive mode. >>> >>> I think I'd rather change compute_sid behavior to preclude the situation >>> from arising in the first place, possibly altering the behavior in >>> permissive mode upon an invalid context to fall back on the ssid >>> (process) or the tsid (object). But I'm not entirely convinced any >>> change is required here. >>> >>> >> I just want to follow up to make sure we are all on the same page here. Was the >> suggestion to change avc_has_perm in libselinux or context_to_sid in the kernel >> or leave the code as is and fix the callers of avc_has_perm to correctly handle >> error codes? >> >> I prefer the last approach because of Eamon's explanation, EINVAL is already >> passed in errno to specify the context was invalid (and if object managers >> aren't handling that correctly now there is a good chance they aren't handling >> the ENOMEM case either). >> > > I'd be inclined to change compute_sid (not context_to_sid) in the kernel > to prevent invalid contexts from being formed even in permissive mode > (scenario is a type transition where role is not authorized for the new > type). That was originally to allow the system to boot in permissive > mode. But an alternative would be to just stay in the caller's context > (ssid) in that situation. > > Changing the callers of avc_has_perm() to handle EINVAL and/or ENOMEM > may make sense, but that logic should not depend on enforcing vs. > permissive mode. > > 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 <> Signed-off-by: Colin Walters <>
1 files changed, 12 insertions, 2 deletions
diff --git a/bus/selinux.c b/bus/selinux.c
index c0f6f4db..46a18a93 100644
--- a/bus/selinux.c
+++ b/bus/selinux.c
@@ -433,8 +433,18 @@ bus_selinux_check (BusSELinuxID *sender_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;
+ }
return TRUE;