[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190711202015.GA24270@espresso.pseudorandom.co.uk>
Date: Thu, 11 Jul 2019 21:20:15 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: Privileged File Access from Desktop Applications
On Thu, 11 Jul 2019 at 11:47:10 -0400, Perry E. Metzger wrote:
> having to add file i/o subsystems inside of dbus(!) probably does
> add lots of threats
I think you might be misunderstanding the scope of D-Bus. D-Bus
is an IPC mechanism, normally using AF_UNIX sockets; dbus is the
reference implementation, including a message bus (broker) and a client
library. System services and their clients can use D-Bus to communicate
if they have been designed to do so, similar to the way they might use
ONC RPC (aka SunRPC), CORBA, ZeroMQ, SOAP-over-HTTP, any other
pre-existing IPC mechanism chosen by their designer, or their own
unique/ad-hoc IPC mechanism.
If someone writes a system service that provides file I/O over D-Bus,
that does not imply adding code to dbus, in the same way that in the ONC
RPC ecosystem (NFS etc.) adding a new RPC service didn't involve adding
code to the portmapper, and in CORBA adding a new RPC service didn't
involve adding code to the broker. The D-Bus protocol and the dbus
implementation just carry messages, with some security and functional
guarantees. Processing those messages (preferably securely, and making
appropriate use of the guarantees given by the IPC mechanism where they
are helpful) is a job for higher layers.
D-Bus is often used by system services as a reusable protocol over
AF_UNIX sockets. Unlike protocols designed for network use, the concept
of identity used in its authentication/authorization handshake is bound to
Unix uids (and it normally authenticates using Linux SO_PEERCRED or other
kernels' equivalents, so identity is guaranteed by the kernel). This is
good if uids are an important part of your security model (conversely, if
uids aren't the basis for your security model, then D-Bus is a poor fit).
The security of each system service that happens to use D-Bus should
be considered on its own merits, the same way that using HTTP does not
automatically make a higher-layer protocol more or less secure than it
would otherwise be. Some system services that communicate via D-Bus are
carefully designed with security in mind, while others are not (and I've
sent advisories in the past for some in the latter category).
smcv
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
