Non-user-inconveniencing privacy and security behavior against screenshot attacks and similar security-hole-based data leaks
Dear Wayland protocol developers, please improve Wayland's privacy and security model against recent screenshot and similar attacks. Use a screenshot and recording security model where applications by default can only get pixels from themselves and some other common user interface elements that are anonymized by default. E.g. using the default desktop background wallpaper image without user generated or any desktop icons for screenshots and screen recordings. Maybe Wayland can specify or include a default (possibly vector-based .svg) image or color. (Avoid blue due to it's effect on the circadian rhythm. Green, yellow and red colors are fine.) Same for sound for both input and output including but not limited to operating system sounds/noises. Thus have a permission model where applications by default can only record their own input(s) and output(s) and some other operating system elements are included but anonymized by default. More generous application permissions must be explicitly and manually set by the user (after installation of the application?) in unambiguous and clear settings in security and privacy settings. Other permissions for an application might be: any other application can record this application's input(s) and output(s) and the dreaded this application can record any other application's input(s) and output(s). This last one must absolutely be explicitly and manually set by the user (after installation of the application) in unambiguous and clear settings in security and privacy settings. Where settings such as whether to show the actual desktop wallpaper, icons and other personal thus privacy-sensitive information to specific applications are also located. 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. One that's clear and unambiguous. Contains everything related to an application's security, privacy, data sharing, permissions, location sharing, antivirus settings for that application, firewall settings for that application, other network security settings, etc. Also no autorun of insertable media by default. Ask what to do (for audio or video media and maybe open the designated file explorer for data carrying media) for the default settings. Thanks for reading and have a nice day.
Re: [PATCH V8 40/43] drm/colorop: Add 3D LUT support to color pipeline
On 5/17/25 2:22 AM, Xaver Hugl wrote:
Am Do., 27. März 2025 um 00:58 Uhr schrieb Alex Hung :
It is to be used to enable HDR by allowing userpace to create and pass
3D LUTs to kernel and hardware.
new drm_colorop_type: DRM_COLOROP_3D_LUT.
Signed-off-by: Alex Hung
---
v8:
- Fix typo in subject (Simon Ser)
- Update documentation for DRM_COLOROP_3D_LUT (Simon Ser)
- Delete empty lines (Simon Ser)
v7:
- Simplify 3D LUT by removing lut_3d_modes and related functions (Simon Ser)
drivers/gpu/drm/drm_atomic.c | 6 +++
drivers/gpu/drm/drm_atomic_uapi.c | 6 +++
drivers/gpu/drm/drm_colorop.c | 72 +++
include/drm/drm_colorop.h | 21 +
include/uapi/drm/drm_mode.h | 33 ++
5 files changed, 138 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 0efb0ead204a..ef47a06344f3 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -806,6 +806,12 @@ static void drm_atomic_colorop_print_state(struct
drm_printer *p,
case DRM_COLOROP_MULTIPLIER:
drm_printf(p, "\tmultiplier=%llu\n", state->multiplier);
break;
+ case DRM_COLOROP_3D_LUT:
+ drm_printf(p, "\tsize=%d\n", colorop->lut_size);
+ drm_printf(p, "\tinterpolation=%s\n",
+
drm_get_colorop_lut3d_interpolation_name(colorop->lut3d_interpolation));
+ drm_printf(p, "\tdata blob id=%d\n", state->data ?
state->data->base.id : 0);
+ break;
default:
break;
}
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 947c18e8bf9b..d5d464b4d0f6 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -719,6 +719,10 @@ static int drm_atomic_color_set_data_property(struct
drm_colorop *colorop,
case DRM_COLOROP_CTM_3X4:
size = sizeof(struct drm_color_ctm_3x4);
break;
+ case DRM_COLOROP_3D_LUT:
+ size = colorop->lut_size * colorop->lut_size *
colorop->lut_size *
+ sizeof(struct drm_color_lut);
+ break;
default:
/* should never get here */
return -EINVAL;
@@ -771,6 +775,8 @@ drm_atomic_colorop_get_property(struct drm_colorop *colorop,
*val = state->multiplier;
} else if (property == colorop->lut_size_property) {
*val = colorop->lut_size;
+ } else if (property == colorop->lut3d_interpolation_property) {
+ *val = colorop->lut3d_interpolation;
} else if (property == colorop->data_property) {
*val = (state->data) ? state->data->base.id : 0;
} else {
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index e03706e7179b..224c6be237d2 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -67,6 +67,7 @@ static const struct drm_prop_enum_list
drm_colorop_type_enum_list[] = {
{ DRM_COLOROP_1D_LUT, "1D LUT" },
{ DRM_COLOROP_CTM_3X4, "3x4 Matrix"},
{ DRM_COLOROP_MULTIPLIER, "Multiplier"},
+ { DRM_COLOROP_3D_LUT, "3D LUT"},
};
static const char * const colorop_curve_1d_type_names[] = {
@@ -82,6 +83,11 @@ static const struct drm_prop_enum_list
drm_colorop_lut1d_interpolation_list[] =
{ DRM_COLOROP_LUT1D_INTERPOLATION_LINEAR, "Linear" },
};
+
+static const struct drm_prop_enum_list drm_colorop_lut3d_interpolation_list[]
= {
+ { DRM_COLOROP_LUT3D_INTERPOLATION_TETRAHEDRAL, "Tetrahedral" },
+};
+
/* Init Helpers */
static int drm_colorop_init(struct drm_device *dev, struct drm_colorop
*colorop,
@@ -349,6 +355,51 @@ int drm_colorop_mult_init(struct drm_device *dev, struct
drm_colorop *colorop,
}
EXPORT_SYMBOL(drm_colorop_mult_init);
+int drm_colorop_3dlut_init(struct drm_device *dev, struct drm_colorop *colorop,
+ struct drm_plane *plane,
+ uint32_t lut_size,
+ enum drm_colorop_lut3d_interpolation_type
interpolation,
+ bool allow_bypass)
+{
+ struct drm_property *prop;
+ int ret;
+
+ ret = drm_colorop_init(dev, colorop, plane, DRM_COLOROP_3D_LUT,
allow_bypass);
+ if (ret)
+ return ret;
+
+ /* LUT size */
+ prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE |
DRM_MODE_PROP_ATOMIC,
+"SIZE", 0, UINT_MAX);
+ if (!prop)
+ return -ENOMEM;
+
+ colorop->lut_size_property = prop;
+ drm_object_attach_property(&colorop->base, colorop->lut_size_property,
lut_size);
+ colorop->lut_size = lut_size;
+
+ /* interpolation */
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
"LUT3D_INTERPOLATION",
Do we ever expec
Re: Non-user-inconveniencing privacy and security behavior against screenshot attacks and similar security-hole-based data leaks
Hello there, On 18 May 2025, at 19:10, Pete wrote: > Also no autorun of insertable media by default. Ask what to do (for audio or > video media and maybe open the designated file explorer for data carrying > media) for the default settings. I really wish Wayland was named something like SUGCP (Secure Unix Graphics Composition Protocol) — it would discourage people from thinking that Wayland is software. Nobody really sends messages to HTTP working group asking for their favourite browser to have a new knob. Maybe it's not too late for a rebranding? -- Best regards, Mikhail.
[RFC] Wayland Security Modules
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. 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. 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. 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. 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. We have also experimented with per-surface screenshot restrictions in Weston, which needs to be implemented almost entirely in the compositor itself. We probably should have gone public with this far earlier in the design process. However, despite the late stage we find ourselves in, we are open to significant revisions based on community feedback. Thanks, Brandon
Re: [PATCH V8 40/43] drm/colorop: Add 3D LUT support to color pipeline
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.
