Allow exposing select priviledged protocols to security-contexts

Use case

wp_security_context_manager_v1 allows creating a new socket for unprivileged clients.

In some situations, I would like to grant one such client access to a single privileged global. E.g.: I want to allow a client to use the screencopy global, but not layer-shell (or viceversa).

Proposed solution

Implement a protocol which exposes a new global: unveil_manager_v1. This global has two methods:

• manage_context. Takes as argument a new_id and creates a new unveil_context.
• destroy

An unveil_context implements the following methods:

• set_sandbox_engine. May only be called before unveil_global.
• set_app_id. May only be called before unveil_global.
• set_instance_id. May only be called before unveil_global.
• unveil_global. Takes as argument global_id: int: the id of a global object that is to be exposed to the sandboxed client. This is the id of the global object as seen by the client sending this request.
• destroy.

Once unveil_global is called, the compositor shall expose the specified global to sandboxed clients matching the sandbox_engine, app_id and instance_id. This is done by the compositor simply emitting a wl_registry::global event for clients under matching security contexts.

This shall be a privileged protocol, since it can grant clients in a secure context access to (individual) privileged protocols.

If set_instance_id is never called, then all instances matching the sandbox_engine and app_id will be granted access. It is unclear what the appropriate behaviour would be to never calling set_app_id; tentatively, it should be a protocol error.

See also

• !68 (merged)

My intent here is to open discussion on the topic and gather feedback.

Some relevant discussion in weston#206 (comment 183479)

wp_security_context_manager_v1 provides authentication. What the compositor does with that authentication is up to the compositor. It is absolutely possible to expose "privileged" protocols to clients that use wp_security_context_manager_v1.

It is possible. What is missing is an interface for a sandbox engine to communicate with a compositor and say "let client X access global Y". This is what I am trying to address.

As Sebastian says, this is already possible at the compositor level.

In my implementation, every client has a set of capabilities that govern which globals the client can access.

When a security context is created, the set of capabilities for that socket is set based on the app ID. The user can configure this mapping. (This part is not yet implemented.)

What would be useful is doing this in the security context itself. For example, the app could specify in its manifest that it needs access to a global shortcuts protocol. The user could the grant or deny this during installation and flatpak would take care of the rest.

I don't know why it would have to be a separate protocol nor why it would have to be privileged.

I don't know why it would have to be a separate protocol

I guess that it could be part of the security-context protocol, if that is a better fit. They are related functionalities, but different, so I don't see the necessity of blending them into a single protocol.

nor why it would have to be privileged.

This protocol allows a privileged client to grant access to privileged functionality. You generally don't want sandboxed clients to use this protocol.

When a security context is created, the set of capabilities for that socket is set based on the app ID. The user can configure this mapping. (This part is not yet implemented.)

There is an intent for wp_security_context_manager_v1 to integrate the functionality that I'm describing here?

I can't say I am a fan of permissions having to be granted before an application starts (i.e.: defined statically). If I want to give an application permissions to a new privileged protocol, I'd need to kill it, start a new security-context, and then restart the client.

For example, the app could specify in its manifest that it needs access to a global shortcuts protocol. The user could the grant or deny this during installation and flatpak would take care of the rest.

If Alice installs a program on a host, then Bob cannot grant/deny permissions at installation time. I don't think that users can give consent for permissions at installation time if applications can be installed system-wide.

\>You generally don't want sandboxed clients to use this protocol.

The capabilities of a nested sandbox are, in my implementation, bound by the capabilities of the parent sandbox so that is not an issue. For that reason, security context itself is not privileged.

\>I can't say I am a fan of permissions having to be granted before an application starts (i.e.: defined statically).

Sounds like what you want is a portal that applications can use for access to globals. It might even be possible for that portel to not have a compositor side implementation and to be handled entirely withing flatpak. Which would then use the existing security context to add globals.

The capabilities of a nested sandbox are, in my implementation, bound by the capabilities of the parent sandbox so that is not an issue. For that reason, security context itself is not privileged.

You're quite right. In the case of this protocol, it follows the same idea, so it doesn't strictly need to be privileged.

Sounds like what you want is a portal that applications can use for access to globals. It might even be possible for that portel to not have a compositor side implementation and to be handled entirely withing flatpak. Which would then use the existing security context to add globals.

Nope, this is not at all what I'm looking for. I'm talking about communication between the compositor and a client, portals and Flatpak are not really in scope here.

If you wanted to implement this via a portal, the portal would then need a mechanism to tell the compositor "allow app_id=X to view global=Y". This protocol is the mechanism for a portal implementation to instruct the compositor to do so.

Nope, this is not at all what I'm looking for. I'm talking about communication between the compositor and a client, portals and Flatpak are not really in scope here.

Permission management is what flatpak does. Access to certain protocols is not much different from access to /home or /dev or dbus or wayland which are all managed via flatpak. A priori I would not assume that compositors have a mechanism for showing permission request dialogs, persisting permissions, revoking permissions. If an application wants access to a protocol, you'd probably also have the application declare this ahead of time so that the user can see it before installing the application.

How this would work for applications running outside of flatpak I do not know.

I don't disagree with anything that you've just said, I just don't see how the relationship between your statements and what we're discussing here.

A priori I would not assume that compositors have a mechanism for showing permission request dialogs, persisting permissions, revoking permissions.

Indeed, this is the case, and I don't think that it would be good design for a compositor to implement these features itself, given that they can perfectly well be implemented by an dedicated client.

If an application wants access to a protocol, you'd probably also have the application declare this ahead of time so that the user can see it before installing the application.

I dislike this model, and is what I'm trying to avoid. I don't want a "all permissions must be declared ahead of time" model; I want the ability to grant access to a global to an existing client.

This model also completely ignores what I said before: If Alice installs a program on a host, then Bob cannot grant/deny permissions at installation time. If Alice refuses to grant the application permissions when she installs them, how would this affect Bob when he runs them on his own session?

How this would work for applications running outside of flatpak I do not know.

I really don't understand what you mean here. How if Flatpak related? Flatpak has no mechanism to expose a global to a single sandboxed client. To do so, it would need a mechanism to tell the compositor "allow client X to see global Y". This is what my proposal aims to do.

You really should just look at flatpak and portals instead of arguing here without understanding the problem space and making everything a wayland problem. The portal frontend would set permissions into the permission store, the compositor would query the store when a client connects and listen for Changed signals and then expose protocols accordingly.

Your suggestion here is that all compositors integrate into Flatpak's portals. I really don't think that's a sensible mechanism. This would require that all compositors implement the D-Bus protocol themselves, which sounds like a huge explosion in complexity. That side, it's not at all scalable to other sandbox mechanism (which won't use Flatpak's portals).

A simpler design is to have a dedicated client query and listen to the permission store via D-Bus, and relay the permissions granted to the compositor via a standardised wayland protocol. I don't see any valid reason to use D-Bus, HTTP, or any other protocol for this single functionality; both the client and server already have a common transport protocol and even a connection established.

Flatpak has no mechanism to expose a global to a single sandboxed client. To do so, it would need a mechanism to tell the compositor "allow client X to see global Y". This is what my proposal aims to do.

Not to a client but to an entire socket via the security context.

It's not a flatpak thing, it's a portal thing. It works with flatpak, snap, and anything else that integrates with portals (and we're currently making that much easier).

If you your entire argument is "i don't like portals", then that's fine, but at least be explicit and honest about it.

You won't be able to convince GNOME people that using yet another mechanism that someone came up with because they didn't like portals is a good idea.

Let's assume that I'm using portals to store permission granted to each application.

When I grant a program permission to access ext-layer-shell via the portal, I need to notify the compositor of this change so that it exposes the global via that program's socket.

To do this, I'd write a small program that queries/listens to the permissions portal and then talks to the compositor and tells it grant socket sandbox_engine=X, app_id=Y access to global=Z. The compositor needs an interface for this. This interface is what this discussion is about.

Whether I like or dislike portals is besides the point, because use-cases that want to support using portals will need this interface this as much as use cases that don't use portals.

I hope this example helps clarify things a bit.

To do this, I'd write a small program that queries/listens to the permissions portal and then talks to the compositor and tells it grant socket sandbox_engine=X, app_id=Y access to global=Z

This already assumes a certain implementation that isn't the most obvious one because you don't want to use dbus in your compositor.

This already assumes a certain implementation that isn't the most obvious one because you don't want to use dbus in your compositor.

On the other side, this assumes that a compositor has to use dbus to implement a sandbox. FYI, one of the most popular Wayland compositors, sway, doesn't support dbus and will probably never support dbus.

And the same argument also applies to security-context-v1: we can use dbus for it so why bother with wayland-protocols? No, Wayland needs it, but dbus is not a part of Wayland.

Others limiting themselves from using the standard desktop IPC mechanism out of zealotry isn't my issue.

And the same argument also applies to security-context-v1

It doesn't.

And the same argument also applies to security-context-v1

It doesn't.

Could you please explain more?

You can give me thumbs down as much as you want, but if you don't understand how the security context works, you shouldn't be in this thread.

The point here is that a generic "enable this protocol" thing isn't a good idea. Sandboxed clients already have portals to make their intent known and if that requires exposing a wayland protocol it can already be done.

The point here is that a generic "enable this protocol" thing isn't a good idea.

If you're going to say "This is a bad idea", please say "This is not a good idea because..." and provide some justification. There's really on way for me to reply if you're not providing the arguments to your conclusion.

Sandboxed clients already have portals to make their intent known and if that requires exposing a wayland protocol it can already be done

Can you please explain how it can be done right now? E.g.: how can a portal tell the compositor expose ext_session_lock_manager_v1 to a specific client?

This is the second claim that I see that this is already possible, but I don't see any existing mechanism to enable this.

mutter provides portal implementations. It's a bit crazy to me that I have to justify that you can use dbus and are not forced to only use wayland for all IPC.

The point here is that a generic "enable this protocol" thing isn't a good idea.

If you're going to say "This is a bad idea", please say "This is not a good idea because..." and provide some justification. There's really on way for me to reply if you're not providing the arguments to your conclusion.

Sandboxed clients already have portals to make their intent known and if that requires exposing a wayland protocol it can already be done

Can you please explain how it can be done right now? E.g.: how can a portal tell the compositor expose ext_session_lock_manager_v1 to a specific client?

locked the discussion in this issue

This discussion is not productive and is derailing, locking for a few days to leave everybody time to cool down.

Re-opening now. Please remain civil and avoid ad hominem replies. I would suggest to not use the thumbs-down reaction, instead preferring to explain why you disagree in a comment. Also, I don't believe that rehashing the D-Bus vs. Wayland debate is especially productive (everybody has their own opinion on the matter and it's completely fine to take different approaches).

unlocked the discussion in this issue

changed the description

This was short-sighted of me, but instead of the set_sandbox_engine, set_app_id and set_instance_id requests, this could simply take a wp_security_context_v1 object instead.

This subtle change mean that the compositor doesn't need to keep global state. Protocols can be unveiled either before starting the sandboxed clients, or during their runtime.

could this be a new minor-v2 request in wp_security_context_v1? i think it would make sense, but either way, that or taking the context as the argument for an unveil object sounds good.

allowing the sandbox to permit specific globals without the compositor needing to be aware of any given app_id or out-of-band sandbox engine metadata is a good idea for simplicity and extensibility imo

could this be a new minor-v2 request in wp_security_context_v1?

I think so. My initial train of thought was that compositors might want to implement wp_security_context_v1 without this feature. I no longer see the point in that, and it's likely unnecessary flexibility.

i think it would make sense, but either way, that or taking the context as the argument for an unveil object sounds good.

Yup, I agree entirely. This simply didn't occur to me originally, but it's the obvious approach.