Wayland security

[rusty-snake]

@fira959 in #5883 (comment):

Could someone explain the implications of not using this security-context to the casual reader coming across this issue please?

I used to be under the impression that X11 = bad for sandboxing because any process of the same user could access the x11 sockets and use it to read all other applications input. Is the same true for new sway implementations now, given the option for any normal client to use the screen capture feature of wayland? Does using any form of sandboxing on wayland/sway imply the same or similar issues as with X11?

[emersion]

Unsandboxed applications cannot be secured, because they can just echo backdoor >~/.bashrc. Thus, on Sway, unsandboxed applications have access to all privileged protocols.

Sandboxed applications (for sandbox engines using the security-context protocol) do not have access to privileged protocols.

[fira959]

Sandboxed applications (for sandbox engines using the security-context protocol) do not have access to privileged protocols.

Does that mean sandboxed applications that do not yet add changes to use the new security-context (like firejail) are just as vulnerable as unsandboxed applications?
It sounds like the introduction of these privileged protocols introduced a weakness in wayland that is fatal to sandboxed applications and required additional isolation (security-context). What are the exact implications of not having security-context implemented in firejail?

[emersion]

Does that mean sandboxed applications that do not yet add changes to use the new security-context (like firejail) are just as vulnerable as unsandboxed applications?

In terms of privileged Wayland protocols, that is correct. It's still possible for users to wrap firejail with a tool which creates a security-context (there are a few of these).

We had to balance usability and security here. We want users to be able to take a screenshot with a simple CLI tool, or manage the configuration of their outputs.

Some other compositors have a different design, e.g. they require connecting to a different Wayland socket for privileged operations. But there's no standard way to discover which socket that is, and implementing more fine-grained rules is cumbersome (requires setting up separate privileged sockets). At some point you end up with one Wayland socket per application, and this is exactly what security-context gives you (and as a standardized Wayland protocol).

What are the exact implications of not having security-context implemented in firejail?

Here's the list of protocols gated behind security-context: https://github.com/swaywm/sway/blob/e7c972b04a109c59dae1dd73da4d9bd7cbc6800c/sway/server.c#L91

(More fine-grained rules are still a TODO in Sway.)

[fira959]

Thanks for the explanation.

Is there an option in sway to simply set the default to unprivileged for all applications? Or perhaps even a global wayland setting?

[emersion]

Sway offers no such knob. It would break too many things (e.g. the status bar and background image wouldn't be able to run).