Hello,

Just a quick question...dbus was patched to support SE Linux. I see no
mention of SE Linux support below. Does it replicate the same SE Linux
support?

Thanks,
-Steve

On Tue, 13 Mar 2018 17:32:20 +0100
Jan Kurik <jku...@redhat.com> wrote:

> = Proposed System Wide Change: Make dbus-broker the default DBus
> implementation =
> https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementation
> 
> 
> Owner(s):
>   * David Herrmann <dh dot herrmann at gmail dot com>
>   * Tom Gundersen <teg at jklm dot no>
> 
> 
> Enable dbus-broker.service to use dbus-broker as system and session
> message bus backend.
> 
> 
> == Detailed description ==
> The dbus-broker project is an implementation of a message bus as
> defined by the D-Bus specification. Its aim is to provide high
> performance and reliability, while keeping compatibility to the D-Bus
> reference implementation. It is exclusively written for linux systems,
> and makes use of many modern features provided by recent linux kernel
> releases.
> The main focus points of dbus-broker are reliability, scalability and
> security. The dbus-broker project tries to improve on these points
> over dbus-daemon, and thus provide a better alternative. And in-depth
> analysis can be found in the initial announcement of dbus-broker. An
> excerpt:
> 
> * Accounting: dbus-broker maintains per-user accounting, including
> inter-user quotas. This guarantees that no single user can cause
> irregularly high memory consumption in the daemon. Unlike dbus-broker,
> dbus-daemon accounts memory in a multi-tier system, based on plain
> resource counters on users, connections, and other resources. The
> multi-tier system suffers from resource-chaining-exhaustion, where
> clients effectively circumvent the accounting by creating multiple
> connections/objects, which themselves grant them each a new set of
> quotas. The single-tier accounting scheme of dbus-broker avoids this,
> while at the same time adding inter-user quotas to prevent misuse even
> across clients.
> 
> * Reliability: While D-Bus is used on reliable transports, dbus-daemon
> might still silently drop messages and given circumstances. This is
> the only possible solution dbus-daemon has, given several of its
> runtime guarantees. The dbus-broker project changed the architecture
> of the bus daemon to a degree, that it can provide many guarantees,
> including that no message will be silently, or unexpectedly, dropped.
> 
> * Scalability: The message bus broker is a crucial infrastructure on
> modern linux system, which is a hot-path for almost all IPC going on.
> Hence, the broker should perform fast and be scalable to its users.
> dbus-daemon has several **global** data-structures that affect the
> overall scalability of independent message transactions. dbus-broker
> does not employ any global data-structures (unless required by the
> spec), as such any message transaction is only affected by the data
> provided by the involved peers. Moreover, even for spec-defined global
> behavior, dbus-broker avoids global data-structures, unless clients
> actually make use of these obscure features. In several other cases,
> dbus-daemon scales O(n) time looking up message targets and related
> data. dbus-broker runs all these in O(log(n)) time.
> 
> * Linux-specific: The dbus-broker project was explicitly designed for
> linux system, making use of many linux-specific APIs and behavior.
> This allows mitigation of several possible DoS attacks.
> 
> 
> == Scope ==
> * Proposal owners:
> ** Fix regressions.
> ** Enable dbus-broker.service in system and user-global context of
> systemd (via systemd presets).
> ** Pull in dbus-broker package from dbus package.
> 
> * Other developers:
> ** Watch for regressions
> 
> * Release engineering: #7262 https://pagure.io/releng/issues/7262
> 
> * List of deliverables:
> N/A
> 
> * Policies and guidelines:
> No changes needed.
> 
> * Trademark approval:
> No changes needed.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to