On Fri, 17.04.15 13:43, Simon McVittie (simon.mcvit...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
