[RFC] Wayland Security Modules

[Pekka Paalanen]

On Thu, 22 May 2025 21:02:48 +0000
"Sloane, Brandon" <bsloane at owlcyberdefense.com> wrote:

> > Could you explain more of your actual use cases? Maybe people would
> > have better ideas how to solve them.  
> 
> We are focused on cross domain and multi-level systems built using
> SELinux as a core part of their security architecture. For instance,
> we might have a workstation that is connected to sensitive networks A
> and B as well as the open internet. The security policy might dictate
> that there can be no data transfer between the internet and the other
> networks; and that data transfer between A and B is allowed only
> through trusted applications. The details of this policy are
> specified using SELinux.

Hi,

thank you for the in length explanation. I think that nicely
establishes the context for this discussion. I'm afraid I need to
withdraw from this discussion because I am personally far out of my
depth. I did leave some notes below.

> For a bit of context on how SELinux works, every process, file, and
> other resource type is given a context consisting of (among other
> information): a domain (firefox_t, apache_t, etc.), a sensitivity
> level (s0, s1, ... sn), and 0 or more categories (c0 ... c1024).
> Multi-level processes may be given a low and high context to
> represent their access to everything between the two. In the above
> example, we might say that processes that talk to the internet run
> with a level of "s0", those with access to network A run with
> "s1:c0", those with access to network B run with "s1:c1", and a
> trusted multilevel process might run with "s0 - s1:c0.c1". If a file
> comes from network A, it would have a context containing "s1:c0", and
> so only be accessable to processes containing category c0 and a
> sensitivity of s1 or greater.
> 
> Thus far, there have been two potential dataflows within Wayland we
> have looked into. The first is related to clipboard access and
> drag-and-drop. If a copy is performed in an application connected to
> network A, we want the compositor to block any paste action for an
> application connected to network B. From the SElinux perspective,
> this would denial would be based on the fact that the copy has the c0
> label, which is not present in the recieving client.
> 
> This gets more complicated with the introduction of a trusted
> application with access to both networks A and B. Such an application
> would run with level "s1:c0.c1". Naivly, this would allow it to
> perform a paste operation from both c0 and c1 clients, but perform a
> copy operation to neither. We would like for this application to be
> able to copy data to either c0 or c1 applications while still
> restricting c0 data to c0 applications and c1 data to c1
> applications. Since this is a trusted application, we trust it to
> tell us what data it provided belongs to c0 and what data belongs to
> c1. 
> 
> The way I anticipate this working is that the trusted client
> constructs a wl_data_source, then labels that wl_data_source object
> with either the c0 or c1 category as appropriate. This can be
> accomplished by the SELinux WSM its own global object which provides
> requests like "wsm_selinux::setcon(res: object, ctx: string)" and
> "wsm_selinux::setcreatecon(interface: string, ctx: string)", which
> will either update the context of an existing object, or set the
> context for any subsequent object of the given interface. Obviously,
> the ability of a client to do this would itself be subject to an
> access control check.
> 
> As simmilar issue arrises with screen captures. A c0 application
> should not be able to see the pixels of a c1 application and
> vice-versa. However a trusted c0.c1 application should be able to
> identify specific regions as belonging to c0 and others as belonging
> to c1. The complication with screen captures is that a single capture
> may implicate multiple surfaces. We anticipate this causing a
> seperate access check for every surface. The behaviour for cases
> where these access checks return different results is up to the
> compositor. Ideally, the compositor would redact only the nessasary
> surfaces, but that may prove depending on how compositors implement
> screen capturing.

Identifying screenshot regions belonging to different security contexts
is information that just does not exist at the Wayland protocol level
and cannot be extracted even by complete state tracking in WSM, because
window positions are never communicated.

Per-surface screenshooting access checks would need to be implemented
explicitly in compositors.

> 
> Those are the only cases we have looked at closely, but we anticipate
> this type of concern in any protocol extension that facilitates
> cross-client communication. For instance an
> ext_foreign_toplevel_handle_v1 should share a context with the
> corresponding xdg_toplevel in the foreign client, where a single
> client might have multiple top level surfaces with different contexts.
> 
> The other issue is that we cannot fully anticipate the security needs
> of every future project. By creating an access check for everything
> (and writing the SELinux WSM such that all libwayland access checks
> are answered based on the system policy), we allow system integrators
> to create security policies to meet their specific needs.
> 
> A related issue is that it is simply not feasible to expect
> compositor authors to consider every potential security implicication
> for every system of every protocol they implement. Nor is it feasible
> to expect system integrators to audit every compositor release for
> new features and create new access checks for every potential
> concern. 
> 
> > I'm curious about when does your WSM design actually work.  
> 
> For copy-and-paste, drag-and-drop, and screenshots it pretty much
> just works. We do require the compositor to advice us on the
> relationship between wl_data_offer and wl_data_sources, and be able
> to handle a NULL coming out of wl_resource_create. However, from the
> protocol perspective, just not creating the wl_data_offer and not
> sending the event works fine. Screenshots run into some composting
> issues (since, the notion of a partial screenshot does not seem to be
> well supported), but nothing that is protocol related.

Those compositors that choose to support sensitive content Wayland
extensions (I forget if we have any atm.) would know how to censor
surfaces from screenshots.

> Those are the only two situations we have gotten to testing thus far.
> However, looking through the protocols, there are a lot of cases
> where blocking a request/event is safe. It is up to WSM developers
> (and, where relevent system policy developers) to make sensible
> decisions on what to block. If they do not do so, the resulting
> breakage is on them.
> 
> As far as I can tell, the only Wayland protocol level breakage that
> occurs with our design is blocking new_id. From what I can tell,

I feel this is very optimistic. Maybe I'm wrong.

> there are not many circumstances where doing so is actually
> important, as most goals could be achieved by allowing the creation
> and blocking the accesses the new object would give. Again, the
> specific here are policy decisions that can be defered to the system
> integrator. Logical breakage for specific protocols with some poorly
> placed denials remains possible, and can cause varying levels of
> problems. But that would again be the responsibility of WSM
> developers and policy developers to resolve.

In other words, in the effort to not put the burden of implementing
security checks on the people who understand Wayland protocols, you
choose to put the burden of understanding all Wayland protocols and
their implementations on the WSM policy developers. When Wayland
protocol development continues, the policy developers must stay on top
of it and plug any openings that may be added.

I suppose this is a good trade-off for Wayland, compositor, and
application developers.


Thanks,
pq

> > You later wrote that e.g. with clipboard access, the security
> > policy would need to know not just the source and destination
> > clients, but also the destination wl_surface. Maybe you want to
> > have even more context. But can you really get this context
> > reliably from libwayland-server hooks?  
> 
> I might have not been fully clear here. For clipboard access, the
> important thing is the source wl_data_source; this does require
> explicit compositor support to provide. The wl_surface was relevent
> for screenshots.
> 
> -- 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/20250526/bc412e1e/attachment.sig>