[Bug 42809] DBusTube access control is under-specified

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=42809

--- Comment #6 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2011-11-11 09:04:52 PST ---
(In reply to comment #5)
> What does this mean? Isn't "bound to local loopback only" what S_A_C_Localhost
> in general requires?

It requires either bound to local loopback, or accessible from off-machine but
using authentication (which for stream tubes can be as simple as getpeername(),
but I don't think libdbus lets you see the remote address) to lock it down to
only verifiably-local users. Any of these would be acceptable:

* listen on tcp:host=0.0.0.0 and reject ANONYMOUS
* listen on tcp:host=127.0.0.1 (MAY allow ANONYMOUS or not)
* listen on unix:tmpdir=/tmp (MAY allow ANONYMOUS or not)

For instance, a D-Bus server listening on tcp:host=0.0.0.0 that didn't allow
ANONYMOUS would be a perfectly fine implementation.

Perhaps I should just delete that sentence if it only confuses matters, or
perhaps we should just ban Localhost for D-Bus (it makes very little sense).

Perhaps this would also be an improvement:

  <p>This access control mechanism is intended as a fallback. Applications
    SHOULD use the Port or Credentials mechanisms if available, and
    SHOULD NOT fall back to this access control mechanism for private
    data on multi-user systems.</p>

  <tp:rationale>
    This access control mechanism does not require special OS features,
    so it can be provided as a fallback on any platform. However, it is
    vulnerable to interception by other users on multi-user systems,
    whereas Port and Credentials are secure even on a multi-user system.
  </tp:rationale>

I wonder whether CMs support access control for FT and stream tubes yet?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.