Migration of windows between displays

Jim Gettys Jim.Gettys at hp.com
Thu Nov 11 23:46:42 EET 2004


On Fri, 2004-11-12 at 10:19 +1300, Perry Lorier wrote:
> Jim Gettys wrote:
> > Phil Blundell has done this on the iPAQ (migrating from a small screen
> > to a workstation).
> 
> Neat!

IIRC, Phil may have written up what he did.

Phil, is my memory correct?

> 
> > The big issue is making sure applications can't be easily hijacked; some
> > sort of authentication mechanism is required to ensure that doesn't
> > happen.
> 
> What is the threat model here?  Presumably if they can write properties 
> onto a window the attacker can range from being a real nuisance 
> (minimizing windows etc), through to doing outright damage (eg sending 
> synthesized events to the window getting it to quit without saving, or 
> deleting files for example).  Is this the right level of abstraction to 
> place security?  If hostile users have access to the display then 
> perhaps there should be another X Extension that should deal with what 
> they can/can't do, perhaps providing ACL's per property if necessary?

Arguably, stealing entire application is more dangerous than sniffing
input events.

You are opening a big topic: the current XSecurity extension isn't
useful; Eamon Walsh started doing work in the spring to bring SELinux
style policies, but he's no longer available, and that work is
languishing (any volunteers).

In general, you need to do a couple things: 1) prevent hijacking of an
application, at least if you want to start thinking about shared use
displays (thing of projector systems, where you may be wanting to share
the use of the display with a friend). 2) you need to tell an
application where to go, and may need to be able to pass in
authentication tokens to enable the connection.

> 
> I must admit I don't really understand X's internal security mechanisms 
> other than I need a magic cookie to connect to a display, and newer 
> versions of ssh have some kind of "insecure x forwarding" mode that 
> seems to break some applications.

Yeah, the SSH folks have tried to use XSecurity, which is broken.

> 
> What kind of security is necessary?  If not everyone who has permission 
> to access the display doesn't have the necessary permission to ask an 
> application to move displays, who does?  Is strong crypto necessary (can 
> the wire be sniffed/MiTM?) or even usable? (do IPaq's have enough 
> processing power to not introduce heaps of latency when moving large 
> numbers of windows around?) is a simple cookie instead appropriate?

Cookies may be sufficient. Compute isn't an issue (low end of a PDA
these days is 200mhz).

> 
> > So yes, we need a standard in this area, and we also need to worry about
> > the security consequences.
> > 
> > There is other implementation work to fully flesh out this vision:
> > 	a) right now, gtk can't quite remove itself entirely from the
> > 	   display; some more work is needed there.
> 
> Hmm, irritating :)  Maybe I'll have to start looking deeper into how gtk 
> works.

Owen can tell you what needs doing.

> 
> > 	b) Xlib needs some work to allow applications to be notified if
> > 	   their display connection fails.  I did some work here a year
> > 	   ago, but haven't had time to complete it since, due to all
> > 	   the XFree86/X.org upheavals and subsequent transition.
> 
> and maybe xlib too :)  (I was so hoping to avoid learning how xlib works :)

Well, I was doomed...  The work I started a year ago was against the
current (antique) Xlib code base I started 20 years ago. At this date,
Xcb may be far enough along it might make more sense to do there,
and it is much cleaner in the transport area.  I dunno if I'll have time
to pick this up anytime soon or not, though my motivation will go way up
if people are working on the other parts of the problem.  It isn't all
that hard to do, particularly if we don't have to deal with the old Xlib
code base, which is pretty ugly in the transport side, particularly due
to its retrofit for threading.

> 
> > 	c) we need to deal with the security issues that this
> > 	   capability raises.
> 
> See above :)






More information about the xdg mailing list