On 29/04/15 14:35, Stephen Smalley wrote: > As it currently stands, there > are no LSM hook calls in the kdbus tree beyond metadata collection of > security labels.
SELinux and AppArmor are the two particularly interesting LSMs here: those are the ones that have support for user-space mediation in dbus-daemon, and hence the ones for which replacing dbus-daemon with kdbus, without LSM hooks, would be a regression. > It is also interesting that kdbus allows impersonation of any > credential, including security label, by "privileged" clients, where > privileged simply means it either has CAP_IPC_OWNER or owns (euid > matches uid) the bus. FWIW, this particular feature is *not* one of those that are necessary for feature parity with dbus-daemon. There's no API for making dbus-daemon fake its clients' credentials; if you can ptrace it, then you can of course subvert it arbitrarily, but nothing less hackish than that is currently offered. > On 04/29/2015 08:47 AM, Harald Hoyer wrote: >> * Eavesdropping on the kernel level, so privileged users can hook into >> the message stream without hacking support for that into their >> userspace processes > > This one worried me a bit, particularly the statement that such > eavesdropping is unobservable by any other participant on the bus. > Seems a bit prone to abuse, particularly since it can be done by any > privileged client, not merely the process that originally created the bus? For feature parity with dbus-daemon, the fact that eavesdropping/monitoring *exists* is necessary (it's a widely used developer/sysadmin feature) but the precise mechanics of how you get it are not necessarily set in stone. In particular, if you think kdbus' definition of "are you privileged?" may be too broad, that seems a valid question to be asking. In traditional D-Bus, individual users can normally eavesdrop/monitor on their own session buses (which are not a security boundary, unless specially reconfigured), and this is a useful property; on non-LSM systems without special configuration, each user should ideally be able to monitor their own kdbus user bus, too. The system bus *is* a security boundary, and administrative privileges should be required to eavesdrop on it. At a high level, someone with "full root privileges" should be able to eavesdrop, and ordinary users should not; there are various possible criteria for distinguishing between those two extremes, and I have no opinion on whether CAP_IPC_OWNER is the most appropriate cutoff point. In dbus-daemon, LSMs with integration code in dbus-daemon have the opportunity to mediate eavesdropping specially. SELinux does not currently do this (as far as I can see), but AppArmor does, so AppArmor-confined processes are not normally allowed to eavesdrop on the session bus (even though the same user's unconfined processes may). That seems like one of the obvious places for an LSM hook in kdbus. Having eavesdropping be unobservable means that applications cannot change their behaviour while they are being watched, either maliciously (to hide from investigation) or accidentally (bugs that only happen when not being debugged are the hardest to fix). dbus-daemon's traditional implementation of eavesdropping has had side-effects in the past, which is undesirable, and is addressed by the new monitoring interface in version 1.9. kdbus' version of eavesdropping is quite similar to the new monitoring interface. -- Simon McVittie Collabora Ltd. <http://www.collabora.com/> For context, I am a D-Bus maintainer, but neither the original designer of D-Bus nor a kdbus developer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
