GNOME Bugzilla – Bug 608539
screen locking is vulnerable to a SysRq attack
Last modified: 2015-03-05 20:16:44 UTC
As described in http://bugs.debian.org/564079 you can easily kill the gnome-screensaver process if the SysRq keys are authorized. This pretty much defeats the idea of locking the screen. Ths short-term solution is, of course, to disable the SysRq’s that can kill processes, but in the long term it would be better to make screen locking resilient to a loss of the controlling process. It’s annoying if you can’t get your session back because of a crash, but it’s much more annoying if someone else can get your session because of a vulnerability. This would probably require a new X11 extension to lock the screen on the server side. This way, it would not be possible to unlock it in any other way than an already connected X11 client.
Can you please summarize the issue here? The other bug may get locked or go away and it also has lots of noise. Thanks.
(Sorry for not replying earlier, I stopped receiving bugzilla emails 2 weeks ago because of a misconfiguration on my side.) There are situations in which you can trick the Linux OOM killer into reaping the gnome-screensaver process. Most cases are non-obvious, but the Alt-SysRq-F combination will kill what the kernel thinks is the active process. If at the same time you get gnome-screensaver to do something (e.g. by moving the mouse) you can kill it. Three solutions were proposed in this thread: - disable magic SysRq keys by default (and wait for people to re-enable them) - set /proc/self/oom_adj to -17 so that the process cannot be attacked by the OOM killer (a patch for this is coming) - a new X server extension that would lock the screen until an authenticated X client unlocks it - this has the advantage to work with anything that could possibly kill the gnome-screensaver process, but of course requires synchronisation with fd.o.
(In reply to comment #2) > - set /proc/self/oom_adj to -17 so that the process cannot be attacked by the > OOM killer (a patch for this is coming) Erm, the patch is not coming right now since it requires a setuid helper to do this /o\
This seems to me to be an issue of how a user has their system configured: not a GNOME bug. Requested features could assist.
(In reply to comment #4) > This seems to me to be an issue of how a user has their system configured: not > a GNOME bug. Requested features could assist. I think it is a bug for gnome-screensaver to be vulnerable to any kind of attack that kills the process. It turns any DoS attack into a privilege escalation one. It doesn’t mean we shouldn’t fix those attacks either, but it is a band-aid. Making screen locking resilient to a process crash would fix all such attacks at once.
The screen lock is implemented directly in gnome-shell, not in gnome-screensaver (as it was with older version of GNOME 3 and GNOME 2.x). Reassigning.
(In reply to comment #5) <snip> > Making screen locking resilient to a process crash would fix all such attacks > at once. I believe that was done in gnome-shell 3.9.2 (so 3.10 stable) in bug 691987. Can you confirm?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!
(In reply to Florian Müllner from comment #8) > Closing this bug report as no further information has been provided. Please > feel free to reopen this bug report if you can provide the information that > was asked for in a previous comment. > Thanks! What information is missing?
(In reply to James from comment #9) > What information is missing? Quoting Bastien in comment #7: > (In reply to comment #5) > <snip> > > Making screen locking resilient to a process crash would fix all such attacks > > at once. > > I believe that was done in gnome-shell 3.9.2 (so 3.10 stable) in bug 691987. > Can you confirm? So basically: gnome-shell will start locked when it crashed while locked, do you consider that good enough?