Migration of windows between displays
perry at coders.net
Fri Nov 12 01:59:15 EET 2004
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:
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
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.
More information about the xdg