[systemd-devel] SD_BUS_VTABLE_CAPABILITY

Simon McVittie simon.mcvittie at collabora.co.uk
Fri Apr 17 05:43:45 PDT 2015


On 16/04/15 15:52, Andy Lutomirski wrote:
> (I really think this dichotomy
> needs to be removed, *especially* since it looks like code already
> exists to try to use both metadata sources.  This seems like it's just
> asking for security screw-ups.)

Would it address this concern if there was an explicit API separation
into "things that can't be faked, suitable for authorization" and
"things that could have been faked, only suitable for debugging" - such
that the uid would be in the first set only, capabilities would be in
the first set on kdbus but absent or in the second set on traditional
D-Bus, and /proc/*/cmdline would always be in the second set?

That's effectively what dbus-daemon has internally: for each
DBusConnection (which in practice wraps an AF_UNIX socket), it tracks
the uid, the pid, and in recent versions the LSM label (all taken from
getsockopt results), and a "log info" string (derived from /proc/$pid).

The "log info" is mentioned in the syslog message when something is
denied, but is not used for authentication, and is not made available to
dbus-daemon's clients such as polkit.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>


More information about the systemd-devel mailing list