[RFC] Wayland Security Modules

Tue May 20 08:57:51 UTC 2025

On Mon, 19 May 2025 15:48:04 +0000
"Sloane, Brandon" <bsloane at owlcyberdefense.com> wrote:

> Hello,
> 
> I've spent the past few months prototyping a security modules system
> for Wayland. Our specific motivation for this is to support SELinux
> integration to meet some rather unique security requirements.
> However, what we are proposing here is a rather general purpose
> security module system that provides high level hooks modules can
> then implement. Potential usecases for this system are:
> 
> * Creating SELinux permissions for Wayland actions.
> * Integrating with non-SELinux Linux Security Modules
> (AppArmor/SMACK/etc).
> * Integrating with PolicyKit.
> * Disabling privileged protocols that a specific compositor
> implements.
> * Restricting privileged protocols to trusted clients.
> * Creating backends for wp_security_context_manager.

Hi,

from this and the readme I understand that the goal is to remove
security policies from compositors and place them outside of
compositors and DE projects, where they can be shared by many desktop
and other environments. Is that right?

What is the reason for this goal?

To unify policy configuration over all environments?

To enforce policy where the compositor does not do so itself?

> Our current proof of concept is here:
> https://gitlab.freedesktop.org/bsloane1650/wayland. Some more
> in-depth technical discussion is available in the doc/WSM.md file in
> that repository.
> 
> We also have some modules in development here:
> https://gitlab.freedesktop.org/bsloane1650/wayland-security-modules
> * Logger - a basic proof of concept that demonstrates instantiating a
> module and logging every access.
> * Allow-list - A basic proof of concept that demonstrates globally
> restricting what interfaces can be used.
> * SELinux - A more complex module that defers all access decisions to
> the system's SELinux policy (under active development)
> 
> The overall design is to add hooks at key points in libwayland:
> * Creation and destruction of core libwayland objects: wl_client,
> wl_display, wl_global, wl_resource
> * Prior to sending an event to the client
> * Prior to invoking the request handler after receiving a request
> from a client.
> * Prior to publishing a global object
> * Prior to binding a global object.

What about all the other Wayland protocol implementations that do not
use libwayland? Or those that bundle a libwayland without the hooks?

> A security module is represented by a "struct wsm" object, which has
> void* for modules to use, and a function pointer for each hook.
> Compositors can instantiate these structs however they like and pass
> them into a new wl_display_create_with_wsms method. The existing
> wl_display_create method is modified to dynamically load shared
> object files based on the new WAYLAND_SECURITY_MODULES environmental
> variable. These shared objects are expected to export a wl_wsm_init
> symbol that instantiates a wsm structure.

What's the failure mode of losing the environment variable by accident,
e.g. by a software update? Any security limitations just won't be there
and without notice? Isn't that too fragile and invisible?

> We have had success running this by linking unmodified compositors
> (mostly Weston) against an updated libwayland. Depending on what
> accesses the module blocks, existing compositors work without even
> needing a recompile. However, to be useful, we have found a couple of
> areas that additional compositor integration is needed. Mostly this
> has been shifting from wl_resourc_create to
> wl_resource_create_with_related in a few key places (such as creating
> a wl_data_offer) to allow the security modules to associated
> resources that are shared between clients. 

To me this sounds like aiming for unmodified compositors just won't
work. Would it not be better to aim for explicit integration?

Or, if unmodified compositors is an explicit design goal, make the
security layer a Wayland proxy? An independent man-in-the-middle
process.

> We have also found a need to modify compositors to deal with denials
> associated with new_id type requests. We think we have a workable
> solution implemented in libwsm_compositor that compositors can
> incorporate with a few library calls; but I still consider this the
> most questionable part of the project. This issue is discussed rather
> in much more detail in doc/WSM.md. Any input on this would be greatly
> appreciated.

You cannot "deny" any request at will, not even those without new_id
arguments. The protocol specification defines the behaviour of each
request, and a security module cannot decide against the spec. It would
break the protocol, cause mismatching state between the compositor and
the client, likely lead to hard-to-debug failure modes if it does not
outright cause a protocol error soon after, disconnecting the client.
Some requests are specified so that the compositor can decide to
refuse, but those are very rare. In general, it makes no sense to be
able to gate each and every request. No message can ever be ignored at
will and expect the application to continue working fine.

You also cannot really retrofit asynchronous access checks (that may
take more than, say, 100 ms) to interfaces or requests that were not
designed with that in mind. Wayland protocol stream follows a strict
execute-in-order model, so you would have to freeze the whole client
connection until an access decision is available. This would make the
application appear frozen, and the application might get disconnected
due to being unresponsive (even though it would be the compositor's
fault) or due to overflowing socket buffers (less of a problem
nowadays I guess).

Instead, developers try to account for the security requirements at the
protocol (extension) design. In the simplest form, the interface
offered through wl_registry either exists if granted, or not. When
finer grained control is necessary, the possibility to refuse and
revoke is built into the interface specification. Also the need for
asynchronous access checks is considered, allowing the application and
the compositor to continue their otherwise normal operations until the
access decision arrives.

If there are security design issues with Wayland protocol interfaces, I
would hope they get fixed by revising the protocol.

I am most sceptical about the hooking libwayland part of the proposal.
OTOH, offering compositors an API they can query in order to determine
access might be a good idea. It might need to be decoupled from literal
protocol interfaces, because there can be many different interfaces,
not all upstream wayland-protocols or even Wayland at all, for
applications to do things.

Thanks,
pq

> We have also experimented with per-surface screenshot restrictions in
> Weston, which needs to be implemented almost entirely in the
> compositor itself.
> 
> We probably should have gone public with this far earlier in the
> design process. However, despite the late stage we find ourselves in,
> we are open to significant revisions based on community feedback.
> 
> Thanks,
> Brandon
>  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20250520/974dc581/attachment-0001.sig>