linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 29 Apr 2015 13:48:39 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Simon McVittie <simon.mcvittie@...labora.co.uk>,
	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 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/