[RFC] Wayland Security Modules

[Alyssa Ross]

"Sloane, Brandon" <bsloane at owlcyberdefense.com> writes:

>> -----Original Message-----
>> From: Pekka Paalanen <pekka.paalanen at haloniitty.fi>
>> Sent: Tuesday, May 20, 2025 4:58 AM
>> To: Sloane, Brandon <bsloane at owlcyberdefense.com>
>> Cc: wayland-devel at lists.freedesktop.org
>> Subject: Re: [RFC] Wayland Security Modules
>> 
>> 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?
>
> I would say the goal is to move security policy out of the compositors to the system integrators. I tend to consider DE projects to be a form of system integration, so using them using this to implement their own security policies would be well within scope (although I would hope they do so in a way that allows downstream integrators to replace the security policy if needed). Our specific motivation is that we building systems with some rather niche security requirements that would not be suitable to implement in a general purpose DE. We also want to unify our policy configuration with a single environment, so our network policy, file access policy, device access policy, and GUI policy can all exist as a single unified security policy.
>
> The ability of have a common policy configuration work across different environments/compositors is nice, but was not a primary design goal. As we went to design this, we quickly found that, even if we were only concerned with a single compositor, the low-level IPC layer by far the most natural and simplest place to implement this.

You might find this previous related discussion interesting:

https://lists.freedesktop.org/archives/wayland-devel/2021-July/041897.html

Later in the thread a similar sounding previous attempt is linked:

https://github.com/mupuf/libwsm

After that conversation I was convinced that this is best implemented
through direct integration with a specific compositor.  Some work has
now been started in that direction:

https://github.com/pop-os/cosmic-comp/pull/1145
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20250521/3e5d4711/attachment.sig>