Message Bus Security Considerations

anti-spoofing

There is nothing native to zeromq similar to the functionality described in the cell to the right for dbus (unique connection names, etc.) so the implementer would have to identify and build those solutions in. As such, the implementer would have to implement a solution (e.g a key-based signing mechanism) to cryptographically prevent spoofing. While zeromq does not have a built in key-based mechanism it could certainly be implemented. Some things to note here:

• The proposed ZeroMQ implementation would address spoofing/snooping with file permissions. Assume each application runs under a distinct user (the Android model). The manifest system could create a directory for each pub/sub “network”. The directories would be available for ZeroMQ to create and manage sockets. These directories would have permissions defined, such that only the publisher would have write access, and specified subscribers would have read access.

• We shouldn’t be heading down the need to encrypt/sign every message over the message bus since it’s entirely on-device. crypto is good for off-device, but we aren’t talking about that. The OS or mbus daemon should be providing isolation and accounting using isolated communication mechanisms (i.e. point to point, daemon<->app)

Dbus does offer a variety of functionality to otherwise help with anti-spoofing: unique connection names, process limitations to well-known names registered by services, security policies enforcing which processes can connect to the bus/send messages/receive messages from specific sources/register well-known names and authentication. While dbus does not have a built in key-based mechanism it could certainly be implemented.

anti-snooping

Encryption capabilities exist to be used, e.g. via APIs that can integrate with encryption capabilities, but enforcement and adoption would be on the implementer. Unlike dbus there is no zeromq dbus-monitor equivalent, however, anti-snooping still requires proper design across authentication, authorization, networking, topic filtering, etc. to mitigate within risk tolerance.

One of the bigger considerations with dbus is who/what can use the dbus-monitor tool which is a powerful capability that can be used to sniff messages. Based on initial research it appears as though there are ways to take a layered approach to restrict a container’s access via security policies, by leveraging systemd-nspawn to limit container access and something like seccomp/apparmor/selinux profiles. A mitigation here would also be encryption assuming that whatever can use dbus-monitor does not have the access needed to also decrypt.

debugging

There is nothing equivalent to dbus-monitor for zeromq, however, there are ways to achieve similar capabilities with some work, however, depending on the approach it could be a per-container solution so the pros and cons of that should be considered.

As indicated above dbus-monitor is a powerful tool that can help with this, however, it also wields great power so you have to balance it against anti-snooping and spoofing requirements. This should also be weighed against zeromq because dbus-monitor plugs into the dbus daemon running on host so it provides some unification, but again, with great power comes great responsibility.