# Linux desktop environment security wrt screenshot privileges **URL:** https://discuss.privacyguides.net/t/linux-desktop-environment-security-wrt-screenshot-privileges/19910 **Category:** General **Created:** 2024-08-06T15:44:39Z **Posts:** 20 ## Post 1 by @Regime6045 — 2024-08-06T15:44:39Z Continuing the discussion from [People should avoid Wayland environments which use wlroots as the compositor - #7 by jerm](https://discuss.privacyguides.net/t/people-should-avoid-wayland-environments-which-use-wlroots-as-the-compositor/17899/7) * * * Well that’s silly. In my opinion this is just security theatre (“yes, I want to allow the screenshot program I installed to take a screenshot”) and the trade-off is that you’d have to use Gnome as a desktop environment which is completely unusable unless you install half a dozen third-party extensions which is way more of a security issue. edit: [found the related feature request](https://bugs.kde.org/show_bug.cgi?id=491037) Quote by Nate Graham from KDE: > That already happens for apps using the portal API. It doesn’t happen for Spectacle and Flameshot because they use a special internal KWin-only screenshot API that bypasses the confirmation prompt, for usability’s sake. They do this because they are screenshot apps, and as I alluded to before, making an app ask the user for permission every time it wants to exercise its primary purpose makes people want to throw their computers out the window. > > Now, you might say, “the existence of this backdoor means any Wayland app can use it to take screenshots without permission on KWin”. And you would be right. There are trade-offs here. > > It’s an open topic of discussion, and we may end up porting back to the portal API and trying to improve its usability. For example, asking only once per app, as you suggested. > > It may or may not be feasible, though. > > Regardless, this is a topic that KWin and Plasma folks are aware of. --- ## Post 2 by @RoyalOughtness — 2024-08-06T18:01:20Z It’s not silly and your reduction of the issue isn’t accurate. This isn’t about screenshot apps being able to take screenshots. It’s about _any_ app being able to take screenshots, which breaks content isolation for wayland applications. Knowingly trading off application isolation for user convenience is a sad indication of the current prioritization of security in KDE, and I hope that they reconsider. Sacrificing wayland application isolation to save the user a click, aside from being a poor design choice, is a false dichotomy. To screenshot on GNOME, no click is required because the shell itself takes screenshots. So KDE could solve this like GNOME without the need to “inconvenience the user” by building the screenshot utility into plasma-shell itself. > Gnome as a desktop environment which is completely unusable :smile: while I tend to agree somewhat with your subjective assessment of GNOME’s usability and prefer KDE Plasma’s workflow, I’ve begrudgingly switched to GNOME since this issue was uncovered. This issue is egregious enough to warrant using vanilla GNOME unless and until other DEs decide that application isolation is important. --- ## Post 3 by @redoomed1 — 2024-08-06T18:13:34Z Just to add on, in the latest release of the site, dngray and I added a [Permission Controls](https://www.privacyguides.org/en/os/linux-overview/#permission-controls) section to the Linux Overview that discusses GNOME’s screenshot permission. Related PR: [https://github.com/privacyguides/privacyguides.org/pull/2690](https://github.com/privacyguides/privacyguides.org/pull/2690) --- ## Post 4 by @RoyalOughtness — 2024-08-06T18:17:08Z secureblue started [recommending GNOME images](https://github.com/secureblue/secureblue/blob/78b531846db4362cf629f31ee6ef1727052c17f6/RECOMMENDED.md) as well :smile: --- ## Post 5 by @xe3 — 2024-08-06T18:44:59Z > [@Regime6045](#): > > which is _completely unusable_ unless you install half a dozen extensions I think you are confusing your own subjective personal preferences with something objective and universal (and presenting it in rather hyperbolic terms). Extensions are optional and not necessary with Gnome. Many people use a few to customize their desktop to their subjective preferences, and many people use none or one. I’m in the latter category, as are a large number of other Fedora users (before Fedora’s recent popularity, shipping a mostly unadulterated “vanilla Gnome” was one of the most commonly mentioned reasons for choosing Fedora). * * * > Well that’s silly. In my opinion this is just security theatre That KDE contributor you quoted doesn’t appear to share your point of view: > “the existence of this backdoor means _any Wayland app can use it to take screenshots without permission on KWin_”. And you would be right. There are trade-offs. You could try to make the argument that the usability costs outweigh the security benefits, but calling it “security theatre” seems pretty misleading (assuming the quote above is accurate). --- ## Post 6 by @asanyan — 2024-08-06T20:30:39Z It seems that both sway and kde [currently implement the security context wayland protocol](https://wayland.app/protocols/security-context-v1), meaning that sandboxed applications with flatpak already have privileged protocols such as screencopy disabled inside the sandbox. Firejail doesn’t yet implement it but there’s an issue open for it [here](https://github.com/netblue30/firejail/issues/5883) --- ## Post 7 by @RoyalOughtness — 2024-08-07T22:17:43Z It’s a step in the right direction, but it still pales in comparison to what GNOME is doing: preventing all processes running under an unprivileged user, regardless of sandboxing, from accessing screencopy without user consent. --- ## Post 8 by @asanyan — 2024-08-08T01:05:16Z I really don’t see how that is much better. Unsandboxed applications can spy on the user through many different ways. Restricting this only matters if the application already can’t do whatever it wans to the system --- ## Post 9 by @RoyalOughtness — 2024-08-08T01:32:28Z If you are aware of a mechanism by which a program running as an unprivileged (non-wheel) user can read the content of other applications or keylog the input for other applications, please do elaborate. --- ## Post 10 by @asanyan — 2024-08-08T02:35:46Z [LD\_PRELOAD](https://github.com/Aishou/wayland-keylogger) --- ## Post 11 by @RoyalOughtness — 2024-08-08T03:03:14Z Ah, yep. This will be a problem until [Confined Users](https://discussion.fedoraproject.org/t/security-enthusiasts-wanted-from-beginners-up-to-selinux-experts-to-make-up-the-selinux-confined-users-sig-to-foster-fedoras-security-capabilities/89127) are mature enough to ship by default, which is the plan for Fedora. > Restricting this only matters if the application already can’t do whatever it wans to the system The goal should be to close all the holes, even if there’s more than one. --- ## Post 12 by @sha123 — 2024-08-08T07:25:53Z > [@RoyalOughtness](#): > > Ah, yep. This will be a problem until [Confined Users](https://discussion.fedoraproject.org/t/security-enthusiasts-wanted-from-beginners-up-to-selinux-experts-to-make-up-the-selinux-confined-users-sig-to-foster-fedoras-security-capabilities/89127) are mature enough to ship by default, which is the plan for Fedora I don’t see how Selinux users can help with this. They are designed to strengthen the security boundary between users, not to confine individual applications from each other within a user. --- ## Post 13 by @RoyalOughtness — 2024-08-08T07:46:52Z You’re right actually, this should be possible already without confined users. Confined users would help in other ways though and could potentially make it easier to write policies around this. I’m writing an SELinux policy that should prevent the LD\_PRELOAD issue. I’ll post it once it’s tested. --- ## Post 14 by @RoyalOughtness — 2024-08-08T08:50:27Z Edit: **Please largely disregard the configuration below, it was for testing and is not robust.** Alright, I got it working :smile: Note: use at your own risk. Doing the below steps will prevent unconfined processes from modifying .bashrc or .bash\_profile, even when run as root. This completely prevents the LD\_PRELOAD-via-bashrc issue. Step 1: Create a file addbashrctype.cil: ``` (type bashrc_t) (typeattributeset file_type (bashrc_t)) (roletype object_r bashrc_t) ``` Step 2: Install it: `semodule -i addbashrctype.cil` Step 3: Set .bashrc and .bash\_profile to the new type: `semanage fcontext -a -t bashrc_t '/var/home/yourusername/.bashrc'` `semanage fcontext -a -t bashrc_t '/var/home/yourusername/.bash_profile'` Step 4: Run restorecon to apply the types: `restorecon -v /var/home/yourusername/.bashrc` `restorecon -v /var/home/yourusername/.bash_profile` Step 5: Create a file denyrule.cil: ``` (deny unconfined_t bashrc_t (file (write))) ``` Step 6: Install it: `semodule -i denyrules.cil` Step 7: Attempt to modify .bashrc or .bash\_profile as any user, it fails. Bash variables are still of course globally modifiable in /etc/bashrc and /etc/profiles.d, but only as root/wheel. So this solution works but is less feasible on a multi-user system than on a single-user system, where making global bashrc modifications in /etc/bashrc is a reasonable alternative. --- ## Post 15 by @jerm — 2024-08-08T10:31:29Z > **[491037 – Wayland screencopy should make a popup, requesting access from the user](https://bugs.kde.org/show_bug.cgi?id=491037#c5)** Dev replied about this thread and commented some corrections on the relevant PR on Github. --- ## Post 16 by @RoyalOughtness — 2024-08-08T16:59:19Z I responded there. It’s fairly easy to reproduce the issue on Plasma, so I’m not sure what he’s referring to. --- ## Post 17 by @sha123 — 2024-08-09T07:04:25Z Wait, Selinux has the long missed `deny` instruction? That must be quite new. Wouldn’t you need to block other operations aside from `write`? For example: `(deny unconfined_t bashrc_t (file (write append create rename unlink truncate relabelto)))` Maybe the best way would be to create a new Selinux user by copying some existing like `user_u` and adjusting this rule to the new Selinux user. Is that what you meant by referring to confined users? Edit: You could also write protect these files against non-root users via attributes `chattr +i filename` as a somewhat easier solution --- ## Post 18 by @RoyalOughtness — 2024-08-09T18:50:46Z > Wait, Selinux has the long missed `deny` instruction? That must be quite new. Yep, somewhat new: [https://lukas-vrabec.com/index.php/2024/02/14/introduction-of-deny-rules-for-selinux-policy/](https://lukas-vrabec.com/index.php/2024/02/14/introduction-of-deny-rules-for-selinux-policy/) > Wouldn’t you need to block other operations aside from `write` ? Might as well, what I wrote is just a proof of concept, not a complete solution > You could also write protect these files against non-root users via attributes `chattr +i filename` as a somewhat easier solution That’s not the goal here, non-root users _should_ be able to modify their .bashrc. What I posted earlier is a proof of concept and only half a solution. The second half of the solution is to choose a specific text editor, confine it, and grant it access to bashrc\_t. That way arbitrary unconfined processes can’t modify those files, but the user still has a way to modify them via a specific confined text editor. > **[Using SELinux to secure against LD_PRELOAD attacks](https://discussion.fedoraproject.org/t/using-selinux-to-secure-against-ld-preload-attacks/128089)** > > I’ve been experimenting with ways to use SELinux to prevent LD_PRELOAD attacks such as the one demonstrated in GitHub - Aishou/wayland-keylogger: Proof-of-concept Wayland keylogger So far, I have the following which works but is not as elegant as... --- ## Post 19 by @RoyalOughtness — 2024-08-09T19:11:40Z That said, I think your method is a much better temporary fix than mine since it will take time to come up with comprehensive selinux policies. I’m inclined to add a `ujust toggle-bash-environment-lockdown` toggle to secureblue that uses polkit to prompt for a wheel user’s password and toggles the chattr +i state on bash profile files, like you mentioned. --- ## Post 20 by @RoyalOughtness — 2024-08-09T19:12:30Z FYI [update: Remove Wayland section from and add Permission Controls section to Linux Overview by redoomed1 · Pull Request #2690 · privacyguides/privacyguides.org · GitHub](https://github.com/privacyguides/privacyguides.org/pull/2690/files#r1711614243)