(CC'ing the parti-discuss list, which is probably more appropriate)
On Mon, Apr 14, 2008 at 10:04:31PM +0100, Mark Seaborn wrote:
> I've just come across your xpra program (it was mentioned on the xorg
> list). It could be just what I have been looking for: I have been
> investigating ways of running X clients securely, so that they cannot
> interfere with other clients, do keypress injection and so on (see
> http://plash.beasts.org/wiki/X11Security for some background). The
> idea of forwarding screen contents from another X server using (I
> presume) the X damage extension is not one that occurred to me.
Right -- it runs clients against a headless Xvfb, and then uses
Composite and Damage and XTest to proxy them. The clever hack part of
this is that it lets us effectively virtualize and proxy X connections
but in a really low-implementation-cost way -- we let X.org take care
of all the nasty X server implementation stuff, and then use a small
and simple protocol ourselves.
I didn't make the connection to the POLA gui problem either, but now
that you mention it it's an obvious point! All interaction with the
user's real X server is performed by a small and simple client
application (~400 lines of python) that doesn't know how to initiate
a grab, create a passive grab, steal focus, or other such antisocial
behaviors. The main issues I can think of would be:
-- Clients can still pop up arbitrary override-redirect windows,
including ones that completely cover the desktop.
Override-redirect windows never get keyboard focus, but they can
steal mouse events (and keyboard modifier state, since X mouse
events include that). They can't paint an image of the real
desktop on the override-redirect window, though (because they
don't have enough access to take a screenshot), which reduces the
effects of this.
-- Multiple clients running through the same xpra also share a
single Xvfb, and thus can interfere with each other.
Theoretically this isn't much of an issue -- you probably want
separate proxy processes *anyway* for serving multiple clients,
to reduce the chance of bugs -- but the need to manage multiple
such processes makes UI trickier, and wastes resources. (E.g.,
each Xvfb allocates a full frame-buffer, which is not actually
used.) Probably not the main worries at this stage in the game.
-- Generally, maintaining synchronization between the state
displayed by the xpra client to the user and the state actually
existing on the Xvfb is very tricky. For instance, if xpra is
wrong about which Xvfb client has focus, then keystrokes directed
into one proxy window might go to another underlying window.
That per se is not really a problem (it's really just an instance
of the previous problem), but there is lots of state in X and
the same problem could arise in many different guises. Of
course, xpra tries hard to be robust against such issues, but
there is always the potential for bugs, and in general when
writing security software, an architecture that allows
desynchronization of real state and displayed state is one that I
would want to examine very carefully.
-- Nathaniel
--
Electrons find their paths in subtle ways.
_______________________________________________
Parti-discuss mailing list
[email protected]
http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
