Bug 103457

See Bug #100344, comments starting at 15, for some more thoughts on whether/when this might be desirable.

On Bug #100344, David Herrmann had some more ideas about this (see its comments 19 to 21).

At the moment we require connecting users to have the same uid as the creator of the container socket, so the difference is only theoretical anyway, and we don't *have* to solve this right now.

(In reply to David Herrmann on https://bugs.freedesktop.org/show_bug.cgi?id=100344#c21)
> (In reply to Simon McVittie on https://bugs.freedesktop.org/show_bug.cgi?id=100344#c20)
> > In that case Geoclue would be asking Alice "Allow Weather to see your
> > location? [y/n]", and the only security issue is one that she has inflicted
> > on herself, by delegating a socket to Bob that is pre-authenticated to act
> > as Alice (the fd acts like a capability - in the capability-based security
> > sense, not the CAP_SYS_ADMIN sense).
> 
> Right. I would expect the origin of the listener socket to determine the
> capabilities of anyone talking through it.

I'm not so sure that that follows. If you give someone else access to a connected IPC connection, it seems reasonable that they can do IPC as though they were the user who connected. If you give someone else access to a listening socket, and they connect to it themselves, that doesn't really feel the same to me - particularly since dbus-daemon already *has* a listening socket, and if you connect to that one, you don't get to pretend to be messagebus!

> This would mean this entire container infrastructure is just a fancy way to
> multiplex a single socket to the daemon. So semantically speaking, we could
> make this container infrastructure mirror xdg-proxy: Whenever someone
> connects through such a listener, they get the credentials of the
> listener-owner enforced, rather than capturing their credentials at
> connect-time.

That's an interesting way to think about it, but I would tend to think that the flatpak-dbus-proxy works like this because nothing else was implementable in a proxy, rather than because that's what its authors ideally wanted.

> If we went this route, we would probably have to omit the type and uid from
> GetConnectionCredentials(), because in this world-view they are no use (and
> potentially actively harmful) when not used in conjunction with the container
> instance initiator's identity, and putting the container instance initiator's
> identity in GetConnectionCredentials() seems easy to confuse with the actual
> connection's identity.

In the interests of kicking this can further down the road, I'm very tempted to remove o.fd.D.Containers1.Type and o.fd.D.Containers1.Name from GetConnectionCredentials(), leaving only o.fd.D.Containers1.Instance (the object path); and if there's demand for them, we can (solve the issue of who to believe, then) put them back in.

Created attachment 136300 [details] [review]
[1/2] containers test: Don't assert that GetConnectionCredentials has Type, Name

It isn't clear whether we want these in GetConnectionCredentials(),
because if we later open up different-uid access to the container
sockets, it raises questions of how strongly we can trust that
information.

Created attachment 136301 [details] [review]
[2/2] GetConnectionCredentials: Don't include Containers1 Type, Name

It isn't clear whether we want these in GetConnectionCredentials(),
because if we later open up different-uid access to the container
sockets, it raises questions of how strongly we can trust that
information.

The other thing I should do here in the short term is to add the container instance's initiator's credentials to GetInstanceInfo() and and GetConnectionInstance() (which will be an API break, but that's OK, this is still very much at the experimental stage and has never been in a release). Then anyone calling one of those functions will at least have all the tools to make their own decisions.

(In reply to David Herrmann in https://bugs.freedesktop.org/show_bug.cgi?id=100344#c19)
> At the same time, if Bob decides to
> access random resources, he must be aware that they might be maliciously put
> there.

It's a bit more complicated than this if the reason you're sandboxing apps is that you do not 100% trust them. The situation I was concerned about in https://bugs.freedesktop.org/show_bug.cgi?id=100344#c15 was: Bob has two apps, let's say GoodApp and MalwareApp. The malware wants to get sensitive data from a system bus service; Bob does not want this. Another user Alice, conspiring with the author of the malware, can create a system bus listening socket that claims to be GoodApp. If Bob's instance of MalwareApp is able to connect to that socket and send a request to the service, then the service will believe that the request to see the sensitive data came from GoodApp (admittedly running as Alice, so it's detectable, but still seems weird).

For the specific case of Geoclue and location (which is what I said on #100344), it doesn't really matter, because the sensitive data (geolocation) is the same for both Alice and Bob anyway; so if Alice is willing to leak that information to the malware author, Bob has already lost. But perhaps there are other system services that process data on behalf of specific users, so Alice would not be able to do the equivalent except by tricking Bob?

Again, until we let users connect to sockets they didn't create, this is purely theoretical (and my only concern right now is to avoid committing to an API that, later, will turn out to have been a mistake).

(In reply to Simon McVittie from comment #6)
> The other thing I should do here in the short term is to add the container
> instance's initiator's credentials to GetInstanceInfo() and and
> GetConnectionInstance() (which will be an API break, but that's OK, this is
> still very much at the experimental stage and has never been in a release).
> Then anyone calling one of those functions will at least have all the tools
> to make their own decisions.

Kicked out to Bug #104610.

Comment on attachment 136300 [details] [review]
[1/2] containers test: Don't assert that GetConnectionCredentials has Type, Name

Obsoleted by a commit on Bug #104610

Comment on attachment 136301 [details] [review]
[2/2] GetConnectionCredentials: Don't include Containers1 Type, Name

Obsoleted by a commit on Bug #104610

-- 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/dbus/dbus/issues/188.