Show Your Support: This site is primarily supported by advertisements. Ads are what have allowed this site to be maintained on a daily basis for the past 18+ years. We do our best to ensure only clean, relevant ads are shown, when any nasty ads are detected, we work to remove them ASAP. If you would like to view the site without ads while still supporting our work, please consider our ad-free Phoronix Premium.
The NSA Is Looking At Systemd's KDBUS
While it's true that an NSA analyst sent out an email about KDBUS security, it hopefully shouldn't raise any alarm bells. The thread in question is about credential faking for KDBUS and why it's even there. Stephen Smalley of the NSA was asking why there's support for credential faking for this soon-to-be-in-kernel code while it wasn't part of the original D-Bus daemon in user-space. The preference of Stephen Smalley is to actually get rood of this functionality that could be abused.
It turns out this credential faking is needed for Dbus1 compatibility in part for faking meta-data. David Herrmann explained:
To be clear, faking metadata has one use-case, and one use-case only: dbus1 compatibility
In dbus1, clients connect to a unix-socket placed in the file-system hierarchy. To avoid breaking ABI for old clients, we support a unix-kdbus proxy. This proxy is called systemd-bus-proxyd. It is spawned once for each bus we proxy and simply remarshals messages from the client to kdbus and vice versa.
With dbus1, clients can ask the dbus-daemon for the seclabel of a peer they talk to. They're free to use this information for any purpose. On kdbus, we want to be compatible to dbus-daemon. Therefore, if a native client queries kdbus for the seclabel of a peer behind a proxy, we want that query to return the actual seclabel of the peer, not the seclabel of the proxy. Same applies to PIDS and CREDS.
This faked metadata is never used by the kernel for any security decisions. It's sole purpose is to return them if a native kdbus client queries another peer. Furthermore, this information is never transmitted as send-time metadata (as it is, in no way, send-time metadata), but only if you explicitly query the connection-time metadata of a peer (KDBUS_CMD_CONN_INFO).
Stephen Smalley is part of the Trusted Systems Research Group at the NSA. He's long been involved with SELinux (Security Enhanced Linux) while more recently is also part of the NSA's Security Enhanced Android (SEAndroid) project. All in all, this really shouldn't be worrisome or news worthy, unless you're wearing a tin hat.