On 04/29/2015 11:18 AM, Simon McVittie wrote: > On 29/04/15 14:35, Stephen Smalley wrote: >> 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.
Then I'd be inclined to drop it from kdbus unless some compelling use case exists, and even then, I don't believe that CAP_IPC_OWNER or bus-owner uid match is sufficient even for forging credentials other than the security label. For socket credentials passing, for example, the kernel checks CAP_SYS_ADMIN for pid forging, CAP_SETUID for uid forging, and CAP_SETGID for gid forging. And I don't believe we support any form of forging of the security label on socket credentials. > 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. Yes, we would want to control this in SELinux; I suspect that either the eavesdropping functionality did not exist in dbus-daemon at the time of the original dbus-daemon SELinux integration or it was an oversight. > 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. -- 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/