Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933306AbbD2PQk (ORCPT ); Wed, 29 Apr 2015 11:16:40 -0400 Received: from bhuna.collabora.co.uk ([93.93.135.160]:55193 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933211AbbD2PQi (ORCPT ); Wed, 29 Apr 2015 11:16:38 -0400 Message-ID: <5540F637.1090803@collabora.co.uk> Date: Wed, 29 Apr 2015 16:18:15 +0100 From: Simon McVittie Organization: Collabora Ltd. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Stephen Smalley , Harald Hoyer , John Stoffel , Havoc Pennington CC: "Theodore Ts'o" , Linus Torvalds , Andy Lutomirski , Lukasz Skalski , Greg Kroah-Hartman , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni , Paul Moore , James Morris , LSM Subject: Re: [GIT PULL] kdbus for 4.1-rc1 References: <20150423163616.GA10874@kroah.com> <20150423171640.GA11227@kroah.com> <553A4A2F.5090406@samsung.com> <20150428171840.GB11351@thunk.org> <21824.5086.446831.189915@quad.stoffel.home> <5540D2F9.2010704@redhat.com> <5540DE30.7050105@tycho.nsa.gov> In-Reply-To: <5540DE30.7050105@tycho.nsa.gov> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3860 Lines: 78 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. 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/