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.

I will look into it now.

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.

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.

(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.

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 ;-)

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.