|
Message-ID: <542DB3E0.2060504@oracle.com> Date: Thu, 02 Oct 2014 13:21:52 -0700 From: Alan Coopersmith <alan.coopersmith@...cle.com> To: oss-security@...ts.openwall.com CC: Daniel Kahn Gillmor <dkg@...thhorseman.net>, cve-assign@...re.org, "X.Org Security Team" <xorg-security@...ts.x.org> Subject: Re: Re: gnome-shell lockscreen bypass with printscreen key On 10/ 2/14 10:34 AM, Daniel Kahn Gillmor wrote: > However, this still leaves gnome-shell users vulnerable to the next > gnome-shell crash while locked. it's fixing one crashing problem, but > not fixing the larger problem that a screenlocking program effectively > fails open when it fails. > > Is there a way to make a screenlocking program that is designed to fail > closed instead? Not easily in the current X11 architecture - as far as the X server knows the screen lock is just another program who happened to grab all input and open a full screen window - very much like some games do. When the connection from it closes (program exit or crash) then the X server just goes on about its business, handling the remaining clients as normal. There's been occasional discussion of some extension to do better here, but it's never been fleshed out. Fortunately, I believe this is one of the mistakes in X that the Wayland developers learned from and did better at. The best I know of a current X screenlock can do is to use separate processes and do as little as possible in the process that has grabbed the input devices, leaving all operations likely to cause crashes isolated in a process that won't open holes if it does crash. > fwiw, https://bugzilla.gnome.org/show_bug.cgi?id=737456#c5 raises an > interesting alternate approach to resolving the underlying problem: > > Not sure what crazy side effects that might have if any but ... > Jasper can we simply unmap all windows when we lock and map them on > unlock? > > I don't know enough about X11 to know if this proposal is sufficient to > protect the user from command execution after a gnome-shell crash, or > what the side effects would be. Generally I think you'd just have the window manager or compositor sitting on screen waiting for you to tell it to uniconify a window before you could execute commands in it, but I've never tried it to see how that works (and am not sure at all what happens if the process that crashed is also your window manager or compositor). -- -Alan Coopersmith- alan.coopersmith@...cle.com X.Org Security Response Team - xorg-security@...ts.x.org
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.