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]

Message-ID: <20150416180310.GA5382@dztty>
Date:	Thu, 16 Apr 2015 19:03:10 +0100
From:	Djalal Harouni <tixxdz@...ndz.org>
To:	Rik van Riel <riel@...hat.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Havoc Pennington <hp@...ox.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tom Gundersen <teg@...m.no>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

Hi,

On Wed, Apr 15, 2015 at 05:07:28PM -0400, Rik van Riel wrote:
[...]
> > This leads me to a potentially interesting question: where's the
> > buffering?  If there's a bus with lots of untrusted clients and one of
> > them broadcasts data faster than all receivers can process it, where
> > does it go?
> >
> > At least with a userspace solution, it's clear what the OOM killer
> > should kill when this happens.  Unless it's PID 1.  Sigh
> 
> It may be useful to do the buffering (and general interception
> of any message that cannot be delivered) in a userspace program.
> 
> Not only to get the buffers out of the kernel and into swappable
> memory, but also so people could re-use the same infrastructure
> for things like cluster communication (or communication between
> different containers) - the userspace daemons could take care of
> routing messages to and from the outside.
> 
> They could also be useful to keep some of the policy stuff
> outside of the kernel, if only to ensure that the kernel side
> policy is not set in stone, and people can do things differently
> in the future if they want to.
> 
kdbus connections have memory pools, please check  kdbus.pool(7). The
pool has its own quota accounting to prevent bad scenarios, and the
memory is attributed to the connection.

Messages that can't be delivered are not stored in the pool, but senders
will get an appropriate error code. For further details on how this
works, please see kdbus.message(7). If you are aware of any corner-cases
we overlooked, please let us know.

Regarding the policy, the implementaion is hardly more complex than
traditional UNIX file permissions. Bus names may have multiple
permissions assined, each of which consist of a bit-mask to denote OWN,
TALK and SEE flags which are applied to UIDs, GIDs or "world". This
policy has to be enforced by the kernel, therfore the information it
acts upon also needs to be stored there. For further details, please see
kdbus.policy(7).

The concept of a name policy originates from dbus1 [1], however we
simplified it substantially, removing features which we believe rather
belong into userspace.

[1] http://dbus.freedesktop.org/doc/dbus-daemon.1.html


-- 
Djalal Harouni
http://opendz.org
--
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/