From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755205AbcBCL43 (ORCPT ); Wed, 3 Feb 2016 06:56:29 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:39666 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752134AbcBCL41 (ORCPT ); Wed, 3 Feb 2016 06:56:27 -0500 X-Sasl-enc: HEoGIGgjp/JbUTP55ykht+0qEBZ40wdf8x0MznHuTL/Q 1454500586 Subject: Re: [PATCH v2] unix: properly account for FDs passed over unix sockets To: Simon McVittie , David Herrmann , Willy Tarreau References: <201601100657.u0A6vk1B025554@mail.home.local> <56B1E64F.3070206@collabora.co.uk> Cc: "David S. Miller" , netdev , linux-kernel , Linus Torvalds , Eric Dumazet , socketpair@gmail.com, Tetsuo Handa From: Hannes Frederic Sowa Message-ID: <56B1EAE6.5010209@stressinduktion.org> Date: Wed, 3 Feb 2016 12:56:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56B1E64F.3070206@collabora.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03.02.2016 12:36, Simon McVittie wrote: > 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?) > The described behavior was simply a bug in the referenced patch. I already posted a follow-up to change this behavior so that only the current sending process is credited with the number of fds in flight: Other processes (in this case the original opener of the file) isn't credited anymore if it does not send the fd itself. That said, I don't think you need to change anything or give different advice because of this thread. Thanks, Hannes