Support for send_destination_prefix

[ya-mouse]

Currently dbus-broker supports only own_prefix as a busconfig's allow/deny attribute. That would be great to add support for send_destination_prefix as well as dbus daemon supports.

[dvdhrm]

Yeah, this was added in June 2019, a bit after we made dbus-broker synchronize the policy language with dbus-daemon. That's why it does not show up in dbus-broker.

Can you explain why you think this is needed? Other than for compatibility.

Note that adding this means every bus-transaction now needs a multiple of its original policy checks. So instead of one policy check for org.example.foo.bar, we now need 5 checks for "", "org", "org.example", "org.example.foo", "org.example.foo.bar". This will slow down bus operations significantly. For own_prefix this is not as big an issue, because claiming-names is not as crucial. But the send_destionation_prefix will happen on every single bus message.

[ya-mouse]

We need to control send_destination to a specific end-points: e.g. xyz.openbmc_project.Hwmon.id-3972539786.Hwmon1 where is id- part is a hash-based. Owning of such names is not a problem via own_prefix.

[dvdhrm]

We need to control send_destination to a specific end-points: e.g. xyz.openbmc_project.Hwmon.id-3972539786.Hwmon1 where is id- part is a hash-based. Owning of such names is not a problem via own_prefix.

Can you elaborate on this? Why do you need to have policies at all? What do you protect against? Why do you use randomized names? Would policies based on interfaces suffice? Etc.

[ya-mouse]

Default rule is disallow send_destination by any user/group. We should explicitly allow accessing specific destination by a specific set of users/groups. Some service has a pathname as a part of the name (it hashed): https://github.com/openbmc/phosphor-hwmon/blob/master/mainloop.cpp#L373-L375 PS. Please pay attention, that the _prefix << "-" for busname should be repalced with _prefix << ".id-" (or similar) to make it work with *_prefix attributes.

[ya-mouse]

One possible workaround could be to pre-generate configs with such names (they knonw in advance). But some of services has 20+ identical prefix for send_destination (within the same daemon). This list is also dynamic (configuration-based).

[dsommers]

For OpenVPN 3 Linux this would be a useful feature.

The unprivileged user on the system sends a "I need a VPN tunnel" to our VPN session manager. This runs unprivileged as the openvpn user. The responsibility of the session manager is purely to manage all running OpenVPN connections (sessions). When creating a new session, the session manager starts a new VPN client process for this session alone. This registers its own busname which is unique per process. The end-user will communicate with the VPN client process entirely via the session manager. To restrict the communication channel better from the VPN client process to the session manager, being able to allow a prefix of sender names in the policy would help us with further hardening the implementation. Our current workaround now is to restrict these methods in the session manager by using the interface name and to have code in the session manager to restrict the UID/GID of the sender of these messages. And Debian packaging sanity checks complains loudly about the D-Bus policy not being well defined (which we so far have ignored).

One of the design goals of OpenVPN 3 Linux is to make it run with as few privileges as ever possible, and to split up the whole VPN stack into loosely coupled units communicating with each other purely over D-Bus. This is to further restrict what each component is capable to do, so if one component collapses or gets compromised the potential damage is limited. So to be able to harden the communication channel further between the VPN client process and the session manager would be valuable for us.