"Sloane, Brandon" <bslo...@owlcyberdefense.com> writes: >> -----Original Message----- >> From: Pekka Paalanen <pekka.paala...@haloniitty.fi> >> Sent: Tuesday, May 20, 2025 4:58 AM >> To: Sloane, Brandon <bslo...@owlcyberdefense.com> >> Cc: wayland-devel@lists.freedesktop.org >> Subject: Re: [RFC] Wayland Security Modules >> >> On Mon, 19 May 2025 15:48:04 +0000 >> "Sloane, Brandon" <bslo...@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
signature.asc
Description: PGP signature
