"dbus-monitor --system" stopped monitoring method calls remotely

[Simon McVittie]

On Thu, 12 Jul 2018 at 19:37:47 -0700, L A Walsh wrote:
> Simon McVittie wrote:
> > * on a totally trusted LAN in conjunction with NFS-shared home
> >   directories on Unix (but in 2018 I don't think this is really valid
> >   any more, because LANs that you can totally trust are increasingly rare)
> ----     Lans that only only have secure connections to them, such as ssh
> or vpns, are rare?

Unfortunately yes. As soon as an untrusted (either malicious or
easily-hacked) mobile phone, printer, TV, smart lightbulb, etc. gets
access to the LAN, that device can eavesdrop on all unencrypted
communications on that LAN and can impersonate other devices on that
LAN. D-Bus is not suitable for such environments.

> > If you are using the ANONYMOUS authentication mechanism, that is doubly
> > insecure. I am seriously considering removing <allow_anonymous/> from
> > the dbus-daemon: it might occasionally be valid for "peer to peer" D-Bus,
> > but it is not a reasonable thing to do for a dbus-daemon.
> ---
>    Why

The standard system bus is designed to connect mutually distrusting
processes and allow them to carry out controlled privilege escalation. To
make privilege escalation controlled, the system service that is offering
privileged operations needs to check that the requester is authorized
to carry out that operation. System services cannot make an informed
authorization decision if the answer to "who asked for this?" is "I
don't know, they wouldn't tell me".

Conversely, the standard session bus is designed to connect mutually
trusting processes belonging to the same user. A session service or
client should be able to assume that everything else on the bus is
equally-privileged. Allowing other users' processes to connect to a
session bus - either with the other user's credentials, or anonymously -
would break that assumption.

> > Exposing D-Bus over TCP and enabling ANONYMOUS authentication were
> > among the factors that led to a recall of 1.4 million unsafe vehicles:
> > <http://www.bbc.co.uk/news/technology-33650491>.
> ----
>    Vehicles are a poor comparison to a stationary, closed environment.
>    Especially, since vehicles almost never (maybe never?) use a wired
> connection on a closed network.

In-vehicle network developers assumed that their environment was closed
and secure. This assumption was incorrect, with a rather expensive result.
Thankfully I'm not aware of any deaths or injuries resulting from this,
but there could have been.

> > To monitor the system bus, you will need to be either root (uid 0) or
> > the uid that is running the system bus (usually named messagebus or
> > dbus, but it depends on your OS distribution). To monitor a session
> > bus, you need to be the same uid that is running the session bus.
> ---
>    You don't use access lists or standard unix/linux access mechanisms?

Kernel-level access control determines who can connect to the bus; in
the case of the system bus that's "everyone", and in the case of the
session bus that's just your own uid. For the system bus, dbus-daemon
needs to do its own access control within that, to determine who can
and can't do particular privileged operations.

Older versions of dbus-daemon had general-purpose access control lists
to control everything (including privileged operations), but it came to
our attention that several system services misconfigured those ACLs to be
very insecure (CVE-2014-8148 is a particularly bad example). As a result,
to mitigate misconfigurations like that one, we've moved towards a model
where the most sensitive operations (like monitoring) are hard-coded
to only be available to what we call "privileged" connections: root and
the uid of the dbus-daemon process itself. (Note that those are the same
user IDs that could equally well violate confidentiality by reading out
the dbus-daemon's memory via ptrace.)

There has been a proposal in the past to add a separate "management"
socket to the system bus, and only accept privileged operations on
connections that came in via that management socket. However, nobody has
implemented this, whereas what we have now is simple enough that someone
had the resources to implement it.

Not all OS kernels apply filesystem-level permissions to path-based
AF_UNIX sockets, Linux does not apply filesystem-level permissions to
abstract AF_UNIX sockets (which don't exist in the filesystem at all),
and as far as I'm aware no kernel applies filesystem-level permissions to
TCP sockets, so we cannot rely on standard filesystem-level permissions
here - if we did, the resulting system would be insecure.

>    Is this a case of moving toward users having to run as root more often
> to do anything useful?

The session bus does not have this restriction, because only your own
uid can connect to your session bus. Because your uid matches the uid
of the dbus-daemon process, you can monitor your own session bus without
special privileges.

Monitoring the system bus breaks the security properties that the
system bus is normally designed to provide. System services and their
clients are meant to be able to exchange method calls and replies (but
not signals) containing confidential information, such as wifi and VPN
passphrases for NetworkManager. Allowing everyone to monitor the system
bus would violate that confidentiality. This is the same reasoning that
says only root can read out the NetworkManager process's memory contents,
only root and members of the adm group (on Debian, group names vary in
other distributions) can read the syslog, and so on.

Monitoring the system bus is a specialized operation for developers, so
it is far from true to say that you cannot do anything useful with D-Bus
without monitoring. For the first 10 years of dbus' lifetime, there was
no way to monitor the system bus without removing its security properties
altogether (legacy "eavesdropping" was poorly designed and could not do
this), so the addition of the Monitoring interface has not reduced what
you can do. The Monitoring interface has always had its current security
checks. dbus-monitor(1) is an ordinary D-Bus client that uses Monitoring
if possible, or legacy eavesdropping if Monitoring is unavailable or
not allowed: you could do the same things from other C code, and in fact
we already have unit tests that do.

The bottom line here is that some actions violate the security model
of a system (for instance monitoring the system bus breaks a
confidentiality property that we intended to provide). If we allow them
globally, then the system becomes insecure: anything that was relying
on those security properties can no longer do so. We can either allow
them to only a subset of connections, or forbid them completely.
Monitoring is useful, so we don't want to forbid it completely; and
limiting it to specific uids is simple, robust, and unlikely to lead
to new security vulnerabilities.

A fully configurable ACL would be more flexible, yes, but it's one more
thing that can go horribly wrong, and we should always err on the side of
safety at security boundaries.

> > On dbus 1.10+
> > (Ubuntu 16.04/xenial or later) the instructions for the system bus can
> > be simplified to: "Run sudo dbus-monitor --system".
> ---
>    Might as well suggest:
> 
>    # chmod u+s dbus-monitor

No, never do this. dbus-monitor is not designed to be a security boundary.
Only programs that are designed to act as a security boundary (such as
sudo, su and dbus-daemon-launch-helper) can safely be setuid.

If you don't like setuid (and you're right to dislike it, but it's one
of the tools in the Unix toolbox), users with suitable credentials can
also arrange for code to be run as root via inter-process communication,
for instance by sending D-Bus messages to systemd (for which authorization
will be confirmed via polkit) or by opening a loopback ssh connection.

    smcv