Re: [RFC] Wayland Security Modules
On Mon, 19 May 2025 15:48:04 + "Sloane, Brandon" 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? > Our current proof of concept is here: > https://gitlab.freedesktop.org/bsloane1650/wayland. Some more > in-depth technical discussion is available in the doc/WSM.md file in > that repository. > > We also have some modules in development here: > https://gitlab.freedesktop.org/bsloane1650/wayland-security-modules > * Logger - a basic proof of concept that demonstrates instantiating a > module and logging every access. > * Allow-list - A basic proof of concept that demonstrates globally > restricting what interfaces can be used. > * SELinux - A more complex module that defers all access decisions to > the system's SELinux policy (under active development) > > The overall design is to add hooks at key points in libwayland: > * Creation and destruction of core libwayland objects: wl_client, > wl_display, wl_global, wl_resource > * Prior to sending an event to the client > * Prior to invoking the request handler after receiving a request > from a client. > * Prior to publishing a global object > * Prior to binding a global object. What about all the other Wayland protocol implementations that do not use libwayland? Or those that bundle a libwayland without the hooks? > A security module is represented by a "struct wsm" object, which has > void* for modules to use, and a function pointer for each hook. > Compositors can instantiate these structs however they like and pass > them into a new wl_display_create_with_wsms method. The existing > wl_display_create method is modified to dynamically load shared > object files based on the new WAYLAND_SECURITY_MODULES environmental > variable. These shared objects are expected to export a wl_wsm_init > symbol that instantiates a wsm structure. What's the failure mode of losing the environment variable by accident, e.g. by a software update? Any security limitations just won't be there and without notice? Isn't that too fragile and invisible? > We have had success running this by linking unmodified compositors > (mostly Weston) against an updated libwayland. Depending on what > accesses the module blocks, existing compositors work without even > needing a recompile. However, to be useful, we have found a couple of > areas that additional compositor integration is needed. Mostly this > has been shifting from wl_resourc_create to > wl_resource_create_with_related in a few key places (such as creating > a wl_data_offer) to allow the security modules to associated > resources that are shared between clients. To me this sounds like aiming for unmodified compositors just won't work. Would it not be better to aim for explicit integration? Or, if unmodified compositors is an explicit design goal, make the security layer a Wayland proxy? An independent man-in-the-middle process. > We have also found a need to modify compositors to deal with denials > associated with new_id type requests. We think we have a workable > solution implemented in libwsm_compositor that compositors can > incorporate with a few library calls; but I still consider this the > most questionable part of the project. This issue is discussed rather > in much more detail in doc/WSM.md. Any input on this would be greatly > appreciated. You cannot "deny" any request at will, not even those without new_id arguments. The protocol specification defines the behaviour of each request, and a security module cannot decide against the spec. It would break the protocol, cause mismatching state between the compositor and the client, likely lead to hard-to-debug failure modes if it does not outright cause a protocol error soon after, disconnecting the client. Some requests are specified so that the compositor can decide to refuse, but those are very rare. In general, it makes no sense to be able to gate each and ev
Proposal: no more alphas/betas for Wayland releases
Hi all, With years passing by, development in the main Wayland repository has slowed down quite a bit, activity has moved over to wayland-protocols and compositors. However, cutting a new Wayland release is still a heavyweight process: it takes at least one and a half months with at least 3 pre-releases. I'm also not sure about the value of all of these pre-releases: historically they've been used to push the last features over the fence before the RCs, but it's easy enough to talk and coordinate over the bits that we want to wait on for the release. I would suggest to drop the alphas/betas from the release process, ie. go straight to RC1. The process would then continue as usual, with weekly RCs. As a release manager this would help reduce the load. This is also what I've been doing for Sway and wlroots for a very long time. Would this make sense? Are there other reasons why alphas/betas were valuable? Thanks, Simon
Re: Non-user-inconveniencing privacy and security behavior against screenshot attacks and similar security-hole-based data leaks
On Sun, 18 May 2025 17:10:36 + (UTC) Pete wrote: > Dear Wayland protocol developers, please improve Wayland's privacy > and security model against recent screenshot and similar attacks. Hi, what attacks are you referring to? > Use > a screenshot and recording security model where applications by > default can only get pixels from themselves This is already the case in Wayland. Which is not to say anything about interfaces elsewhere. > Same for sound for both input and output including but not limited to > operating system sounds/noises. Audio is not in Wayland's scope. There are no audio interfaces in Wayland. > Security and privacy settings must also have a place that's a list of > installed application where for each application a security and > privacy oversight can be opened. Any kind of settings are out of Wayland's scope. User interface design is out of scope. > Also no autorun of insertable media by default. Out of scope. Wayland has nothing to do with that. Thanks, pq pgpNl76p5kCvN.pgp Description: OpenPGP digital signature
Re: [PATCH V8 40/43] drm/colorop: Add 3D LUT support to color pipeline
On 2025-05-19 19:43, Simon Ser wrote: > On Sunday, May 18th, 2025 at 00:32, Xaver Hugl wrote: > >>> We can always make the property mutable on drivers that support it in >> >>> the future, much like the zpos property. I think we should keep it >>> immutable for now. >> >> Sure, but I don't see any reason for immutability with an enum >> property - it can just limit the possible values to what it supports, >> and that can be only one value. Either way, it's not a big issue. > > Immutability is a clear indication that a property has a fixed read-only > value which can't be switched by user-space. That's also the pattern > used everywhere in the KMS uAPI, so I think it's better to remain > consistent here. I was envisioning this to be a driver-caps thing, but I agree if we make this mutable it can still serve that function but with different/future HW possibly support other interpolation schemes. Harry
RE: [RFC] Wayland Security Modules
> -Original Message- > From: Pekka Paalanen > Sent: Tuesday, May 20, 2025 4:58 AM > To: Sloane, Brandon > Cc: wayland-devel@lists.freedesktop.org > Subject: Re: [RFC] Wayland Security Modules > > On Mon, 19 May 2025 15:48:04 + > "Sloane, Brandon" 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. > > > Our current proof of concept is here: > > https://gitlab.freedesktop.org/bsloane1650/wayland. Some more in-depth > > technical discussion is available in the doc/WSM.md file in that > > repository. > > > > We also have some modules in development here: > > https://gitlab.freedesktop.org/bsloane1650/wayland-security-modules > > * Logger - a basic proof of concept that demonstrates instantiating a > > module and logging every access. > > * Allow-list - A basic proof of concept that demonstrates globally > > restricting what interfaces can be used. > > * SELinux - A more complex module that defers all access decisions to > > the system's SELinux policy (under active development) > > > > The overall design is to add hooks at key points in libwayland: > > * Creation and destruction of core libwayland objects: wl_client, > > wl_display, wl_global, wl_resource > > * Prior to sending an event to the client > > * Prior to invoking the request handler after receiving a request from > > a client. > > * Prior to publishing a global object > > * Prior to binding a global object. > > What about all the other Wayland protocol implementations that do not use > libwayland? Or those that bundle a libwayland without the hooks? Our changes should only effect libwayland-server, and do not change the wire format at all. As such, non-libwayland clients should work just as well as libwayland clients. For compositors, a non-libwayland compositor would not see any change or benefit from this effort. If they want to be able to use a WSM, they would need to implement enough of the libwayland-server ABI to be compatible with whatever module(s) they want to use (or just the libwayland-server API if recompiling the module is acceptable). Originally, we had intended to have a WSM API that modules would be written against, which better enable sharing with non-libwayland compositors. However, we ultimately determined that such an API was not worth the effort. > > > > A security module is represented by a "struct wsm" object, which has > > void* for modules to use, and a function pointer for each hook. > > Compositors can instantiate these structs however they like and pass > > them into a new wl_display_create_with_wsms method. The existing > > wl_display_create method is modified to dynamically load shared object > > files based on the new WAYLAND_SECURITY_MODULES environmental >
