Re: [GIT PULL] kdbus for 4.1-rc1

[Simon McVittie]

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