Linux desktop environment security wrt screenshot privileges

General
1

Continuing the discussion from People should avoid Wayland environments which use wlroots as the compositor - #7 by jerm

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

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.

2 Likes
2

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.

4 Likes
3

Just to add on, in the latest release of the site, dngray and I added a Permission Controls section to the Linux Overview that discusses GNOME’s screenshot permission.

Related PR:
https://github.com/privacyguides/privacyguides.org/pull/2690

3 Likes
4

secureblue started recommending GNOME images as well :smile:

2 Likes
5

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).

2 Likes
6

It seems that both sway and kde currently implement the security context wayland protocol, 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

1 Like
7

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.

1 Like
8

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

9

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.

1 Like
10

LD_PRELOAD

1 Like
11

Ah, yep. This will be a problem until Confined Users 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.

1 Like
12

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.

13

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.

1 Like
14

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.

2 Likes
15

Dev replied about this thread and commented some corrections on the relevant PR on Github.

2 Likes
16

I responded there. It’s fairly easy to reproduce the issue on Plasma, so I’m not sure what he’s referring to.

1 Like
17

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

18

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/

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.

2 Likes
19

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.

2 Likes
20

FYI update: Remove Wayland section from and add Permission Controls section to Linux Overview by redoomed1 · Pull Request #2690 · privacyguides/privacyguides.org · GitHub

3 Likes