From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756935AbcBCLg5 (ORCPT ); Wed, 3 Feb 2016 06:36:57 -0500 Received: from bhuna.collabora.co.uk ([46.235.227.227]:53737 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755127AbcBCLgv (ORCPT ); Wed, 3 Feb 2016 06:36:51 -0500 Subject: Re: [PATCH v2] unix: properly account for FDs passed over unix sockets To: David Herrmann , Willy Tarreau References: <201601100657.u0A6vk1B025554@mail.home.local> Cc: "David S. Miller" , netdev , linux-kernel , Linus Torvalds , Eric Dumazet , Hannes Frederic Sowa , socketpair@gmail.com, Tetsuo Handa From: Simon McVittie X-Enigmail-Draft-Status: N1110 Organization: Collabora Ltd. Message-ID: <56B1E64F.3070206@collabora.co.uk> Date: Wed, 3 Feb 2016 11:36:47 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.