Add Access Control to Container sockets

[swick]

The Container1 interface proposed in #34 makes it possible to create new sockets which uniquely identify a container app instance. The only difference to the main socket is that connections from it are authenticated with a (sandbox engine, app id, app instance) triple which can be queried by services.

This is enough to get rid of a bunch of code in xdg-desktop-portal which tries to collect this authentication manually for flatpak and snap.

There are two other problems that can be solved by extending this Container1 interface:

Static access policy

Flatpak applications currently rely on xdg-dbus-proxy to restrict D-Bus access in addition to the usual D-Bus access control. By default almost no access is allowed and rules are added to broaden the access. Details are documented here https://github.com/flatpak/xdg-dbus-proxy/blob/8d87ac1664b42d1e73f370e4dd84e9c13d5e6108/flatpak-proxy.c#L49. This static access policy could be moved to the D-Bus broker itself to get rid of this proxy.

Client to Client communication

With the static access policy in place client to client communication becomes hard. Any app cannot by default talk to any other app because of the static access policy. If access to a bus name is specified in the flatpak manifest of an app, flatpak will create a rule to allow the access. Applications like firefox have addons which might want to talk to a particular bus name. It's impossible to enumerate all the bus names in the firefox flatpak manifest.

We need a better way to let flatpak apps talk to other apps.

Just giving access to all bus names owned by a flatpak app isn't a good idea: the flatpak app might not be aware that it's a flatpak app and that potentially malicious flatpak apps might talk to it. For example, if a password manager exposes a service to read the passwords and we expose this bus name to all flatpak applications, we've given all applications all the passwords.

We can only expose bus names when the application understands that potentially malicious actors are accessing it. For example, if the password manager exposes a service to all flatpak apps, it should first ask the user to authorize access by the applications which wants to use the service.

We need a mechanism for applications to opt-into exposing their bus name to all other, potentially malicious, applications.

One solution would be an interface for an app to own a bus name where a flag can be provided so that potentially malicious actors can connect to it. The static access policy would be extended by a flag which would allow connections on this socket to talk with bus names for which the previously mentioned flag was provided.

[WhyNotHugo]

dbus-broker exposes an API for the dbus controller to register the main listener socket:

https://github.com/bus1/dbus-broker/blob/83d0772624768bb9f4b0ce1010025fb268cf9789/docs/dbus-broker.rst?plain=1#L149-L158

This takes a policy argument, which, AFAIK, declare restrictions as to which buses can be taken and similar rules. Perhaps it makes sense to use the same "policy" format for this API too?

OTOH, the syntax of this policy is not stable yet:

https://github.com/bus1/dbus-broker/blob/83d0772624768bb9f4b0ce1010025fb268cf9789/docs/dbus-broker.rst?plain=1#L175-L177

My main point is that both the policy argument in the dbus controller API and the "Access control" proposed in https://gitlab.freedesktop.org/dbus/dbus/-/issues/171#note_47997 serve the same purpose. It would make sense to try and use the same API style and types for both of them.

[swick]

@zeenix asked me to provide a bit more detail. Is this better to understand?

[zeenix]

@zeenix asked me to provide a bit more detail. Is this better to understand?

Yes, thanks!

We can only expose bus names when the application understands that potentially malicious actors are accessing it.

I'm not too sure of the need for that. Application should always assume that any clients accessing its services are malicious. That's security 101: Don't trust anyone by default. :)

For example, if the password manager exposes a service to all flatpak apps, it should first ask the user to authorize access by the applications which wants to use the service.

If the application needs to ask the user, it should be able to do so w/o any changes to how it registers its bus names. I think this is where policykit comes into the picture.

[swick]

I'm not too sure of the need for that. Application should always assume that any clients accessing its services are malicious. That's security 101: Don't trust anyone by default. :)

That's a nice idea but in practice, before flatpak became a thing apps just exposed whatever they wanted because it was assumed that all programs from one user are cooperative and not adversarial. Flatpak then filtered out all of those services which would otherwise be exposed, so applications had no reason to adjust to the adversarial environment.

Further, any session service operates under the assumption that it can only be reached by the same trusted base (i.e. not adversarial processes).

So, unfortunately this isn't the case and we absolutely need some opt-in for the cases where the service does understand that connections might come from a container (i.e. an adversarial process), is able to use the Container1 information and can inform the user about which app is trying to do what.

If the application needs to ask the user, it should be able to do so w/o any changes to how it registers its bus names. I think this is where policykit comes into the picture.

polkit is only useful for system services. A policy must be shipped with the service itself and to get access you usually have to authenticate yourself or authenticate another user.

We don't need any permissions from the system but need some way to tell the user what's going to happen.

For example, let's say I have a firefox extension which uses my password manager for storing and retrieving passwords. If there was polkit in the way, you would get some window which tells you that firefox wants to access a service of the password manager app and now asks you for a password. None of the information is really useful. Which passwords? Also my credit cards? The authentication is useless.

If the password manager is always exposed and uses the Container1 interface to figure out which app is connected to it, the app can now show you all the accounts for this specific login and ask you with which to login. It becomes obvious to the user what's going on and which information end up at firefox.