[systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Lennart Poettering]

On Fri, 17.04.15 13:43, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

> 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?

Note that sd-bus exposes an sd_bus_creds API that collects credentials
about bus peers. And it by default only includes credentials that can
be acquired without races. To augment the data with stuff from /proc
you need to pass a special flag (SD_BUS_CREDS_AUGMENT) that it
basically the developer's opt-in to saying "I know this is racy, but I
want the data anyway".

I also prepared a patch that keeps a mask in the object that can be
queried later on that will tell you if the data was acquired via this
race-ful augmentation from /proc, or can be trusted. I will then
update systemd's code to explicitly check this mask, as an extra
safety net, and to make explicit in code what we require for
authentication and what not.

> 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.

Yeah, it's pretty close to what we exose in sd-bus in that regard.

Lennart

-- 
Lennart Poettering, Red Hat