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

On 4/4/26 5:19 AM, Wei Deng wrote:
> Hi Chris,
>
> Thanks for the review.
>
> 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.


>> The init_dbus_send_script() makes me wonder.
> They target different domains:
>
>    init_dbus_send_script(): bluetooth_t -> initrc_t (SysV init scripts)
>    init_dbus_chat():        bluetooth_t <-> init_t  (systemd itself)
>
> Both are needed for cross-platform compatibility.

initrc_t also exists on systemd systems for generic commands run from 
systemd units. However, if these rules are needed for sysvinit vs 
systemd, then these two rules should be put in an if/else of an 
init_systemd block.


-- 
Chris PeBenito