Bug 42809

(In reply to comment #0)
> I think the values for S_A_C that make sense for D-Bus tubes are:
> 
> * Localhost: any local user can connect to the CM. I'd re-interpret this as
>   "use dbus_connection_set_unix_user_function() and
>   dbus_connection_set_windows_user_function() to set a function that
>   allows everyone".

Agree.

> 
> * Credentials: for D-Bus I'd either re-interpret this as
>   "use the default D-Bus auth handshake as used for the session bus,
>   which only allows the same uid; omit the extra byte", or deprecate it
>   for D-Bus tubes (it's fine to use on stream tubes) and introduce a
>   new S_A_C_DBus_Same_User which is explicitly "use the normal D-Bus
>   mechanisms to determine that it's the same user".

I vote for the way of the reinterpretation. In hindsight, it'd probably have been better to have separate access control enums in StreamTube and DBusTube, but as they're shared (also with FT), I favor the way where there are the fewest values specific to DBus tubes. The Credentials notion isn't too far off from what S_A_C_DBus_Same_User would be, the difference mostly being that the dbus transport library implements the credential passing for you.

(In reply to comment #1)
> I vote for the way of the reinterpretation.

Looking at the DBusTube spec again, I think this is clearly what was intended. I'm currently doing some rather long-running thread-safety stress tests on GDBus, so I'll write a spec patch while I wait...

Created attachment 53406 [details] [review]
[1/2] Redefine Socket_Access_Control_Credentials on D-Bus  tubes to be useful

I think this is what was always intended, and it seems to be what Gabble
has always implemented.

Created attachment 53407 [details] [review]
[2/2] DBusTube: recommend Socket_Access_Control_Credentials

The two known Tubes implementations (Gabble and Salut) implement it
using libdbus, where it's actually easier to implement than anything
else. It'd be equally easy with GDBus, from what I can tell.

(In reply to comment #3)
> Created attachment 53406 [details] [review] [review]
> [1/2] Redefine Socket_Access_Control_Credentials on D-Bus  tubes to be useful
> 
> I think this is what was always intended, and it seems to be what Gabble
> has always implemented.

+ ... If the socket is only available to local users
+            (e.g. a Unix socket, an IPv4 socket bound to 127.0.0.1, or an
+            IPv6 socket bound to ::1), the <code>ANONYMOUS</code>
+            authentication mechanism MAY be enabled.</p>

What does this mean? Isn't "bound to local loopback only" what S_A_C_Localhost in general requires? So how could some other situation occur, and how would it affect the use of the ANONYMOUS D-Bus auth mechanism?

I think I must understand this bit of the documentation. Otherwise it's rather less likely that any of our users would understand it either :)

Otherwise, this patch looks like a perfectly good clarification.

(In reply to comment #4)
> Created attachment 53407 [details] [review] [review]
> [2/2] DBusTube: recommend Socket_Access_Control_Credentials
> 
> The two known Tubes implementations (Gabble and Salut) implement it
> using libdbus, where it's actually easier to implement than anything
> else. It'd be equally easy with GDBus, from what I can tell.

++

(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?

(In reply to comment #6)
> perhaps we should just ban Localhost for D-Bus (it makes very little sense).

Rather little, yes. But would it be required e.g. if you want to run the app you connect to tube in a sandbox with different UID from yourself (dropping even your own privileges)?

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

Gabble does support all of them for stream tubes fwiw.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/126.