From: Simon McVittie <simon.mcvittie@collabora.co.uk>
To: David Herrmann <dh.herrmann@gmail.com>, Willy Tarreau <w@1wt.eu>
Cc: "David S. Miller" <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Eric Dumazet <edumazet@google.com>,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
socketpair@gmail.com,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Subject: Re: [PATCH v2] unix: properly account for FDs passed over unix sockets
Date: Wed, 3 Feb 2016 11:36:47 +0000 [thread overview]
Message-ID: <56B1E64F.3070206@collabora.co.uk> (raw)
In-Reply-To: <CANq1E4T0sqTTD4RsWXTUrFvsKvEsKsUiPbskWd=wAEVu83_Srg@mail.gmail.com>
On 02/02/16 17:34, David Herrmann wrote:
> Furthermore, with this patch in place, a process better not pass any
> file-descriptors to an untrusted process.
...
> Did anyone notify the dbus maintainers of this? They
> might wanna document this, if not already done (CC: smcv).
Sorry, I'm not clear from this message on what patterns I should be
documenting as bad, and what the effect of non-compliance would be.
dbus-daemon has a fd-passing feature, which uses AF_UNIX sockets'
existing ability to pass fds to let users of D-Bus attach fds to their
messages. The message is passed from the sending client to dbus-daemon,
then from dbus-daemon to the recipient:
AF_UNIX AF_UNIX
| |
sender -------> dbus-daemon -------> recipient
| |
This has been API since before I was a D-Bus maintainer, so I have no
influence over its existence; just like the kernel doesn't want to break
user-space, dbus-daemon doesn't want to break its users.
The system dbus-daemon (dbus-daemon --system) is a privilege boundary,
and accepts senders and recipients with differing privileges. Without
configuration, messages are denied by default. Recipients can open this
up (by installing system-wide configuration) to allow arbitrary
processes to send messages to them, so that they can carry out their own
discretionary access control. Since 2014, the system dbus-daemon accepts
up to 16 file descriptors per message by default.
There is also a session or user dbus-daemon (dbus-daemon --session) per
uid, but that isn't normally a privilege boundary, so any user trying to
carry out a denial of service there is only hurting themselves.
Am I right in saying that the advice I give to D-Bus users should be
something like this?
* system services should not send fds at all, unless they trust the
dbus-daemon
* system services should not send fds via D-Bus that will be delivered
to recipients that they do not trust
* sending fds to an untrusted recipient would enable that recipient to
carry out a denial-of-service attack (on what? the sender? the
dbus-daemon?)
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
next prev parent reply other threads:[~2016-02-03 11:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-10 6:54 Willy Tarreau
2016-01-11 5:05 ` David Miller
2016-02-02 17:34 ` David Herrmann
2016-02-02 18:29 ` Hannes Frederic Sowa
2016-02-02 19:29 ` Linus Torvalds
2016-02-02 20:32 ` Hannes Frederic Sowa
2016-02-02 20:39 ` Willy Tarreau
2016-02-02 21:55 ` Hannes Frederic Sowa
[not found] ` <CA+55aFzqdR80MKupCs+va8vtbTU67Jobax1QAbfWNktQCXFxpA@mail.gmail.com>
2016-02-03 0:57 ` Hannes Frederic Sowa
2016-02-03 1:12 ` Hannes Frederic Sowa
2016-02-02 20:44 ` Linus Torvalds
2016-02-02 20:49 ` Willy Tarreau
2016-02-02 20:53 ` Linus Torvalds
2016-02-02 20:58 ` Willy Tarreau
2016-02-02 20:56 ` Hannes Frederic Sowa
2016-02-03 12:19 ` David Laight
2016-02-03 11:36 ` Simon McVittie [this message]
2016-02-03 11:56 ` Hannes Frederic Sowa
2016-02-03 11:56 ` David Herrmann
2016-02-03 12:49 ` Simon McVittie
2016-02-03 14:07 ` Hannes Frederic Sowa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56B1E64F.3070206@collabora.co.uk \
--to=simon.mcvittie@collabora.co.uk \
--cc=davem@davemloft.net \
--cc=dh.herrmann@gmail.com \
--cc=edumazet@google.com \
--cc=hannes@stressinduktion.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=socketpair@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®