Re: [GIT PULL] kdbus for 4.1-rc1

[Stephen Smalley]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/