lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 3 Feb 2016 12:56:39 +0100 From: David Herrmann <dh.herrmann@...il.com> To: Simon McVittie <simon.mcvittie@...labora.co.uk> Cc: Willy Tarreau <w@....eu>, "David S. Miller" <davem@...emloft.net>, netdev <netdev@...r.kernel.org>, linux-kernel <linux-kernel@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Eric Dumazet <edumazet@...gle.com>, Hannes Frederic Sowa <hannes@...essinduktion.org>, socketpair@...il.com, Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp> Subject: Re: [PATCH v2] unix: properly account for FDs passed over unix sockets Hi On Wed, Feb 3, 2016 at 12:36 PM, Simon McVittie <simon.mcvittie@...labora.co.uk> wrote: > 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?) With the revised patch from Hannes, this should no longer be needed. My original concern was only about accounting inflight-fds on the file-owner, rather than the sender. However, with Hannes' revised patch, a different DoS attack against dbus-daemon is possible. Imagine a peer that receives batches of FDs, but never dequeues them. They will be accounted on the inflight-limit of dbus-daemon, as such causing messages of independent peers to be rejected in case they carry FDs. Preferably, dbus-daemon would avoid queuing more than 16 FDs on a single destination (total). But that would require POLLOUT to be capped by the number of queued fds. A possible workaround is to add CAP_SYS_RESOURCE to dbus-daemon. Thanks David
Powered by blists - more mailing lists