[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
