>GNOME lockscreen can be bypassed with vidya game controller. >closed wontfix

>GNOME lockscreen can be bypassed with vidya game controller
>closed wontfix
>https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7530

gnomebros….. your response?

POSIWID: The Purpose Of A System Is What It Does Shirt $21.68

Tip Your Landlord Shirt $21.68

POSIWID: The Purpose Of A System Is What It Does Shirt $21.68

  1. 3 weeks ago
    Anonymous

    >security
    Can you explain the use case?

    • 3 weeks ago
      Anonymous

      It's amazing how much bullshit they've forced on everyone with Wayland and Systemd just to do this.
      Frick Gnome what a disaster.

  2. 3 weeks ago
    Anonymous

    >the solution is to ignore the problem and use a different store
    HAHAHAHAHAHAHHHAHAHAAHAHAH

    • 3 weeks ago
      Anonymous

      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.

      What the actual frick? Why did they call it a lockscreen if anything can just unlock it? XScreensaver doesn't have this problem.

      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.

      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.

      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.

      • 3 weeks ago
        Anonymous

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

        • 3 weeks ago
          Anonymous

          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.

          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.

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

          • 3 weeks ago
            Anonymous

            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?

          • 3 weeks ago
            Anonymous

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

          • 3 weeks ago
            Anonymous

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

          • 3 weeks ago
            Anonymous

            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.

          • 3 weeks ago
            Anonymous

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

          • 3 weeks ago
            Anonymous

            >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

          • 3 weeks ago
            Anonymous

            >Alice and Bob do not share the same lock screen

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

            >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?

          • 3 weeks ago
            Anonymous

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

          • 3 weeks ago
            Anonymous

            The lock screen on tty2 is part of Alice's session.
            The lock screen on tty3 is part of Bob's session.

          • 3 weeks ago
            Anonymous

            well this is simple, it should be handle by a third process owned by root.

          • 3 weeks ago
            Anonymous

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

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

            >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?

          • 3 weeks ago
            Anonymous

            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.

            >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

            Amazing. I kneel.

          • 3 weeks ago
            Anonymous

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

        • 3 weeks ago
          Anonymous

          xisters i thought wayland is supposed to be more secure and sandboxed. how are random applications running in the same sandbox.

          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.

      • 3 weeks ago
        Anonymous

        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.

        • 3 weeks ago
          Anonymous

          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.

  3. 3 weeks ago
    Anonymous

    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

    • 3 weeks ago
      Anonymous

      thanks for copying the footgay's comment so I don't have to give them a click

    • 3 weeks ago
      Anonymous

      What the actual frick? Why did they call it a lockscreen if anything can just unlock it? XScreensaver doesn't have this problem.

    • 3 weeks ago
      Anonymous

      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.

    • 3 weeks ago
      Anonymous

      xisters i thought wayland is supposed to be more secure and sandboxed. how are random applications running in the same sandbox.

  4. 3 weeks ago
    Anonymous

    imagine having a lock screen that can be defeated by the rough equivalent of pressing alt+f4

  5. 3 weeks ago
    Anonymous

    Hold up, the lockscreen runs in user mode? HAHAHAHA

  6. 3 weeks ago
    Anonymous

    Pretty glad Valve went with KDE for the Steam Deck.

    • 3 weeks ago
      Anonymous

      Valve doesn't even use KDE wayland compositor for their deck, it's too unstable.

      thanks for copying the footgay's comment so I don't have to give them a click

      How did you know its their comment if you already havent given them a click?

      • 3 weeks ago
        Anonymous

        It came to me in a dream.

      • 3 weeks ago
        Anonymous

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

    • 3 weeks ago
      Anonymous

      >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

  7. 3 weeks ago
    Anonymous

    >application can close lock screen
    I mean... what do you want it to do?

  8. 3 weeks ago
    Anonymous

    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?

    • 3 weeks ago
      Anonymous

      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?

      • 3 weeks ago
        Anonymous

        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

        • 3 weeks ago
          Anonymous

          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?

  9. 3 weeks ago
    Anonymous

    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.

  10. 3 weeks ago
    Anonymous

    So that was reason Captain N, had the controller belt.

    • 3 weeks ago
      Anonymous

      What does the "N" stands for?

      • 3 weeks ago
        Anonymous

        I

  11. 3 weeks ago
    Anonymous

    >GNOME lockscreen
    this exists for other lockscreens too. I even made a program that accepts a controller input and converts it to keyboard input

  12. 3 weeks ago
    Anonymous

    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.

  13. 3 weeks ago
    Anonymous

    Wow, Wayland sure made everything secure now.

    • 3 weeks ago
      Anonymous

      it's not Wayland problem

  14. 3 weeks ago
    Anonymous

    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.

    • 3 weeks ago
      Anonymous

      Can't imagine a situation where locking a computer and waking it with joystick is mission critical. Fixed.

    • 3 weeks ago
      Anonymous

      This is a GNOME problem. KDE and Sway do not have this problem on Wayland.

  15. 3 weeks ago
    Anonymous

    why did canonical have to kill unity again?

  16. 3 weeks ago
    Anonymous

    Haven't used this trash since they ruined it with gnome3

  17. 3 weeks ago
    Anonymous

    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.

    • 3 weeks ago
      Anonymous

      >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?

      • 3 weeks ago
        Anonymous

        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.

        • 3 weeks ago
          Anonymous

          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.

        • 3 weeks ago
          Anonymous

          >untrusted applications
          care to name such applications instead of talking constant shit and creating boogiman out of nothing?

          • 3 weeks ago
            Anonymous

            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.

  18. 3 weeks ago
    Anonymous

    you activated my trap card!

  19. 3 weeks ago
    Anonymous

    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.

  20. 3 weeks ago
    Anonymous

    what the frick kind off mental gymnastics is this

    • 3 weeks ago
      Anonymous

      CLOSED WONTFIX

    • 3 weeks ago
      Anonymous

      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.

      • 3 weeks ago
        Anonymous

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

  21. 3 weeks ago
    Anonymous

    >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????

    • 3 weeks ago
      Anonymous

      >enabled lockscreen can simply be "disabled" by a random app
      lmao

      • 3 weeks ago
        Anonymous

        a "random app" can also steal all your keystrokes
        just a bunch of moronic gnome hater in this thread
        Sad!

  22. 3 weeks ago
    Anonymous

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

    • 3 weeks ago
      Anonymous

      >GNOME problem = linux problem
      the mutt's law of IQfy

      • 3 weeks ago
        Anonymous

        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.

    • 3 weeks ago
      Anonymous

      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.

  23. 3 weeks ago
    Anonymous

    If you want to lock your system just press Ctrl Alt F2.

  24. 3 weeks ago
    Anonymous

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

  25. 3 weeks ago
    Anonymous

    B...But muh Wayland security! I bet its much worse on X11 !!1!

    • 3 weeks ago
      Anonymous

      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.

  26. 3 weeks ago
    Anonymous

    just kill x and logout from tty. if you need something daemonized use t-mux

  27. 3 weeks ago
    Anonymous

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

  28. 3 weeks ago
    Anonymous

    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.

  29. 3 weeks ago
    Anonymous

    >lockscreen
    Physical access is root access.

  30. 3 weeks ago
    Anonymous
  31. 3 weeks ago
    Anonymous

    [...]

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

    • 3 weeks ago
      Anonymous

      Most of us don't want or need a fricking sandbox or non-free software.

      Please frick off.

  32. 3 weeks ago
    Anonymous

    >be re/dditor
    >hates IQfy and IQfyners
    >one day gets his thread closed
    >come to IQfy crying

    many such cases!

  33. 3 weeks ago
    Anonymous

    >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

  34. 3 weeks ago
    Anonymous

    is this the power of le most secure operating system?

  35. 3 weeks ago
    Anonymous

    So I can use that controller to unlock gnome machines?
    Sweet!

  36. 3 weeks ago
    Anonymous

    Linux security is a joke, has always been a joke, and will likely remain a joke.

  37. 3 weeks ago
    Anonymous

    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.

    • 3 weeks ago
      Anonymous

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

  38. 3 weeks ago
    Anonymous

    >muh wayland muh security!!!1
    >btw your application can just run this dbus command to do whatever it wants
    lol lmao even

    • 3 weeks ago
      Anonymous

      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.

  39. 3 weeks ago
    Anonymous

    >Appears in: XORG & Wayland
    AHAHAHAHAHAHAHAHA

    WAYLAND
    >>>>>>>>>>

    [...]

    15 YEARS OF WASTED DEVELOPMENT

Your email address will not be published. Required fields are marked *