All of lore.kernel.org
 help / color / mirror / Atom feed
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/>

  parent reply	other threads:[~2016-02-03 11:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-10  6:54 [PATCH v2] unix: properly account for FDs passed over unix sockets Willy Tarreau
2016-01-10  6:58 ` 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
  -- strict thread matches above, loose matches on Subject: below --
2016-01-10  6:58 Willy Tarreau

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.