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.