Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933343AbbD2RuG (ORCPT ); Wed, 29 Apr 2015 13:50:06 -0400 Received: from emvm-gh1-uea09.nsa.gov ([63.239.67.10]:50417 "EHLO emvm-gh1-uea09.nsa.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933266AbbD2Rt7 (ORCPT ); Wed, 29 Apr 2015 13:49:59 -0400 X-TM-IMSS-Message-ID: <34d377d30000d8f9@nsa.gov> Message-ID: <55411977.1060007@tycho.nsa.gov> Date: Wed, 29 Apr 2015 13:48:39 -0400 From: Stephen Smalley Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Simon McVittie , 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> <5540F637.1090803@collabora.co.uk> In-Reply-To: <5540F637.1090803@collabora.co.uk> 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: 3642 Lines: 65 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/