| Message ID | 9dc38544-b297-741e-dd7e-e09778a0baf3@debian.org (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On 03/21/2018 07:58 AM, Laurent Bigonville wrote: > Hello, > > Could somebody have a quick look at the two patches that I opened for two dbus bugs: > > https://bugs.freedesktop.org/show_bug.cgi?id=92831 (stop using avc_init()) > > https://bugs.freedesktop.org/attachment.cgi?id=138021 (stop using selinux_set_mapping()) > > I'm also wondering whether the call to avc_add_callback() shouldn't be replaced by selinux_set_callback(), an opinion on this? Patches look sane to me although I'm not really familiar with dbus code. Looks like the callback is only used to trigger a reload of the dbus configuration (for dbus_contexts updates), and thus selinux_set_callback(SELINUX_CB_POLICYLOAD) is more appropriate than avc_add_callback(AVC_CALLBACK_RESET), since the latter is called upon setenforce 1 as well. However, if it were truly only for that purpose, one might argue that it ought to be a watch on the dbus_contexts file instead and not be tied to selinux at all. NB This still won't fix the case where dbusd has already performed a string_to_security_class/av_perm lookup and the result has been cached by the libselinux class cache and then a subsequent policy update alters those values. That is what was fixed for systemd's usage of selinux_check_access() by selinux commit b408d72ca9104cb0c1bc4e154d8732cc7c0a9190. Offhand, I'm now wondering why I didn't just call flush_class_cache() from avc_reset() itself. That would fix it for other users of the AVC. You can't directly call flush_class_cache() from the dbus selinux policyload callback because it is hidden presently. If we can fix it directly in libselinux, then that is better. If not, we'd need to export it and probably give it a more unique name, ala selinux_flush_class_cache().
On Thu, Mar 22, 2018 at 12:09:08PM -0400, Stephen Smalley wrote: > On 03/21/2018 07:58 AM, Laurent Bigonville wrote: > > Hello, > > > > Could somebody have a quick look at the two patches that I opened for two dbus bugs: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=92831 (stop using avc_init()) > > > > https://bugs.freedesktop.org/attachment.cgi?id=138021 (stop using selinux_set_mapping()) > > > > I'm also wondering whether the call to avc_add_callback() shouldn't be replaced by selinux_set_callback(), an opinion on this? > > Patches look sane to me although I'm not really familiar with dbus code. > > Looks like the callback is only used to trigger a reload of the dbus configuration (for dbus_contexts updates), and thus selinux_set_callback(SELINUX_CB_POLICYLOAD) is more appropriate than avc_add_callback(AVC_CALLBACK_RESET), since the latter is called upon setenforce 1 as well. However, if it were truly only for that purpose, one might argue that it ought to be a watch on the dbus_contexts file instead and not be tied to selinux at all. > > NB This still won't fix the case where dbusd has already performed a string_to_security_class/av_perm lookup and the result has been cached by the libselinux class cache and then a subsequent policy update alters those values. That is what was fixed for systemd's usage of selinux_check_access() by selinux commit b408d72ca9104cb0c1bc4e154d8732cc7c0a9190. Offhand, I'm now wondering why I didn't just call flush_class_cache() from avc_reset() itself. That would fix it for other users of the AVC. You can't directly call flush_class_cache() from the dbus selinux policyload callback because it is hidden presently. If we can fix it directly in libselinux, then that is better. If not, we'd need to export it and probably give it a more unique name, ala selinux_flush_class_cache(). dbus-broker also uses selinux_access_check: https://github.com/bus1/dbus-broker/issues/16 > >
Le 22/03/18 à 17:09, Stephen Smalley a écrit : > On 03/21/2018 07:58 AM, Laurent Bigonville wrote: >> Hello, >> >> Could somebody have a quick look at the two patches that I opened for two dbus bugs: >> >> https://bugs.freedesktop.org/show_bug.cgi?id=92831 (stop using avc_init()) >> >> https://bugs.freedesktop.org/attachment.cgi?id=138021 (stop using selinux_set_mapping()) >> >> I'm also wondering whether the call to avc_add_callback() shouldn't be replaced by selinux_set_callback(), an opinion on this? > Patches look sane to me although I'm not really familiar with dbus code. Thanks for the review, Simon already had a look at the dbus part of the code > Looks like the callback is only used to trigger a reload of the dbus configuration (for dbus_contexts updates), and thus selinux_set_callback(SELINUX_CB_POLICYLOAD) is more appropriate than avc_add_callback(AVC_CALLBACK_RESET), since the latter is called upon setenforce 1 as well. However, if it were truly only for that purpose, one might argue that it ought to be a watch on the dbus_contexts file instead and not be tied to selinux at all. I really don't know the original rational of this. But I guess that if somebody is modifying dbus_contexts file, there are big chances that he will reload the policy as well(?). I'll change avc_add_callback() by selinux_set_callback(), we could say that as the file is in the SELinux path it's its responsibility. > NB This still won't fix the case where dbusd has already performed a string_to_security_class/av_perm lookup and the result has been cached by the libselinux class cache and then a subsequent policy update alters those values. That is what was fixed for systemd's usage of selinux_check_access() by selinux commit b408d72ca9104cb0c1bc4e154d8732cc7c0a9190. Offhand, I'm now wondering why I didn't just call flush_class_cache() from avc_reset() itself. That would fix it for other users of the AVC. You can't directly call flush_class_cache() from the dbus selinux policyload callback because it is hidden presently. If we can fix it directly in libselinux, then that is better. If not, we'd need to export it and probably give it a more unique name, ala selinux_flush_class_cache(). Right, that's a really good point, that I apparently overlooked... Is that cache really supposed to substantially speedup things? Would it be possible to create a version of selinux_check_access() that allows to pass a reference the cache or let selinux_check_access() create that cache itself? If it's the case I guess that dbus-broker would benefit of that as well as they are using selinux_check_access(). Otherwise we can indeed clean up the cache our self, but wasn't the goal of selinux_check_access() to be an "easy" interface to use, asking the applications to do this kind of housekeeping is defeating that purpose, isn't it?
On 03/23/2018 06:31 AM, Laurent Bigonville wrote: > Le 22/03/18 à 17:09, Stephen Smalley a écrit : >> On 03/21/2018 07:58 AM, Laurent Bigonville wrote: >>> Hello, >>> >>> Could somebody have a quick look at the two patches that I opened for two dbus bugs: >>> >>> https://bugs.freedesktop.org/show_bug.cgi?id=92831 (stop using avc_init()) >>> >>> https://bugs.freedesktop.org/attachment.cgi?id=138021 (stop using selinux_set_mapping()) >>> >>> I'm also wondering whether the call to avc_add_callback() shouldn't be replaced by selinux_set_callback(), an opinion on this? >> Patches look sane to me although I'm not really familiar with dbus code. > > Thanks for the review, Simon already had a look at the dbus part of the code > >> Looks like the callback is only used to trigger a reload of the dbus configuration (for dbus_contexts updates), and thus selinux_set_callback(SELINUX_CB_POLICYLOAD) is more appropriate than avc_add_callback(AVC_CALLBACK_RESET), since the latter is called upon setenforce 1 as well. However, if it were truly only for that purpose, one might argue that it ought to be a watch on the dbus_contexts file instead and not be tied to selinux at all. > I really don't know the original rational of this. But I guess that if somebody is modifying dbus_contexts file, there are big chances that he will reload the policy as well(?). > > I'll change avc_add_callback() by selinux_set_callback(), we could say that as the file is in the SELinux path it's its responsibility. > >> NB This still won't fix the case where dbusd has already performed a string_to_security_class/av_perm lookup and the result has been cached by the libselinux class cache and then a subsequent policy update alters those values. That is what was fixed for systemd's usage of selinux_check_access() by selinux commit b408d72ca9104cb0c1bc4e154d8732cc7c0a9190. Offhand, I'm now wondering why I didn't just call flush_class_cache() from avc_reset() itself. That would fix it for other users of the AVC. You can't directly call flush_class_cache() from the dbus selinux policyload callback because it is hidden presently. If we can fix it directly in libselinux, then that is better. If not, we'd need to export it and probably give it a more unique name, ala selinux_flush_class_cache(). > Right, that's a really good point, that I apparently overlooked... > > Is that cache really supposed to substantially speedup things? Would it be possible to create a version of selinux_check_access() that allows to pass a reference the cache or let selinux_check_access() create that cache itself? If it's the case I guess that dbus-broker would benefit of that as well as they are using selinux_check_access(). > > Otherwise we can indeed clean up the cache our self, but wasn't the goal of selinux_check_access() to be an "easy" interface to use, asking the applications to do this kind of housekeeping is defeating that purpose, isn't it? If you use selinux_check_access(), then the class cache is already flushed for you upon an AVC reset; that is what the commit I referenced above did. The problem in the case of dbusd is that it is not using selinux_check_access() but rather its own direct usage of string_to_security_class/av_perm() and avc_has_perm(). That's why we need to either take the call to flush_class_cache() in libselinux to avc_reset() so that it is done for all users of the AVC, or we need to export it and have dbusd call it from its policy reload callback.
Le 23/03/18 à 13:26, Stephen Smalley a écrit : > On 03/23/2018 06:31 AM, Laurent Bigonville wrote: >> Le 22/03/18 à 17:09, Stephen Smalley a écrit : >>> On 03/21/2018 07:58 AM, Laurent Bigonville wrote: >>>> Hello, >>>> >>>> Could somebody have a quick look at the two patches that I opened for two dbus bugs: >>>> >>>> https://bugs.freedesktop.org/show_bug.cgi?id=92831 (stop using avc_init()) >>>> >>>> https://bugs.freedesktop.org/attachment.cgi?id=138021 (stop using selinux_set_mapping()) >>>> >>>> I'm also wondering whether the call to avc_add_callback() shouldn't be replaced by selinux_set_callback(), an opinion on this? >>> Patches look sane to me although I'm not really familiar with dbus code. >> Thanks for the review, Simon already had a look at the dbus part of the code >> >>> Looks like the callback is only used to trigger a reload of the dbus configuration (for dbus_contexts updates), and thus selinux_set_callback(SELINUX_CB_POLICYLOAD) is more appropriate than avc_add_callback(AVC_CALLBACK_RESET), since the latter is called upon setenforce 1 as well. However, if it were truly only for that purpose, one might argue that it ought to be a watch on the dbus_contexts file instead and not be tied to selinux at all. >> I really don't know the original rational of this. But I guess that if somebody is modifying dbus_contexts file, there are big chances that he will reload the policy as well(?). >> >> I'll change avc_add_callback() by selinux_set_callback(), we could say that as the file is in the SELinux path it's its responsibility. >> >>> NB This still won't fix the case where dbusd has already performed a string_to_security_class/av_perm lookup and the result has been cached by the libselinux class cache and then a subsequent policy update alters those values. That is what was fixed for systemd's usage of selinux_check_access() by selinux commit b408d72ca9104cb0c1bc4e154d8732cc7c0a9190. Offhand, I'm now wondering why I didn't just call flush_class_cache() from avc_reset() itself. That would fix it for other users of the AVC. You can't directly call flush_class_cache() from the dbus selinux policyload callback because it is hidden presently. If we can fix it directly in libselinux, then that is better. If not, we'd need to export it and probably give it a more unique name, ala selinux_flush_class_cache(). >> Right, that's a really good point, that I apparently overlooked... >> >> Is that cache really supposed to substantially speedup things? Would it be possible to create a version of selinux_check_access() that allows to pass a reference the cache or let selinux_check_access() create that cache itself? If it's the case I guess that dbus-broker would benefit of that as well as they are using selinux_check_access(). >> >> Otherwise we can indeed clean up the cache our self, but wasn't the goal of selinux_check_access() to be an "easy" interface to use, asking the applications to do this kind of housekeeping is defeating that purpose, isn't it? > If you use selinux_check_access(), then the class cache is already flushed for you upon an AVC reset; that is what the commit I referenced above did. The problem in the case of dbusd is that it is not using selinux_check_access() but rather its own direct usage of string_to_security_class/av_perm() and avc_has_perm(). That's why we need to either take the call to flush_class_cache() in libselinux to avc_reset() so that it is done for all users of the AVC, or we need to export it and have dbusd call it from its policy reload callback. No, I meant the decision cache used by avc_has_perm(). dbus is not using selinux_check_access() because there is no way to set that decision cache (the 5th parameter of avc_has_perm() is NULL)
On 03/23/2018 08:44 AM, Laurent Bigonville wrote: > Le 23/03/18 à 13:26, Stephen Smalley a écrit : >> On 03/23/2018 06:31 AM, Laurent Bigonville wrote: >>> Le 22/03/18 à 17:09, Stephen Smalley a écrit : >>>> On 03/21/2018 07:58 AM, Laurent Bigonville wrote: >>>>> Hello, >>>>> >>>>> Could somebody have a quick look at the two patches that I opened for two dbus bugs: >>>>> >>>>> https://bugs.freedesktop.org/show_bug.cgi?id=92831 (stop using avc_init()) >>>>> >>>>> https://bugs.freedesktop.org/attachment.cgi?id=138021 (stop using selinux_set_mapping()) >>>>> >>>>> I'm also wondering whether the call to avc_add_callback() shouldn't be replaced by selinux_set_callback(), an opinion on this? >>>> Patches look sane to me although I'm not really familiar with dbus code. >>> Thanks for the review, Simon already had a look at the dbus part of the code >>> >>>> Looks like the callback is only used to trigger a reload of the dbus configuration (for dbus_contexts updates), and thus selinux_set_callback(SELINUX_CB_POLICYLOAD) is more appropriate than avc_add_callback(AVC_CALLBACK_RESET), since the latter is called upon setenforce 1 as well. However, if it were truly only for that purpose, one might argue that it ought to be a watch on the dbus_contexts file instead and not be tied to selinux at all. >>> I really don't know the original rational of this. But I guess that if somebody is modifying dbus_contexts file, there are big chances that he will reload the policy as well(?). >>> >>> I'll change avc_add_callback() by selinux_set_callback(), we could say that as the file is in the SELinux path it's its responsibility. >>> >>>> NB This still won't fix the case where dbusd has already performed a string_to_security_class/av_perm lookup and the result has been cached by the libselinux class cache and then a subsequent policy update alters those values. That is what was fixed for systemd's usage of selinux_check_access() by selinux commit b408d72ca9104cb0c1bc4e154d8732cc7c0a9190. Offhand, I'm now wondering why I didn't just call flush_class_cache() from avc_reset() itself. That would fix it for other users of the AVC. You can't directly call flush_class_cache() from the dbus selinux policyload callback because it is hidden presently. If we can fix it directly in libselinux, then that is better. If not, we'd need to export it and probably give it a more unique name, ala selinux_flush_class_cache(). >>> Right, that's a really good point, that I apparently overlooked... >>> >>> Is that cache really supposed to substantially speedup things? Would it be possible to create a version of selinux_check_access() that allows to pass a reference the cache or let selinux_check_access() create that cache itself? If it's the case I guess that dbus-broker would benefit of that as well as they are using selinux_check_access(). >>> >>> Otherwise we can indeed clean up the cache our self, but wasn't the goal of selinux_check_access() to be an "easy" interface to use, asking the applications to do this kind of housekeeping is defeating that purpose, isn't it? >> If you use selinux_check_access(), then the class cache is already flushed for you upon an AVC reset; that is what the commit I referenced above did. The problem in the case of dbusd is that it is not using selinux_check_access() but rather its own direct usage of string_to_security_class/av_perm() and avc_has_perm(). That's why we need to either take the call to flush_class_cache() in libselinux to avc_reset() so that it is done for all users of the AVC, or we need to export it and have dbusd call it from its policy reload callback. > > No, I meant the decision cache used by avc_has_perm(). dbus is not using selinux_check_access() because there is no way to set that decision cache (the 5th parameter of avc_has_perm() is NULL) Oh, you mean the AVC entry reference. Usually that would be cached in a per-object structure of some sort, e.g. in the kernel, there used to be an AVC entry reference cached in the task, inode, and other security structures. However, the AVC entry references were dropped from the kernel altogether when the kernel AVC was converted to using RCU. They are still used in the libselinux AVC, but I wouldn't expect dbusd is gaining much from using it especially since dbusd is only storing a single reference globally rather than any kind of per-object one. The larger cost of switching to using selinux_check_access() is probably the avc_context_to_sid() lookups since you already have the SIDs available to you. You don't necessarily have to switch to selinux_check_access(). But we do need to ensure that the class cache is flushed, either by adding a call to avc_reset() in libselinux if that is possible, or by exporting flush_class_cache() and calling it from the dbusd policy reload callback.
On 03/23/2018 09:14 AM, Stephen Smalley wrote: > On 03/23/2018 08:44 AM, Laurent Bigonville wrote: >> Le 23/03/18 à 13:26, Stephen Smalley a écrit : >>> On 03/23/2018 06:31 AM, Laurent Bigonville wrote: >>>> Le 22/03/18 à 17:09, Stephen Smalley a écrit : >>>>> On 03/21/2018 07:58 AM, Laurent Bigonville wrote: >>>>>> Hello, >>>>>> >>>>>> Could somebody have a quick look at the two patches that I opened for two dbus bugs: >>>>>> >>>>>> https://bugs.freedesktop.org/show_bug.cgi?id=92831 (stop using avc_init()) >>>>>> >>>>>> https://bugs.freedesktop.org/attachment.cgi?id=138021 (stop using selinux_set_mapping()) >>>>>> >>>>>> I'm also wondering whether the call to avc_add_callback() shouldn't be replaced by selinux_set_callback(), an opinion on this? >>>>> Patches look sane to me although I'm not really familiar with dbus code. >>>> Thanks for the review, Simon already had a look at the dbus part of the code >>>> >>>>> Looks like the callback is only used to trigger a reload of the dbus configuration (for dbus_contexts updates), and thus selinux_set_callback(SELINUX_CB_POLICYLOAD) is more appropriate than avc_add_callback(AVC_CALLBACK_RESET), since the latter is called upon setenforce 1 as well. However, if it were truly only for that purpose, one might argue that it ought to be a watch on the dbus_contexts file instead and not be tied to selinux at all. >>>> I really don't know the original rational of this. But I guess that if somebody is modifying dbus_contexts file, there are big chances that he will reload the policy as well(?). >>>> >>>> I'll change avc_add_callback() by selinux_set_callback(), we could say that as the file is in the SELinux path it's its responsibility. >>>> >>>>> NB This still won't fix the case where dbusd has already performed a string_to_security_class/av_perm lookup and the result has been cached by the libselinux class cache and then a subsequent policy update alters those values. That is what was fixed for systemd's usage of selinux_check_access() by selinux commit b408d72ca9104cb0c1bc4e154d8732cc7c0a9190. Offhand, I'm now wondering why I didn't just call flush_class_cache() from avc_reset() itself. That would fix it for other users of the AVC. You can't directly call flush_class_cache() from the dbus selinux policyload callback because it is hidden presently. If we can fix it directly in libselinux, then that is better. If not, we'd need to export it and probably give it a more unique name, ala selinux_flush_class_cache(). >>>> Right, that's a really good point, that I apparently overlooked... >>>> >>>> Is that cache really supposed to substantially speedup things? Would it be possible to create a version of selinux_check_access() that allows to pass a reference the cache or let selinux_check_access() create that cache itself? If it's the case I guess that dbus-broker would benefit of that as well as they are using selinux_check_access(). >>>> >>>> Otherwise we can indeed clean up the cache our self, but wasn't the goal of selinux_check_access() to be an "easy" interface to use, asking the applications to do this kind of housekeeping is defeating that purpose, isn't it? >>> If you use selinux_check_access(), then the class cache is already flushed for you upon an AVC reset; that is what the commit I referenced above did. The problem in the case of dbusd is that it is not using selinux_check_access() but rather its own direct usage of string_to_security_class/av_perm() and avc_has_perm(). That's why we need to either take the call to flush_class_cache() in libselinux to avc_reset() so that it is done for all users of the AVC, or we need to export it and have dbusd call it from its policy reload callback. >> >> No, I meant the decision cache used by avc_has_perm(). dbus is not using selinux_check_access() because there is no way to set that decision cache (the 5th parameter of avc_has_perm() is NULL) > > Oh, you mean the AVC entry reference. Usually that would be cached in a per-object structure of some sort, e.g. in the kernel, there used to be an AVC entry reference cached in the task, inode, and other security structures. However, the AVC entry references were dropped from the kernel altogether when the kernel AVC was converted to using RCU. They are still used in the libselinux AVC, but I wouldn't expect dbusd is gaining much from using it especially since dbusd is only storing a single reference globally rather than any kind of per-object one. The larger cost of switching to using selinux_check_access() is probably the avc_context_to_sid() lookups since you already have the SIDs available to you. > > You don't necessarily have to switch to selinux_check_access(). But we do need to ensure that the class cache is flushed, either by adding a call to avc_reset() in libselinux if that is possible, or by exporting flush_class_cache() and calling it from the dbusd policy reload callback. Sorry, to be clear, the first option is to add a call to flush_class_cache() from avc_reset() in libselinux, so that it is always called upon an AVC reset (and dropping the custom avc reset callback from selinux_check_access).
From 94889d438c81f001d4716d11df8a55a3706e45b0 Mon Sep 17 00:00:00 2001 From: Laurent Bigonville <bigon@bigon.be> Date: Sat, 3 Mar 2018 11:15:23 +0100 Subject: [PATCH 2/2] Stop using selinux_set_mapping() function Currently, if the "dbus" security class or the associated AV doesn't exist, dbus-daemon fails to initialize and exits immediately. Also the security classes or access vector cannot be reordered in the policy. This can be a problem for people developping their own policy or trying to access a machine where, for some reasons, there is not policy defined at all. The code here copy the behaviour of the selinux_check_access() function. We cannot use this function here as it doesn't allow us to define a cache. https://bugs.freedesktop.org/show_bug.cgi?id=105330 --- bus/selinux.c | 75 ++++++++++++++++++++++++++++++++++------------------------- 1 file changed, 43 insertions(+), 32 deletions(-) diff --git a/bus/selinux.c b/bus/selinux.c index f0ddfa11..7cde0537 100644 --- a/bus/selinux.c +++ b/bus/selinux.c @@ -236,24 +236,6 @@ bus_selinux_pre_init (void) #endif } -/* - * Private Flask definitions; the order of these constants must - * exactly match that of the structure array below! - */ -/* security dbus class constants */ -#define SECCLASS_DBUS 1 - -/* dbus's per access vector constants */ -#define DBUS__ACQUIRE_SVC 1 -#define DBUS__SEND_MSG 2 - -#ifdef HAVE_SELINUX -static struct security_class_mapping dbus_map[] = { - { "dbus", { "acquire_svc", "send_msg", NULL } }, - { NULL } -}; -#endif /* HAVE_SELINUX */ - /** * Establish dynamic object class and permission mapping and * initialize the user space access vector cache (AVC) for D-Bus and set up @@ -275,13 +257,6 @@ bus_selinux_full_init (BusContext *context, DBusError *error) _dbus_verbose ("SELinux is enabled in this kernel.\n"); - if (selinux_set_mapping (dbus_map) < 0) - { - _dbus_warn ("Failed to set up security class mapping (selinux_set_mapping():%s).", - strerror (errno)); - return FALSE; - } - avc_entry_ref_init (&aeref); if (avc_open (NULL, 0) < 0) { @@ -398,19 +373,55 @@ error: static dbus_bool_t bus_selinux_check (BusSELinuxID *sender_sid, BusSELinuxID *override_sid, - security_class_t target_class, - access_vector_t requested, + const char *target_class, + const char *requested, DBusString *auxdata) { + int saved_errno; + security_class_t security_class; + access_vector_t requested_access; + if (!selinux_enabled) return TRUE; + security_class = string_to_security_class (target_class); + if (security_class == 0) + { + saved_errno = errno; + _dbus_warn ("Error getting security class \"%s\": %s", + target_class, _dbus_strerror (errno)); + log_callback (SELINUX_ERROR, "Unknown class %s", target_class); + if (security_deny_unknown () == 0) + { + return TRUE; + } + + errno = saved_errno; + return FALSE; + } + + requested_access = string_to_av_perm (security_class, requested); + if (requested_access == 0) + { + saved_errno = errno; + _dbus_warn ("Error getting access vector \"%s\": %s", + requested, _dbus_strerror (errno)); + log_callback (SELINUX_ERROR, "Unknown permission %s for class %s", requested, target_class); + if (security_deny_unknown () == 0) + { + return TRUE; + } + + errno = saved_errno; + return FALSE; + } + /* Make the security check. AVC checks enforcing mode here as well. */ if (avc_has_perm (SELINUX_SID_FROM_BUS (sender_sid), override_sid ? SELINUX_SID_FROM_BUS (override_sid) : bus_sid, - target_class, requested, &aeref, auxdata) < 0) + security_class, requested_access, &aeref, auxdata) < 0) { switch (errno) { @@ -477,8 +488,8 @@ bus_selinux_allows_acquire_service (DBusConnection *connection, ret = bus_selinux_check (connection_sid, service_sid, - SECCLASS_DBUS, - DBUS__ACQUIRE_SVC, + "dbus", + "acquire_svc", &auxdata); _dbus_string_free (&auxdata); @@ -606,8 +617,8 @@ bus_selinux_allows_send (DBusConnection *sender, ret = bus_selinux_check (sender_sid, recipient_sid, - SECCLASS_DBUS, - DBUS__SEND_MSG, + "dbus", + "send_msg", &auxdata); _dbus_string_free (&auxdata); -- 2.16.2