Migration of windows between displays

[Perry Lorier]

Phil Blundell wrote:

>On Fri, 2004-11-12 at 10:19 +1300, Perry Lorier wrote:
>  
>
>>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?
>>    
>>
>
>When I implemented this stuff for GPE, I had it use a public-key
>signature mechanism for authentication.  I don't remember all the
>details offhand, but the gist was that each "please migrate yourself to
>display <x>" request was signed with a private key, and the target
>application would verify the signature against a set of trusted public
>keys before acting on the message.  
>
I presume what you implemented is covered by this message here:
http://mail.gnome.org/archives/wm-spec-list/2003-March/msg00032.html

This specification will interoperate with mine, as I ignore everything 
after the first space as "for extensions purposes", your standard has 
the security data after the first space which I'd ignore.  A request 
from a client of my spec will be ignored by your high security apps, and 
all is fine in the world.

Your specification also has a success/failure reason notification, which 
I've left out of my specification (mostly because I don't understand the 
implications, and it appears to be something you could add to the 
standard later without breaking any applications).

If you absolutely need security, I'd suggest doing something based more 
on the display authentication system.  Display authentication has 
systems already set up for public key, magic cookies, des, or kerberos 
so you can be smarter about how things are authenticated.

Although I'm pretty naive about these things, I agree with Avery.  If 
you want security then doing it within the change display protocol is 
the wrong level of abstraction.  People can already sniff or synthesize 
events or do other nasty things.

>Both sets of keys are typically
>stored in files in $HOME.  So, in the simplest case, where the
>requesting application and the target application are both running in
>the same session, you get to manipulate your own applications without
>having to do any special setup and without anybody else being able to
>mess with them.
>  
>
That seems simple enough.  Is the xauth protocol(s) complicated enough 
to be able to shoehorn this in so that things like ssh will 
automatically copy keys for you?

>The code is in the GPE CVS tree if you want to look it over.  "teleport"
>is the requestor application, and "libdisplaymigration" is the receiving
>end.  Ultimately, you'd want to merge libdisplaymigration into GTK
>itself, so that applications didn't need to take any special measures in
>order to be migratable.
>
>  
>
Right, I've done something like this already with gtk.

>iPAQs generally have between 200MIPS and 400MIPS of computing power,
>which is plenty for this kind of thing.  We're only talking about
>encrypting and decrypting a few tens of bytes for each migration
>request.
>  
>
Heh, I'm used to using soekris boxes at my work which are embedded 486 
machines, sshing into them sometimes has quite a bit of latency while 
they are busy setting up the encryption parameters.