<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div>Thanks Alyssa,</div>
<div><br>
</div>
<div>I've seen the previous libwsm project before. From what I can tell, that effort was abandoned without ever leaving the early prototype state. I'm not sure how the pop-os/cosmic-comp PR is relevent. It seems to be about exposing cosmic-comp as a library
in general. While potentially useful, several other compositors have been doing that for a while, and it doesn't seem inform security decisions.</div>
<div><br>
</div>
<div>I think the biggest difference with what I am ultimately trying to do and what the previous libwsm repository and linked mailing list discussion encompassed is that the prior efforts envisioned capabilities as being something a client either has or doesn't
have (perhaps subject to user confirmation). E.G, for my usecase the question is not "does this client have permission to paste from the clipboard" or "does this client have permission to do a capture the screen", but rather "does this client have permission
to view data from this specific wl_data_source<span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">" and "does this client have permission to capture this specific
wl_surface". Notably, this question really is about "capturing this specific wl_surface", and not "a wl_surface owned by this specific client". I anticipate having trusted clients able to surfaces at different sensitivity levels.</span></div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
My concern with creating a high-level permission API is that it will inevitably embed assumptions about possible security models.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Ultimately, I think the first question to answer is if there is any appetite to add some form of security modules to libwayland itself. Without being able to hook directly into some core libwayland functions, I think a higher level API would be pretty much
forced.</div>
<div id="appendonsend"></div>
<div><br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b>From:</b> Alyssa Ross<br>
<b>Sent:</b> Wednesday, May 21, 2025 1:28 PM<br>
<b>To:</b> Sloane, Brandon<br>
<b>Cc:</b> wayland-devel@lists.freedesktop.org; Pekka Paalanen<br>
<b>Subject:</b> RE: [RFC] Wayland Security Modules </div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-size: 11pt;">"Sloane, Brandon" <bsloane@owlcyberdefense.com> writes:<br>
<br>
>> -----Original Message-----<br>
>> From: Pekka Paalanen <pekka.paalanen@haloniitty.fi><br>
>> Sent: Tuesday, May 20, 2025 4:58 AM<br>
>> To: Sloane, Brandon <bsloane@owlcyberdefense.com><br>
>> Cc: wayland-devel@lists.freedesktop.org<br>
>> Subject: Re: [RFC] Wayland Security Modules<br>
>><br>
>> On Mon, 19 May 2025 15:48:04 +0000<br>
>> "Sloane, Brandon" <bsloane@owlcyberdefense.com> wrote:<br>
>><br>
>> > Hello,<br>
>> ><br>
>> > I've spent the past few months prototyping a security modules system<br>
>> > for Wayland. Our specific motivation for this is to support SELinux<br>
>> > integration to meet some rather unique security requirements.<br>
>> > However, what we are proposing here is a rather general purpose<br>
>> > security module system that provides high level hooks modules can then<br>
>> > implement. Potential usecases for this system are:<br>
>> ><br>
>> > * Creating SELinux permissions for Wayland actions.<br>
>> > * Integrating with non-SELinux Linux Security Modules<br>
>> > (AppArmor/SMACK/etc).<br>
>> > * Integrating with PolicyKit.<br>
>> > * Disabling privileged protocols that a specific compositor<br>
>> > implements.<br>
>> > * Restricting privileged protocols to trusted clients.<br>
>> > * Creating backends for wp_security_context_manager.<br>
>><br>
>> Hi,<br>
>><br>
>> from this and the readme I understand that the goal is to remove security<br>
>> policies from compositors and place them outside of compositors and DE<br>
>> projects, where they can be shared by many desktop and other environments.<br>
>> Is that right?<br>
>><br>
>> What is the reason for this goal?<br>
>><br>
>> To unify policy configuration over all environments?<br>
>><br>
>> To enforce policy where the compositor does not do so itself?<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
You might find this previous related discussion interesting:<br>
<br>
<a href="https://lists.freedesktop.org/archives/wayland-devel/2021-July/041897.html" target="_blank" id="OWA0107dce0-daba-66de-695a-7a0bf7ab8d35" class="OWAAutoLink" rel="noopener noreferrer" data-auth="NotApplicable">https://lists.freedesktop.org/archives/wayland-devel/2021-July/041897.html</a><br>
<br>
Later in the thread a similar sounding previous attempt is linked:<br>
<br>
<a href="https://github.com/mupuf/libwsm" target="_blank" id="OWA763b47ab-7ddc-8440-a37d-d2e06ac55b6f" class="OWAAutoLink" rel="noopener noreferrer" data-auth="NotApplicable">https://github.com/mupuf/libwsm</a><br>
<br>
After that conversation I was convinced that this is best implemented<br>
through direct integration with a specific compositor. Some work has<br>
now been started in that direction:<br>
<br>
<a href="https://github.com/pop-os/cosmic-comp/pull/1145" target="_blank" id="OWAff70e3f4-05d4-2ede-721c-5706289ef31f" class="OWAAutoLink" rel="noopener noreferrer" data-auth="NotApplicable">https://github.com/pop-os/cosmic-comp/pull/1145</a><br>
</div>
</body>
</html>