From: Naga Bhavani Akella <quic_nakella@quicinc.com>
To: Chris PeBenito <pebenito@ieee.org>, <selinux-refpolicy@vger.kernel.org>
Cc: <quic_mohamull@quicinc.com>, <quic_hbandi@quicinc.com>,
<quic_anubhavg@quicinc.com>
Subject: Re: [PATCH v1] Adding Sepolicy rules to allow bluetoothctl and dbus-daemon to access unix stream sockets.
Date: Wed, 15 May 2024 12:59:39 +0530 [thread overview]
Message-ID: <695f447e-b9db-414f-8fa5-1b12b8379c48@quicinc.com> (raw)
In-Reply-To: <877cf03e-037d-4708-8ac0-bce5b2caa48a@ieee.org>
Hi Chris PeBenito,
Thank you for your comments.
On 5/15/2024 1:42 AM, Chris PeBenito wrote:
> On 5/14/2024 3:21 AM, Naga Bhavani Akella wrote:
>> Required for using acquire-notify, acquire-write options (Gatt Client)
>> and Sending notifications (Gatt Server)
>>
>> Below are the avc denials that are fixed with this patch -
>>
>> 1. audit: type=1400 audit(1651238006.276:496):
>> avc: denied { read write } for pid=2165 comm="bluetoothd"
>> path="socket:[43207]" dev="sockfs" ino=43207
>> scontext=system_u:system_r:bluetooth_t:s0-s15:c0.c1023
>> tcontext=system_u:system_r:initrc_t:s0-s15:c0.c1023
>> tclass=unix_stream_socket permissive=1
>> 2. audit: type=1400 audit(1651238006.276:497):
>> avc: denied { getattr } for pid=2165 comm="bluetoothd"
>> path="socket:[43207]" dev="sockfs" ino=43207
>> scontext=system_u:system_r:bluetooth_t:s0-s15:c0.c1023
>> tcontext=system_u:system_r:initrc_t:s0-s15:c0.c1023
>> tclass=unix_stream_socket permissive=1
>> 3. audit: type=1400 audit(1651238006.272:495):
>> avc: denied { read write } for pid=689 comm="dbus-daemon"
>> path="socket:[43207]" dev="sockfs" ino=43207
>> scontext=system_u:system_r:system_dbusd_t:s0-s15:c0.c1023
>> tcontext=system_u:system_r:initrc_t:s0-s15:c0.c1023
>> tclass=unix_stream_socket permissive=1
>> 4. audit: type=1400 audit(315966559.395:444):
>> avc: denied { use } for pid=710 comm="dbus-daemon"
>> path="socket:[13196]" dev="sockfs" ino=13196
>> scontext=system_u:system_r:system_dbusd_t:s0-s15:c0.c1023
>> tcontext=system_u:system_r:bluetooth_t:s0-s15:c0.c1023
>> tclass=fd permissive=0
>> 5. audit: type=1400 audit(315999854.939:523):
>> avc: denied { read write } for pid=812 comm="dbus-daemon"
>> path="socket:[99469]" dev="sockfs" ino=99469
>> scontext=system_u:system_r:system_dbusd_t:s0-s15:c0.c1023
>> tcontext=system_u:system_r:bluetooth_t:s0-s15:c0.c1023
>> tclass=bluetooth_socket permissive=1
>>
>> Signed-off-by: Naga Bhavani Akella <quic_nakella@quicinc.com>
>> ---
>> policy/modules/services/bluetooth.fc | 1 +
>> policy/modules/services/bluetooth.if | 3 +++
>> 2 files changed, 4 insertions(+)
>>
>> diff --git a/policy/modules/services/bluetooth.fc b/policy/modules/services/bluetooth.fc
>> index e167e93f7..03f42fc8b 100644
>> --- a/policy/modules/services/bluetooth.fc
>> +++ b/policy/modules/services/bluetooth.fc
>> @@ -7,6 +7,7 @@
>> /usr/bin/blue.*pin -- gen_context(system_u:object_r:bluetooth_helper_exec_t,s0)
>> /usr/bin/bluetoothd -- gen_context(system_u:object_r:bluetooth_exec_t,s0)
>> +/usr/bin/bluetoothctl -- gen_context(system_u:object_r:bluetooth_exec_t,s0)
>> /usr/bin/dund -- gen_context(system_u:object_r:bluetooth_exec_t,s0)
>> /usr/bin/hciattach -- gen_context(system_u:object_r:bluetooth_exec_t,s0)
>> /usr/bin/hcid -- gen_context(system_u:object_r:bluetooth_exec_t,s0)
>> diff --git a/policy/modules/services/bluetooth.if b/policy/modules/services/bluetooth.if
>> index c7e1c3f14..c869eed71 100644
>> --- a/policy/modules/services/bluetooth.if
>> +++ b/policy/modules/services/bluetooth.if
>> @@ -82,6 +82,9 @@ interface(`bluetooth_stream_connect',`
>> files_search_runtime($1)
>> allow $1 bluetooth_t:socket rw_socket_perms;
>> + allow $1 bluetooth_t:bluetooth_socket rw_socket_perms;
>> + allow $1 bluetooth_t:unix_stream_socket { accept connectto listen rw_socket_perms };
>> + allow $1 bluetooth_t:fd use;
>> stream_connect_pattern($1, bluetooth_runtime_t, bluetooth_runtime_t, bluetooth_t)
>> ')
>
> I have two main concerns:
>
> 1. is the added access in this interface required for all users that connect to bluetoothd over a unix domain socket?
>
As per my understanding any user who wants to use bluetooth over unix domain has to make dbus calls to bluetoothd. So I feel its required. For example- bluetooth_stream_connect is currently being used by pulseaudio_t and obex_t as well, these services also use dbus methods.
Please let us know your opinion on this or better way to fix these AVC denials.
> 2. does bluetoothctl really need all the access of the bluetooth_t domain? It may only need a small permission set, like udev and udevctl.
>
>
By default bluetoothctl is running in initrc_t domain so added bluetooth_exec_t domain to bluetoothctl. bluetoothctl is command line tool to access whole bluetooth functionality like pair/unpair/connect/disconnect etc. There are other tools like hciattach, rfcomm which are using same domain bluetooth_exec_t.
- Naga Bhavani Akella
next prev parent reply other threads:[~2024-05-15 7:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-14 7:21 [PATCH v1] Adding Sepolicy rules to allow bluetoothctl and dbus-daemon to access unix stream sockets Naga Bhavani Akella
2024-05-14 20:12 ` Chris PeBenito
2024-05-15 7:29 ` Naga Bhavani Akella [this message]
2024-05-15 13:51 ` Chris PeBenito
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=695f447e-b9db-414f-8fa5-1b12b8379c48@quicinc.com \
--to=quic_nakella@quicinc.com \
--cc=pebenito@ieee.org \
--cc=quic_anubhavg@quicinc.com \
--cc=quic_hbandi@quicinc.com \
--cc=quic_mohamull@quicinc.com \
--cc=selinux-refpolicy@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).