wayland: new policy module #969

WavyEbuilder · 2025-07-10T20:32:54Z

A new type attribute wayland_compositor is introduced for shared rules for Wayland compositors. To support the security-context protocol[1], two new type attributes are introduced: wayland_client for regular Wayland clients, and wayland_client_sandboxed for sandboxed Wayland clients for use in applications run by sandbox engines such as Flatpak that support security-context[2].

As a fair amount of new policy modules can be expected to work with modern Wayland desktop sessions, a new policy layer has been created, session, to contain these new policy modules.

[1] https://wayland.app/protocols/security-context-v1
[2] flatpak/flatpak#4920

policy/modules/session/wayland.te

0xC0ncord · 2025-07-10T21:50:20Z

policy/modules/session/wayland.te

+# No need to distinguish between the shm of sandboxed and unsandboxed clients;
+# all clients should have their own shm type, this attribute is only to group them
+# and grant wayland_compositor access to them.
+attribute wayland_client_tmpfs_type;


Would it be appropriate to go ahead and add files_tmpfs_file() here?

Yea, seems reasonable, will do

Is this resolved? I don't see a change.

Forgot to reply, this interface doesn't appear to work on attributes?

No, unfortunately, it's a language limitation. You'd have to put it in the interface.

policy/modules/session/wayland.te

0xC0ncord · 2025-07-10T21:55:05Z

policy/modules/session/wayland.te

+xserver_use_user_fonts(wayland_compositor)
+
+xserver_read_xkb_libs(wayland_compositor)
+xserver_rw_mesa_shader_cache(wayland_compositor)


These xserver_() calls should go into an optional.

On the other hand I know it's perfectly possible to run a Wayland desktop without Xorg at all, so maybe this highlights a need to split some of these file types out of xserver in the future.

Maybe that's worth doing now (or possibly noting a dependency on the xserver module for now)? A compositor that doesn't have access to the mesa shader cache is pretty much useless...

Perhaps we should generalize the X fonts to simply user fonts, in userdomain or xdg? (suggestions please).

xdg sounds good to me, would you like a future PR for that?

aerusso · 2025-07-11T12:15:31Z

I've been building up a patchset that gets kde on wayland working with a slightly different set of primitives than this introduces. I haven't opened a PR for it partly because I hadn't yet figured out the best way to capture some of the primitives (which are captured here).

If this patch set is expected to be stable, I'll start re-basing my changes on this, and open a PR soon. Let me know! And, thanks for getting this started!

WavyEbuilder · 2025-07-12T22:51:54Z

Hey,

I've been building up a patchset that gets kde on wayland working with a slightly different set of primitives than this introduces. I haven't opened a PR for it partly because I hadn't yet figured out the best way to capture some of the primitives (which are captured here).

Nice!

If this patch set is expected to be stable, I'll start re-basing my changes on this, and open a PR soon.

One thing I'm solving (and the final concern I have at the moment) is the shared memory (tmpfs_t) of the compositors, so I'm going to make an attribute for that tonight or latest tomorrow. After that all the interfaces should remain stable, ofc I suspect we'll in the future be able to remove some modules from kwin and future compositor modules and consolidate them into the typeattribute more as we get more practical experience of the accesses shared by compositors, but the interfaces themselves should remain stable.

And, thanks for getting this started!

No worries! Glad it could be of use. :)

pebenito · 2025-07-22T13:19:51Z

One thing I'm solving (and the final concern I have at the moment) is the shared memory (tmpfs_t) of the compositors, so I'm going to make an attribute for that tonight or latest tomorrow.

@WavyEbuilder were you going to do further changes? I haven't started reviewing because of this.

WavyEbuilder · 2025-07-22T14:35:37Z

One thing I'm solving (and the final concern I have at the moment) is the shared memory (tmpfs_t) of the compositors, so I'm going to make an attribute for that tonight or latest tomorrow.

@WavyEbuilder were you going to do further changes? I haven't started reviewing because of this.

Sorry! I made a change but forgot to commit and push. Will do now.

policy/modules/session/metadata.xml

pebenito · 2025-07-22T18:13:09Z

policy/modules/session/wayland.if

+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>


This doesn't seem to fit wayland_compositor_tmpfs_type.

Should be resolved.

Perhaps I need to look more at wayland internals... is there a process to handle tmpfs stuff? The attribute naming seems like it should be a file type.

Okay so basically it's /dev/shm - Wayland clients have shared memory with the compositor that is written and read to. Take a look at https://wayland.app/protocols/wayland#wl_shm for associated interfaces. The compositor and the app have the tmpfs so basically imagine I have an app foo and a compositor bar, I'd have foo_t and foo_tmpfs_t, as well as bar_t and bar_tmpfs_t. They need to be able to rw each other's shared memory.

In that case, the doc is wrong (parameter name and summary), as the parameter is to be used as a file type, not a domain.

pebenito · 2025-07-22T18:13:46Z

policy/modules/session/wayland.if

+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+## 	</summary>
+## </param>


This doesn't seem to fit wayland_client_tmpfs_type.

Should be resolved.

Same question as above.

Should be answered above.

policy/modules/session/wayland.if

policy/modules/session/wayland.te

policy/modules/session/wayland.fc

A new type attribute wayland_compositor is introduced for shared rules for Wayland compositors. To support the security-context protocol[1], two new type attributes are introduced: wayland_client for regular Wayland clients, and wayland_client_sandboxed for sandboxed Wayland clients for use in applications run by sandbox engines such as Flatpak that support security-context[2]. As a fair amount of new policy modules can be expected to work with modern Wayland desktop sessions, a new policy layer has been created, session, to contain these new policy modules. [1] https://wayland.app/protocols/security-context-v1 [2] flatpak/flatpak#4920 Signed-off-by: Rahul Sandhu <[email protected]>

aerusso · 2025-07-28T05:43:03Z

I was hoping to get a more well-reasoned review for this prepared this weekend, but it will have to wait another week.

The long and short of it is that, while I've (again) got KDE running, this time using the primitives set out here, the situation is very messy. Handling things like the clipboard and the sundry other permissions wayland appears to, in practice has me with a block like this:

allow wayland_client wayland_compositor_tmpfs_type:file mmap_rw_inherited_file_perms;
allow wayland_client wayland_compositor:unix_stream_socket connectto;
allow wayland_client wayland_compositor:fd use;
allow wayland_client wayland_runtime_t:sock_file rw_sock_file_perms;
allow wayland_client wayland_client:fifo_file write;

allow wayland_compositor wayland_client_tmpfs_type:file mmap_rw_inherited_file_perms;
allow wayland_compositor wayland_client:fd use;
allow wayland_compositor wayland_client:fifo_file write;
allow wayland_compositor wayland_client_sandboxed:fd use;

The KDE module I have working is even worse. There seem to be no mechanisms to label memfd buffers beyond specific names, which for wayland are often very opaque, and many of which in are just very long random hexadecimal strings. I'm out of time for this for now, but I'll try to keep up with the conversation throughout the week.

WavyEbuilder · 2025-07-28T07:00:33Z

allow wayland_client wayland_compositor_tmpfs_type:file mmap_rw_inherited_file_perms;
allow wayland_client wayland_compositor:unix_stream_socket connectto;
allow wayland_client wayland_compositor:fd use;
allow wayland_client wayland_runtime_t:sock_file rw_sock_file_perms;
allow wayland_client wayland_client:fifo_file write;

allow wayland_compositor wayland_client_tmpfs_type:file mmap_rw_inherited_file_perms;
allow wayland_compositor wayland_client:fd use;
allow wayland_compositor wayland_client:fifo_file write;
allow wayland_compositor wayland_client_sandboxed:fd use;

These don't seem particularly egregious - what's up with that? I don't personally seeing anything wrong with just granting those.

WavyEbuilder · 2025-09-19T05:29:47Z

@aerusso @pebenito any updates?

aerusso · 2025-09-20T03:04:52Z

@WavyEbuilder I've cherry picked your commit, and combined it with some other work of mine to get waypipe, kde, Xwayland, and basically all my other wayland applications working.

I was waiting for this patch to finalize, and then I was going to rebase (and clean up) those patches, and then submit them. The KDE patches are pretty significant, so those would come second. There are core improvements (e.g., Xwayland) and other somewhat simpler things (waypipe) that would be good examples to help work out an interface for the new module before diving into all of KDE.

WavyEbuilder force-pushed the wayland-base branch from 1348d77 to ed79ed8 Compare July 10, 2025 20:37

0xC0ncord reviewed Jul 10, 2025

View reviewed changes

WavyEbuilder force-pushed the wayland-base branch from ed79ed8 to 669fd8c Compare July 10, 2025 22:12

WavyEbuilder force-pushed the wayland-base branch from 669fd8c to 56496e5 Compare July 22, 2025 14:42

pebenito requested changes Jul 22, 2025

View reviewed changes

WavyEbuilder force-pushed the wayland-base branch 2 times, most recently from 12ec763 to ea8e486 Compare July 22, 2025 20:22

WavyEbuilder requested a review from pebenito July 23, 2025 02:13

aerusso reviewed Jul 23, 2025

View reviewed changes

policy/modules/session/wayland.te Outdated Show resolved Hide resolved

policy/modules/session/wayland.fc Outdated Show resolved Hide resolved

WavyEbuilder force-pushed the wayland-base branch from ea8e486 to ea224c5 Compare July 24, 2025 14:16

wayland: new policy module #969

Are you sure you want to change the base?

wayland: new policy module #969

Uh oh!

Conversation

WavyEbuilder commented Jul 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WavyEbuilder Jul 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aerusso commented Jul 11, 2025

Uh oh!

WavyEbuilder commented Jul 12, 2025

Uh oh!

pebenito commented Jul 22, 2025

Uh oh!

WavyEbuilder commented Jul 22, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

aerusso commented Jul 28, 2025

Uh oh!

WavyEbuilder commented Jul 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

WavyEbuilder commented Sep 19, 2025

Uh oh!

aerusso commented Sep 20, 2025

Uh oh!

Uh oh!

WavyEbuilder commented Jul 10, 2025 •

edited

Loading

WavyEbuilder Jul 10, 2025 •

edited

Loading

WavyEbuilder commented Jul 28, 2025 •

edited

Loading