Message-ID: <5540DE30.7050105@tycho.nsa.gov>
Date:	Wed, 29 Apr 2015 09:35:44 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	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 08:47 AM, Harald Hoyer wrote:
> On 29.04.2015 01:12, John Stoffel wrote:
>> LDAP is pretty damn generic, in that you can put pretty large objects into
>> it, and pretty large OUs, etc.  So why would it be a candidate for going
>> into the kernel?  And why is kdbus so important in the kernel as well?
>> People have talked about it needing to be there for bootup, but isn't that
>> why we ripped out RAID detection and such from the kernel and built
>> initramfs, so that there's LESS in the kernel, and more in an early
>> userspace?  Same idea with dbus in my opinion.
> 
> Let me elaborate on the initramfs/shutdown situation a little bit more,
> because I have to deal with that every day.
> 
> Because of the "let's move everything to userspace" sentiment we nowadays
> have the situation, that we need a lot of tools to setup the root device.
> 
> Be it LVM on IMSM or iSCSI multipath, the initramfs has to setup the network
> (with bridging, bonding, etc.), the iSCSI connection, assemble the raid, the
> LVM, open crypto devices, etc...
> And if something goes wrong, you want to have a shell, see all the logs and
> debug things.
> 
> Now over the time we moved away from simple shell scripts (without any
> logging) and static compiled special versions for the initramfs to a mini
> distribution in the initramfs, which simplifies maintenance and improves
> reliability.
> 
> Basically you want to use the same tools in the initramfs (and shutdown)
> which you already have and use in your real root, with the same configuration
> files and the same interfaces and the same code paths.
> 
> Therefore systemd is started in dracut created initramfs, which starts
> journald for logging. The same basic systemd targets exist in the initramfs
> as on the real root, so normally you don't have to cope with specialized
> versions for the initramfs.
> 
> The target here is to have the same IPC mechanism from the very beginning to
> the very end. No crappy fallback mechanisms in case a daemon is not running
> or has crashed, no creepy transition from initramfs root to real root to
> shutdown root.
> 
> We already have such transitions like: systemd, journald, mdmon [1], etc.
> systemd has to serialize itself, journald's file descriptors are transitioned
> over, mdmon jumps through hoops. Remember you want to get rid of open files
> and executables and have to reexec everything, if you transition from the
> initramfs root to the real root, and also from the real root to the shutdown
> root.
> 
> We really don't want the IPC mechanism to be in a flux state. All tools have
> to fallback to a non-standard mechanism in that case.
> 
> If I have to pull in a dbus daemon in the initramfs, we still have the
> chicken and egg problem for PID 1 talking to the logging daemon and starting
> dbus.
> systemd cannot talk to journald via dbus unless dbus-daemon is started, dbus
> cannot log anything on startup, if journald is not running, etc...
> 
> dbus-daemon would have to transition to the real root, and from the real root
> to the shutdown root, without losing state.
> 
> Of course this can all be done, but it would involve fallback mechanisms,
> which we want to get rid off. Hopefully, you don't suggest to merge dbus with
> PID 1. Also with a daemon, you will lose the points mentioned in the cover mail
> :
> 
>  * Security: The peers which communicate do not have to trust each
>    other, as the only trustworthy component in the game is the kernel
>    which adds metadata and ensures that all data passed as payload is
>    either copied or sealed, so that the receiver can parse the data
>    without having to protect against changing memory while parsing
>    buffers. Also, all the data transfer is controlled by the kernel,
>    so that LSMs can track and control what is going on, without
>    involving userspace. Because of the LSM issue, security people are
>    much happier with this model than the current scheme of having to
>    hook into dbus to mediate things.

I just want to caution that this justification for kdbus is not fully
realized in the current implementation.  As it currently stands, there
are no LSM hook calls in the kdbus tree beyond metadata collection of
security labels.  I know there have been experimental proof-of-concept
patches floating around for LSM hooks for kdbus but they aren't merged
as of yet, nor are there any real implementations of the hooks for the
security modules.  If kdbus is merged, we need to make sure that the LSM
support is integrated before it gets enabled in any distros or we'll
have a completely unmediated IPC channel, i.e. a bypass of any security
policy restrictions on IPC.

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.  That seems wrong at least for security labels;
either we should not support impersonation of security labels at all or
at least it should be controlled by the security module based on its own
logic and attributes, not based on CAP_IPC_OWNER or a uid match.

Has anyone even reviewed the privilege and UID-based model of kdbus for
its implications with respect to discretionary access control?

>  * Being in the kernel closes a lot of races which can't be fixed with
>    the current userspace solutions.  For example, with kdbus, there is a
>    way a client can disconnect from a bus, but do so only if no further
>    messages present in its queue, which is crucial for implementing
>    race-free "exit-on-idle" services
> 
>  * 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?
--
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