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