Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 10 May 2017 11:54:56 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Cc: Albert Astals Cid <aacid@....org>
Subject: Re: generic kde LPE

On Wed, 10 May 2017 at 12:05:04 +0200, Sebastian Krahmer wrote:
> The callerID usually looks like ":1.123"
> and is a DBUS unique name that maps to the sender of the message.
> You can think of it like the source address of an IP packet.
> This ID should be obtained via a DBUS function while the message is
> arriving, so it can actually be trusted and used as a subject for polit
> authorizations when using systembus-name subjects. Allowing callers to
> arbitrarily choosing values for this ID is taking down the whole idea
> of authentication and authorization.

Yes - the analogy "unique name is like an IP address" is a good one here.
When receiving an IP packet, you might trust the source address in the IP
header, but not an IP address mentioned in the packet's body (payload).
It's the same in D-Bus.

It's also suspicious that the "callerID" is a byte array (D-Bus type 'ay');
that makes me wonder whether it was originally intended to be something
other than a D-Bus unique name. D-Bus unique names are constrained to a
subset of printable ASCII, and in particular are always valid for the
D-Bus string type 's' (which contains arbitrary UTF-8, excluding U+0000,
overlong encodings and non-characters), so it is not necessary to use
a byte-array.

This is probably a good opportunity for me to clarify which
security-sensitive things you can rely on receiving in a trusted way[1]
via D-Bus. They are:

* The unique name of the message sender (dbus_message_get_sender(),
  g_dbus_method_invocation_get_sender() and similar APIs)

* The Unix uid corresponding to a unique name, available by calling
  the GetConnectionCredentials or GetConnectionUnixUser method on
  the dbus-daemon's org.freedesktop.DBus bus name and interface

* The Unix pid corresponding to a unique name, available by calling
  the GetConnectionCredentials or GetConnectionUnixProcessID method
  (but be careful: you can't safely use this pid to look up further
  information in /proc[2])

* The Linux LSM (AppArmor, SELinux, Smack etc.) label corresponding
  to a unique name, available by calling the GetConnectionCredentials
  method

It is not coincidental that these match the information that the
dbus-daemon can get from the kernel in a trusted way by querying
the AF_UNIX socket that it uses to communicate with the peer, via
the SO_PEERCRED and SO_PEERSEC socket options or their non-Linux
equivalents[3].

(By the way, the protocol is called D-Bus and the reference implementation
is dbus. There is nothing called DBUS, and it isn't an acronym.)

Regards,
    S

[1] This requires trusting the dbus-daemon to not lie to you, which in
    practice you must, unless you do some sort of out-of-band
    authentication. On practical Unix systems the system dbus-daemon
    is a security boundary (a trusted component, in the infosec sense that
    it is in a position where it could break your security policy). If
    using LSMs, the session dbus-daemon is potentially also a security
    boundary for the security domains represented by LSM labels.
[2] This would be unsafe because a malicious process could change the
    apparent credentials of a particular pid by queuing up outgoing
    messages that it wants to be interpreted as though their sender had
    higher privilege, then exec()ing a setuid or similarly
    privileged executable. Rather more tenuously, it could also try
    arranging for the 15-bit process ID space to wrap around and then
    exiting at just the right time before a more privileged process
    forks, although that probably isn't a practically feasible attack.
[3] SO_PEERCRED technically also tells us the primary gid,
    but we don't expose that information in dbus-daemon, because the
    distinction between primary and supplementary group IDs seems
    needlessly confusing.

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ