>GNOME lockscreen can be bypassed with vidya game controller
>closed wontfix
>https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7530
gnomebros….. your response?
 UFOs Are A Psyop Shirt $21.68 |
 DMT Has Friends For Me Shirt $21.68 |
UFOs Are A Psyop Shirt $21.68 |
>security
Can you explain the use case?
It's amazing how much bullshit they've forced on everyone with Wayland and Systemd just to do this.
Frick Gnome what a disaster.
>the solution is to ignore the problem and use a different store
HAHAHAHAHAHAHHHAHAHAAHAHAH
Anon, this is moronic and not a security hole.
The devs are right.
Running a command to unlock the lockscreen before starting it, which this program simply does for whatever reason when a button is pressed is not a security issue.
Obviously anything can unlock it. It simply can't be unlocked externally by user input alone. If they fix this “hole” one wouldn't for instance be able to set up a timer that automatically unlocked it after a while; it's moronic to consider this a security hole and closing it in the log screen wouldn't do anything anyway since the user can literally just pkill the lockscreen process after 10 seconds to achieve the same.
This is a moronic complaint.
What's the point of it then, obviously the API that will unlock the lock has no use if it not be locked.
This is like saying:
>There shouldn't be a dbus a.p.i. or any programmatic a.p.i. to unlock the lock at all.
I don't see at all why root should be needed to unlock, why? You should be able to SSH in without root and surrender the lock at any time if you want without having root.
>the user can literally just pkill the lockscreen process after 10 seconds
But no other screen locker on any other system works like this. Windows doesn't let you remotely kill Winlogon. XScreensaver doesn't let you remotely kill it (setuid root). I'm pretty sure Apple's thing doesn't either.
You could argue that what Gnome does is also correct, but the redhat Black folk should actually make that argument, not go "ackshually this is fine", wontfix the issue and make no effort to justify their design decisions.
Well that's silly then but Xscreensaver needs to be setuid root due to how X11 works.
It would be better if Xscreensaver could be unlocked by the user with a command.
They did make that argument when they said it was fine, and it is.
>No, this is not obvious. My expectation is that no non-root process should be able to unlock the system. Violation of that behaviour is very surprising.
Why? What's the advantage of needing root to unlock a screen?
The only important part is that other users can't unlock it.
It's weird though that this is basically the same, correct argument, that people are using to show how Wayland is a security theatre that matters frick all and why they won't “fix” the “security issues” with X11 because it doesn't matter but when GNOME is on the other end they seem to be fine with making the same argument as well it seems, and they're right in this case, but only because a broken clock is right twice per day it seems.
It's simply a violation of how almost all users would expect it to work. If the screen is locked, then I expect that it will stay locked until I unlock it. The idea that I can unlock it is very unexpected and shakes my faith that the system is secure.
>What's the advantage of needing root to unlock a screen?
I accept that a program running as root can do whatever it wants, even if that thing is really weird.
I expect that programs without such privileges aren't able to do such weird things.
>The only important part is that other users can't unlock it.
I wonder how this works when there are multiple local users?
>sign in as alice
>lock and user-switch to bob, keeping alice signed in too
>as bob, set up this "unlock on gamepad press" thing
>lock and choose alice, get to the alice password prompt
>press gamepad button
What happens now?
>It's simply a violation of how almost all users would expect it to work. If the screen is locked, then I expect that it will stay locked until I unlock it. The idea that I can unlock it is very unexpected and shakes my faith that the system is secure.
This doesn't make sense. You say it should be unlocked until you unlock it, but then you say it's unexpected that you can unlock it?
What I would expect is that only I should be able to unlock it and other users can't.
>I expect that programs without such privileges aren't able to do such weird things.
A program running as your shouldn't be able to unlock your own screen?
You say you expect it, but what's the security advantage of this? There are so many disadvantages to this model such as needing root to unlock it without being physically at the terminal or not being able to deal with a hanging lock screen in any way.
>What happens now?
It shouldn't work and if it does that would actually be a bug.
Only Alice' lock screen should be able to be unlocked by Alice' program.
Alice and Bob do not share the same lock screen to begin with if it run as user.
>a program running as your shouldn't be able to unlock your own screen?
A program running as your user shouldn't be able to access your own keypresses? A program running as your user shouldn't be able to access your own screen? A program running as your user shouldn't know its own position and visibility status on screen?
Bypassing lockscreen is less of a security issue than MPV knowing if it's visible on screen or not? Don't be ridiculous.
Every time Gayland Black folk open their prostitute mouths I'm convinced more and more that their whole security model is "I don't want any apps to be able to know what kind of weird porn I'm watching" it's quite literally the only usecase in which Gayland bullshit makes any sort of sense.
Muh secure Wayland.
If I lock my damn computer session THE ONLY thing that should have power to unlock it are my hands on my keyboard putting password into login prompt. Anything else having power to unlock session IS a security issue no matter how you wayland morons try to spin it around. That's the sensible, expected and logical behavior but I guess expecting logic from Wayland shills is too much. Everything must be turned upside down just to "not be like the outdated Xorg bwuuuhwuu" and when someone is outright telling you that shit's working incorrectly you bend your stupid gay ass backwards to pretend that nothing is happening.
By all fricking means please consider suicide. Holy frick, what an absolute dipshit you are.
>If I lock my damn computer session THE ONLY thing that should have power to unlock it are my hands on my keyboard putting password into login prompt. Anything else having power to unlock session IS a security issue no matter how you wayland morons try to spin it around. That's the sensible, expected and logical behavior but I guess expecting logic from Wayland shills is too much. Everything must be turned upside down just to "not be like the outdated Xorg bwuuuhwuu" and when someone is outright telling you that shit's working incorrectly you bend your stupid gay ass backwards to pretend that nothing is happening.
Again, for the thousandth time, why?
What extra security issue does it open up apart from only giving people less flexibility and on top of that requiring a setuid root binary to work opposed to a normal binary.
>Oh no, I can now start a command myself which unlocks the screen, which has many useful applications, what a security issue.
It's hilarious that you call me a “Wayland shill” while this is the kind of security theatre that Wayland used to sell itself and people correctly pointed out that it's asinine of Wayland devs to consider software ran by the user a security threat somehow.
That it requires root or physical access to unlock as said does nothing because software that runs as your own user can literally just delete and read all files on your system or in theory just copy your entire Wayland session to another terminal and let anyone else log in from there; it's an utter security theatre to only allow root or physical access to unlock.
>That it requires root or physical access to unlock as said does nothing because software that runs as your own user can literally just delete and read all files on your system or in theory just copy your entire Wayland session to another terminal and let anyone else log in from there; it's an utter security theatre to only allow root or physical access to unlock.
you convinced me
>Alice and Bob do not share the same lock screen
>It doesn't, you can't send dbus messages to user A's gnome-screensaver process from user B's shell
Alice logs in and locks her screen.
Bob logs in and locks his screen.
Mallory walks up to the computer, sees Bob's lock screen, presses "switch user", chooses Alice.
Bob was the last one to lock their screen, but the computer is now showing a prompt for Alice's password.
Which user owns the process showing that prompt?
If it's Alice's, when did it switch over? Is that transition seamless? Is Bob's still running too, just hidden?
If it's Bob's, does that mean Alice's password is being entered into a process owned by Bob?
If it's a third process owned by root, shouldn't that process always be used for the lock screen?
>presses "switch user"
This should kick you out of the session and back to GDM. I'm sure not even gnomeBlack folk could frick this up.
>If it's a third process owned by root, shouldn't that process always be used for the lock screen?
That's how it works on Windows, but you could argue it doesn't have to be that way.
The lock screen on tty2 is part of Alice's session.
The lock screen on tty3 is part of Bob's session.
well this is simple, it should be handle by a third process owned by root.
(Me)
I ask this because currently I'm convinced that the whole "lock screen process is owned by the user who just locked" concept is fundamentally fricked. Even if the specific user-switching exploit I'm thinking of doesn't work, it feels very flaky and almost guaranteed to have other issues.
>GDM
>This should kick you out of the session and back to GDM
Great. So GDM is able to log people in, accept passwords, etc. It runs as some other user (presumably), and has its own tty. Perfect. Why can't just locking the screen take the user to GDM?
You assume that the setup shares some kind of global session manager that runs as root.
What happens in reality is both wayland compositors output to a different VT and both have a different lock screen running.
Any user that accesses the machine can swtich to any different VT and see what is outputted on it, but for both Alice and Bob is only shown a lock screen that won't do anything unless the password is entered.
Amazing. I kneel.
>I wonder how this works when there are multiple local users?
It doesn't, you can't send dbus messages to user A's gnome-screensaver process from user B's shell. Or at least you shouldn't be able to.
x11 screenlock api even has the option to kill the whole x server if the screen lock is bypassed (such as if it's killed), which brings the user back to the login screen.
Why is the lock screen/screen saver/etc even a separate process that can easily be killed (or indeed politely told to close over dbus)?
Shouldn't it be completely "out of band"? Shouldn't GNOME/whatever work like this:
if screen_locked:
draw_lock_screen()
direct_all_user_input_soley_to_lock_screen()
else:
handle_input_normally()
draw_windows_normally()
with the only way (at least without modifying memory as a root user) to clear screen_locked being to enter a correct password?
>The devs are right
>Obviously anything can unlock it
No, this is not obvious. My expectation is that no non-root process should be able to unlock the system. Violation of that behaviour is very surprising.
just post on reddit talking about the blatant security issues with gnome (i.e this) and talk about moving to KDE. sure KDE will delete all user files but at least they try to improve. when they see redditors talking shit about gnome they'll change it immediately.
this isn't actually a security hole because both the lock screen and the unsandboxed program run inside the same security boundary. it's just using a platform dbus api that it's totally allowed to use. There are many other ways it could achieve the same result as well (loginctl, gdb attach, on Xorg just slurping data from the open display etc etc).
the way to lock down programs from this sort of access is to use flatpak
thanks for copying the footgay's comment so I don't have to give them a click
What the actual frick? Why did they call it a lockscreen if anything can just unlock it? XScreensaver doesn't have this problem.
For what it's worth, I can run sleep 5; loginctl unlock-session in KDE and get the same result.
Interestingly enough, loginctl unlock-sessions requires authentication every time, even though I have just one session on my desktop.
So one could argue this isn't a vulnerability that's unique to Gnome per se, rather an inconsistency in the policies put in place by systemd. This raises the question of whether loginctl unlock-session should require some form of authentication like loginctl unlock-sessions, and if doing so wouldn't break anything else in userspace relying on its current behavior.
xisters i thought wayland is supposed to be more secure and sandboxed. how are random applications running in the same sandbox.
imagine having a lock screen that can be defeated by the rough equivalent of pressing alt+f4
Hold up, the lockscreen runs in user mode? HAHAHAHA
Pretty glad Valve went with KDE for the Steam Deck.
Valve doesn't even use KDE wayland compositor for their deck, it's too unstable.
How did you know its their comment if you already havent given them a click?
It came to me in a dream.
>Valve doesn't even use KDE wayland compositor for their deck, it's too unstable.
They didn't when it came out but they do now.
>Pretty glad Valve went with KDE for the Steam Deck.
>For what it's worth, I can run sleep 5; loginctl unlock-session in KDE and get the same result.
it's the same, just don't use that program if you think it's a huge security risk
>application can close lock screen
I mean... what do you want it to do?
This is like that issue where Ushitu's bundled gnome plugin for a shitty gayOS ripoff dock could be used to bypass the lock screen.
If you have misbehaving shitware, you'll execute code that may or may not do things while the screen is locked. In this case this invokes a dbus call when you touch your gaymer controller.
If we really want a complaint, why is gnome locking the screen while you're inputting with a /dev/input device like a gaymer controller?
The "lock screen" shouldn't have a DBus API for unlocking the screen without authentication. Like, why would you have that? Who dreams this shit up?
To be fair, from the actual lock screen, you really can't interact with dbus normally. You'd need some back channel like this joystick program or a remote shell
Suppose you could argue that if you have a shell, even if you don't know the user's password, the lockscreen is pointless anyway.
On the other hand, you could say that non-malicious software shouldn't be allowed to unlock the screen, or at least not so casually.
Should you blame joystickwake for not properly securing your machine against physical intervention, or gnome-screensaver for even giving it that job in the first place?
FYI, this is why M$ doesn't even let you log into or interact with a captive portal for some Wi-Fi on a lock screen, which also means other issues if you're using an AD account that isn't cached in SAM db.
So that was reason Captain N, had the controller belt.
What does the "N" stands for?
I
>GNOME lockscreen
this exists for other lockscreens too. I even made a program that accepts a controller input and converts it to keyboard input
DESU. I understand the gnome cuck's position, but I also think, of the screen is LOCKED, the dbus APIs to Inhibit / unlock the lock screen should not work. Lock screen should be executed by GDM or root and you should need some auth flow to unlock it.
That way, if you have some remote command or whatever, you still need to authenticate with something like polkit or whatever.
Wow, Wayland sure made everything secure now.
it's not Wayland problem
This, among other reasons, is why Windows and MacOS are the standard, not Linux.
Even if you argue that the lockscreen isn't a viable security measure and, for a miriad of reasons, should be ran under the same permissions and security ring/access-level as other similar applications, this behaviour still breaks user expectations and goes against the purpose of a lockscreen.
Something like this should be absolutely unacceptable. If I were someone in a position of power, in part responsible to the projects funding, I'd cut my support immediately until a proper fix is devised.
Can't imagine a situation where locking a computer and waking it with joystick is mission critical. Fixed.
This is a GNOME problem. KDE and Sway do not have this problem on Wayland.
why did canonical have to kill unity again?
Haven't used this trash since they ruined it with gnome3
The way it's done is IMO perfectly reasonable. Sandboxed applications (running with xdg-dbus-proxy with filtering and no access to privileged Wayland protocols) will not have access to the privileged D-Bus/Wayland API to control session locking. You should be running anything potentially vulnerable/untrusted in flatpak or bwrap scripts. Anything not sandboxed in this way you should assume can control your desktop, access all your user's files or attempt to escalate to root by modifying .bashrc with a fake sudo etc.
I don't use GNOME, but at least on wlroots/sway, lockers work like this:
Your screen locker runs unsandboxed as your user account, and uses this protocol: https://wayland.app/protocols/ext-session-lock-v1
The compositor blanks all outputs and prevents user input from reaching the desktop, and allows the locker to draw some surfaces.
The locker dictates how authentication is handled (almost always PAM) and will tell the compositor to unlock the session when it decides that the user has been authenticated.
If the locker is unexpectedly killed/crashes, the outputs are still permanently blanked and input doesn't reach the desktop.
You can recover from a crash by switching to another VT, logging in, and running the screen locker once more and trying again.
>1st point
didn't major DEs switch Wayland so we didn't have to trust applications to not keylog users? If we have to trust them for this what was the point of that?
>2nd point
you are correct but was it relevant?
Applications cannot keylog or take screenshots or record the desktop under Wayland (Gnome and Plasma only wlroots based compositor just allow everything). You can disable the screen lock from an unsandboxed app because the app is not sandboxed and thus allowed to call dbus. If you run untrusted applications outside of flatpak you are to blame yourself.
This, the idea is that pipewire and a sandbox like flatpak can impose access controls so that only the necessary programs can be configured to have screen recording or global shortcut permissions.
To expand on the wlroots point, there are a bunch of "unsafe" protocols that allow you to do neat things like this: https://git.sr.ht/~brocellous/wlrctl
This doesn't use D-Bus, and so has no standardised way of doing access controls (GNOME on the other hand wants everything to be done through D-Bus, including the screen locker from the OP), so it almost defeats the purpose of Wayland's security focus.
Though, https://wayland.app/protocols/security-context-v1 (https://git.sr.ht/~whynothugo/way-secure https://github.com/swaywm/sway/commit/072fa60cb401acb2e257a03baf41c8ae63f4753d) is supposed to allow you to run Wayland applications without access to those privileged protocols on wlroots. Still in early stages I guess and only recognised by a niche of users.
>untrusted applications
care to name such applications instead of talking constant shit and creating boogiman out of nothing?
I'm a different anon but this includes stuff like firefox/chromium, ffmpeg/mpv, games, potentially anything parsing complex file formats/network bytes like archivers, file sharing programs, chat clients. Just some damage control if bugs are exploited. Defense in depth, principle of least privilege, that shit.
I get the concern with sandboxing when you look at locked down platforms like Android/iOS, and you can definitely make things too inconvenient or lose all composability if you try to secure things too hard, but the Linux desktop having some amount of sandboxing capability (that is 100% in the user's control and can be turned off) without resorting to separate virtual machines or xephyr/xpra (which suck for performance/latency/convenience) would be nice.
you activated my trap card!
I don't use Gn*me but can one of you try this? Enable automounting and autoexecute of removable devices, save the following code as "autorun" and make it executable.
Then lock your screen, insert usb.
#!/usr/bin/env bash
loginctl unlock-session
Does it unlock your session? It doesn't unlock on KDE5.
what the frick kind off mental gymnastics is this
CLOSED WONTFIX
I'm not a GNOME shill, but they're correct for once. No mental gymnastics. This is how Linux desktop security has worked and will work for the forseeable future. Run your shit in a secure sandbox if you don't want it to call platform D-Bus APIs/privileged wlroots protocols or overwrite .bashrc.
>This is how Linux desktop security has worked and will work for the forseeable future.
Our complaint is that they've rearranged half the OS and broken a lot of stuff in the name of "fixing" that just to half ass their own solution.
>install an application to disable the lockscreen while using a gaming controller
>wtf why is this application bypassing the lockscreen when i use my gaming controller????
>enabled lockscreen can simply be "disabled" by a random app
lmao
a "random app" can also steal all your keystrokes
just a bunch of moronic gnome hater in this thread
Sad!
>Linux screensavers run in the same desktop and at the same privilege level as user applications
LMFAO this is a fricking joke right?
On Windows the winlogon application runs in a separate desktop (thereby solving the UI isolation issue) and also at a higher privilege level than normal applications.
Linshitters had to come up with crummy and incompatible workarounds like Wayland instead of fixing their bad architecture.
>GNOME problem = linux problem
the mutt's law of IQfy
considering gnome is what's shipped by default on most big-dog distros (Fedora, SUSE, Ubuntu, Debian), and what is most likely used in enterprise sectors and businesses all over the world, it very much likely is a "Linux" problem.
The situation here is the equivalent of the protocol between winlogon.exe and explorer.exe (the shell) being documented, such that any other application can tell explorer.exe to unlock the screen in the same way that winlogon.exe itself would have. It doesn't matter that winlogon.exe itself runs privileged.
Now you could say "But winlogon.exe itself does not exit in that case either, because it was launched from a more privileged process (and isolated desktop) so the system itself ensures it remains running". That could be done in Linux too, but it's not the job of an unprivileged compositor like GNOME. It would be a matter of writing a service that is able to take over the tty that the compositor is running on (ie remove DRM master privs from the compositor) and then restore them when it's done.
It can even be done with a "no-code" way by switching to a different VT and disallow `Ctrl-Alt-F#` to switch VTs. Then you would have to log in into the second VT and run `chvt` to get back to the one with your compositor.
If you want to lock your system just press Ctrl Alt F2.
>application running outside of the sandbox can access other applications running outside of the sandbox
Yes so what? How is this news? I run everything inside a container or inside flatpak.
B...But muh Wayland security! I bet its much worse on X11 !!1!
The screen lock being exposed over dbus has nothing to do with x or Wayland. It's a correct implementation detail of Gnome. Someone who runs X11 (and thus let's every application keylog and record their screen) shouldn't worry about a lockscreen.
just kill x and logout from tty. if you need something daemonized use t-mux
>lockscreen
You should know lock screen is only good to prevent someone (like a family member or a coworker) from peeking at your desktop. It's not an anihacking measure. You shouldn't leave your PC unattended for longer than 5 minutes when screen is locked. Otherwise just turn it off.
on android or any of the mobile user interfaces(that guhnome is trying so desperately to become) the application just shows a notification on lockscreen if there is a need of an user input.
guhnome will take 20 years and 5 rewrites to implement this ""feature"".
despite being an absplute shitshow of a """" non profit"""" organization, ibm daddys cant stop bribing random youtubers and blogwriters to sing pages of praises for the worst thing that happened to linux desktop. i do understand the need of dbus and polkit for a well integrated system but guhnomes just abusing it for everything they can think of. dbus and polkit couldve been the modern IPC standard across entire operating system instead of being a hack to implement basic desktop UI functionality.
frick redhat frick guhnome. they are not only sabotaging linux but the future of every unix like operating system out there.
>lockscreen
Physical access is root access.
You don't _need_ flatpak, though it's the most convenient option for users, who don't want to configure a sandbox themselves using the available primitives (wayland protocol filtering on wlroots, dbus filtering, pipewire access control, portals, namespaces, seccomp).
Maybe at some point there could be alternatives to flatpak (there kind of already are with firejail and bubblejail). Personally I roll my own bwrap scripts and tools as needed, since I don't like flatpak and I get more customisability and flexibility, nor do I care about a unified "linux app store".
Most of us don't want or need a fricking sandbox or non-free software.
Please frick off.
>be re/dditor
>hates IQfy and IQfyners
>one day gets his thread closed
>come to IQfy crying
many such cases!
>this isn't actually a security hole because both the lock screen and the unsandboxed program run inside the same security boundary. it's just using a platform dbus api that it's totally allowed to use. There are many other ways it could achieve the same result as well (loginctl, gdb attach, on Xorg just slurping data from the open display etc etc).
the way to lock down programs from this sort of access is to use flatpak
is this the power of le most secure operating system?
So I can use that controller to unlock gnome machines?
Sweet!
Linux security is a joke, has always been a joke, and will likely remain a joke.
Hold on, does it mean that no longer does the screen lock itself if I'm using a controller?
Because that was annoying as frick to deal with. To be playing a game and 20 minutes later it's locking me out because it hasn't detected either the mouse or the keyboard.
>To be playing a game and 20 minutes later it's locking me out because it hasn't detected either the mouse or the keyboard.
The issue is simple. It should delay the session locking while a fullscreen application is running, like what it does with video-players and such.
>muh wayland muh security!!!1
>btw your application can just run this dbus command to do whatever it wants
lol lmao even
I mean they're right here that stopping this would be a complete security theatre, but they use the exact same theatre arguments themselves in other cases so it's weird.
Stopping the user from unlocking the screen would do nothing. THe user can literally read the memory of the compositor and dump it to clone it somewhere else to begin with or simply ptrace it and force it to restart without a dbus call so not exposing the dbus call is just silly inconvenience.
The command existing is the right choice. Removing it provides no actual security and simply inconveniences people. It's just weird that they used all those arguments for gimping Wayland for no reason.
>Appears in: XORG & Wayland
AHAHAHAHAHAHAHAHA
WAYLAND
>>>>>>>>>>
15 YEARS OF WASTED DEVELOPMENT