Re: [PATCH] sepolicy: Allow bluetooth to send D-Bus messages to systemd

On 4/9/26 7:36 AM, Wei Deng wrote:
> On 4/7/2026 8:40 PM, Christopher J. PeBenito wrote:
>> On 4/4/26 5:19 AM, Wei Deng wrote:
>>> On 4/3/2026 10:01 PM, Christopher J. PeBenito wrote:
>>>> On 4/3/26 2:31 AM, Wei Deng wrote:
>>>>> Add init_dbus_chat() for bluetooth_t to allow bluetoothd to send
>>>>> D-Bus method_return messages back to systemd (init_t) over the
>>>>> system bus.
>>>>>
>>>>> Below avc denial is fixed with this patch:
>>>>>
>>>>> avc:  denied  { send_msg } for  msgtype=method_return dest=:1.11
>>>>> scontext=system_u:system_r:bluetooth_t:s0
>>>>> tcontext=system_u:system_r:init_t:s0 tclass=dbus permissive=0
>>>>>
>>>>> Signed-off-by: Wei Deng <[email protected]>
>>>>> ---
>>>>>     policy/modules/services/bluetooth.te | 1 +
>>>>>     1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/policy/modules/services/bluetooth.te b/policy/modules/services/bluetooth.te
>>>>> index ceb42d147..a73cb5db0 100644
>>>>> --- a/policy/modules/services/bluetooth.te
>>>>> +++ b/policy/modules/services/bluetooth.te
>>>>> @@ -136,6 +136,7 @@ userdom_dontaudit_search_user_home_dirs(bluetooth_t)
>>>>>     optional_policy(`
>>>>>         dbus_system_bus_client(bluetooth_t)
>>>>>         dbus_connect_system_bus(bluetooth_t)
>>>>> +  init_dbus_chat(bluetooth_t)
>>>>>         init_dbus_send_script(bluetooth_t)
>>>>>           optional_policy(`
>>>> Can you confirm this response is going to systemd/pid1? Is there a fuller set of log messages corresponding to this denial? The init_dbus_send_script() makes me wonder.
>>> The two log entries list here:
>>>
>>>     type=SERVICE_START msg=audit(19.419:292): pid=1 uid=0
>>>       subj=system_u:system_r:init_t:s0
>>>       msg='unit=bluetooth comm="systemd"
>>>       exe="/usr/lib/systemd/systemd" ... res=success'
>>>
>>>     type=USER_AVC msg=audit(19.547:319):
>>>       subj=system_u:system_r:system_dbusd_t:s0
>>>       msg='avc: denied { send_msg } for msgtype=method_return
>>>       dest=:1.11 spid=684 tpid=843
>>>       scontext=system_u:system_r:bluetooth_t:s0
>>>       tcontext=system_u:system_r:init_t:s0
>>>       tclass=dbus permissive=0
>>>       exe="/usr/bin/dbus-daemon"'
>>>
>>>> Can you confirm this response is going to systemd/pid1?
>>>> Is there a fuller set of log messages corresponding to this denial?
>>> Yes. The SERVICE_START entry shows pid=1 with
>>> exe="/usr/lib/systemd/systemd" running under init_t, confirming that
>>> init_t is systemd's SELinux domain.
>> These two audit messages are not related, as they have different event IDs (292 vs 319). Additionally, SERVICE_START messages are expected to come from pid=1.
>>
>> Can you confirm this response is going to systemd/pid1?
>> Is there a fuller set of log messages corresponding to
>> this denial?
> You are right. I apologize for the confusion. The two audit
> messages are unrelated, as they have different event IDs.
>
> Here is the full AVC denial:
>
>    type=USER_AVC msg=audit(1773416627.807:455):
>      pid=801 uid=997 auid=4294967295 ses=4294967295
>      subj=system_u:system_r:system_dbusd_t:s0
>      msg='avc: denied { send_msg } for
>      msgtype=method_return dest=:1.27
>      spid=1942 tpid=1944
>      scontext=system_u:system_r:bluetooth_t:s0
>      tcontext=system_u:system_r:init_t:s0
>      tclass=dbus permissive=0
>      exe="/usr/bin/dbus-daemon"'
>
> The tpid=1944 is obexd, not systemd/pid1, as confirmed by:
>
>    ps -p 1944 -o pid,ppid,comm,exe,label
>        PID  PPID COMMAND  EXE                           LABEL
>       1944     1 obexd    /usr/libexec/bluetooth/obexd  system_u:system_r:init_t:s0
>
> So the real issue is not bluetooth_t -> init_t (systemd),
> but bluetooth_t -> init_t (obexd running in the wrong domain).
>
> The root cause is that obex.te currently uses
> userdom_user_application_domain(), which does not create a
> domain transition from init_t. obexd therefore inherits
> systemd's domain instead of transitioning to obex_t.

Thanks for working that out. It would be acceptable to add this in 
refpolicy, but I think it should be tunable. It's not a common case 
configuration.


-- 
Chris PeBenito