lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 29 Apr 2015 16:18:15 +0100 From: Simon McVittie <simon.mcvittie@...labora.co.uk> To: Stephen Smalley <sds@...ho.nsa.gov>, Harald Hoyer <harald@...hat.com>, John Stoffel <john@...ffel.org>, Havoc Pennington <hp@...ox.com> CC: Theodore Ts'o <tytso@....edu>, Linus Torvalds <torvalds@...ux-foundation.org>, Andy Lutomirski <luto@...capital.net>, Lukasz Skalski <l.skalski@...sung.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Andrew Morton <akpm@...ux-foundation.org>, Arnd Bergmann <arnd@...db.de>, "Eric W. Biederman" <ebiederm@...ssion.com>, One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>, Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Daniel Mack <daniel@...que.org>, David Herrmann <dh.herrmann@...il.com>, Djalal Harouni <tixxdz@...ndz.org>, Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>, LSM <linux-security-module@...r.kernel.org> Subject: Re: [GIT PULL] kdbus for 4.1-rc1 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists