Bug 1151518 - AUDIT-TRACKER: bluez: new D-Bus service /etc/dbus-1/system.d/bluetooth-mesh.conf
AUDIT-TRACKER: bluez: new D-Bus service /etc/dbus-1/system.d/bluetooth-mesh.conf
Status: RESOLVED WONTFIX
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Matthias Gerstner
E-mail List
:
Depends on: 1152672
Blocks:
  Show dependency treegraph
 
Reported: 2019-09-20 20:09 UTC by Stefan Seyfried
Modified: 2019-10-04 08:05 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Seyfried 2019-09-20 20:09:16 UTC
After updating bluez to 5.51, I get this (already disarmed by a rpmlintrc), so I'm filing a bug as requested.

Please do the needful AQAP ;-), submission to factory is planned for now.

[  117s] bluez.x86_64: E: suse-dbus-unauthorized-service (Badness: 100) /etc/dbus-1/system.d/bluetooth-mesh.conf
[  117s] bluez.x86_64: E: suse-dbus-unauthorized-service (Badness: 100) /usr/share/dbus-1/system-services/org.bluez.mesh.service
[  117s] The package installs a DBUS system service file. If the package is intended
[  117s] for inclusion in any SUSE product please open a bug report to request review
[  117s] of the service by the security team. Please refer to
[  117s] https://en.opensuse.org/openSUSE:Package_security_guidelines#audit_bugs for
[  117s] more information.

Package is right now in home:seife:testing/bluez, and I'll submit it to Base:System now to check if it builds on all platforms.
Comment 1 Matthias Gerstner 2019-09-23 09:54:04 UTC
Thank you for opening the bug. We will schedule the review. It might take some
time, however, since there is already a longer queue at the moment.
Comment 2 Matthias Gerstner 2019-09-24 11:12:53 UTC
I will look into it now.
Comment 3 Matthias Gerstner 2019-10-01 12:16:34 UTC
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.
Comment 4 Stefan Seyfried 2019-10-02 04:40:03 UTC
I agree with the assessment that this is a niche feature right now, I do not even know how to use it at all ;-)

For now I suddest to disable the mesh dbus-config, maybe ship it as an example with a README in the package docs.

Regarding a special group that gives access to the feature: as the feature is very special, probably a dedicated group for it would be justified, but I'd go this way once there are users for the feature and a real demand for it, if it is still necessary then.
Comment 5 Matthias Gerstner 2019-10-02 11:04:55 UTC
(In reply to seife@novell.slipkontur.de from comment #4)
> For now I suddest to disable the mesh dbus-config, maybe ship it as an
> example with a README in the package docs.

If you want to take this route then it is fine from my side. Then we
(security team) have nothing to do. By not installing the mesh dbus-config the
rpmlint error will go away.
Comment 6 Stefan Seyfried 2019-10-02 14:19:44 UTC
I'd prefer to go for that route, until users demand the mesh feature.

I don't know of any software using this right now.

Once users of this appear, hopefully the security implications will have improved.
I'll come back for a review then.

https://build.opensuse.org/request/show/734517 is the request with the config removed, I hust have to fight the factory-auto bot to get it in ;-)
Comment 7 Matthias Gerstner 2019-10-04 08:05:57 UTC
Okay then, thanks for bringing this review up with us. I've documented what
I've learned so far in this bug and in our internal wiki. Should we need to
revisit the mesh daemon then we can pick up from there.

I'm closing this bug as WONTFIX. Feel free to contact us again should there be
any need.