http://bugzilla.suse.com/show_bug.cgi?id=1151518
http://bugzilla.suse.com/show_bug.cgi?id=1151518#c3
Matthias Gerstner changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |1152672
Summary|AUDIT-0: bluez: new D-Bus |AUDIT-TRACKER: bluez: new
|service |D-Bus service
|/etc/dbus-1/system.d/blueto |/etc/dbus-1/system.d/blueto
|oth-mesh.conf |oth-mesh.conf
--- Comment #3 from Matthias Gerstner ---
So I'm finished with the review. This new D-Bus service is quite a complex
implementation. It provides a kind of bluetooth mesh networking stack to other
users in the system via D-Bus.
Applications can register themselves at the service and the service will in
turn connect to a network application implemented on the users end of the
D-Bus. This is quite a sensitive setup, since the privileged D-Bus service
running as root now calls into an unprivileged D-Bus service running as a
regular user.
In bug 1152672 I've found a DoS vector that allows regular users to crash the
mesh service running as root.
Generally there's little isolation of different users of the bluetooth-mesh
service against each other. For example user A may start a Join operation
while an arbitrary other user B may cancel a join operation that is currently
in progress. As an exception the Node1 interface is only accessible to the
process that registered it in the first place.
The Management1 interface allows regular users to create a lot of small files
in /var/lib/bluetooth/mesh. Per network it's possible to allocate about 256
MiB of data for e.g. device keys so this has the potential to fill up /var.
Also with this interface arbitrary users may add/delete/update network keys,
device keys or app keys.
Given that the mesh network is rather a niche feature I think doing an
in-depth audit of this component isn't worth it. I don't feel very comfortable
having such a complex service around, however, accessible to everybody. By
default it's not autostarted, because the D-Bus config references an aliased
systemd service that is only installed when the bluetooth-mesh service is
enabled on systemd level.
I would find it better to limit the D-Bus access to this mesh D-Bus service to
members of a separate group. This would make it even more explicit and only
allows users that actually want to work with mesh network to talk to the new
service. Is there a suitable group already around that could be used for this?
A patch of the D-Bus config will be necessary to implement it.
--
You are receiving this mail because:
You are on the CC list for the bug.
