Re: X-windows security in Gnome

[Brian Cameron <Brian Cameron Sun COM>]

Jamie:

> > > If there are any iconified terminals around, arbitrary commands can be
> > > executed by sending synthetic keypress events to them.
> > 
> > This is simply not true.  I was hoping not to have to type in the
> > specifics of the "Security Extension Specifcation", but since there
> > seems to be so much confusion, I will go into more detail.
> 
> Ah, I had read that spec, but I interpreted it as saying that these
> things were only true when "secure mode" had been turned on, e.g., while
> reading a password, not all the time.  I get it now.

Cool.  Glad we are on the same wavelength.

> But rather than making sure this extension works properly on every X
> server, and then modifying those clients that need to take advantage of
> it explicitly, and then making sure that all users have upgraded to said
> versions of those clients, doesn't it seem a whole lot easier to just
> use a firewall and be done with it?  It does to me.  Everybody
> understands firewalls already.

I disagree.  While a firewall is an important feature in any secure
network, it is overly idealistic to assume that there are never hackers
inside a firewall.  

I disagree that using the X-Windows Security Extension is so cumbersome.
Programs which wish to be more secure (due to password entry for
example), just need to make the call to XSecurityGenerateAuthorization,
and this sets themselves up as a secure program.  Ideally the value
passed into XSecurityGenerateAutorization for the "protocol-name" could
be a configurable parameter, so that if a system has installed a more 
secure protocol than MIT-MAGIC-COOKIE, they can easily specify that
they wish to use this more advanced protocol.  And that's it!  Now no
other program can sniff that programs graphics or keyboard entry.
This seems a nice way to add a bit more security to x-windows programs.

While it is important to make sure that the Security extension works
properly on every X-server, I don't see that a bug with a particular
x-server is a good reason not to use the extension for those xservers
which do not have bugs.  Instead xservers with bugs in their
security extension should be identified & fixed.  While not every
user will feel that security is important enough to upgrade, some
will feel it is so important.  To support those users, making programs
that accept sensitive data (like passwords) support the X-windows
security extension seems to just make good sense.

Without this degree of security, a person can step over to your
machine sometime you have forgotten to lock it, and start a process
that sniffs keyboard entry a la "xspy" and logs your keyboard entry
to a file.  Then after you've typed your password into xscreensaver,
they have hacked your password.  Easy hack that is prevented by a 
simple call to XSecurityGenerateAuthorization.

> *No* machine can get TCP packets to my machine's X server.  When I run X
> apps remotely, they come in through ssh.  My X server could just as
> easily not listen to TCP connections at all: *every* connection to it,
> even ones from across the country, come in through domain sockets.

Without this degree of security, a person can step over to your
machine sometime you have forgotten to lock it, and start a process
that sniffs keyboard entry a la "xspy" and logs your keyboard entry
to a file.  Similarly they could set up a simple trojan horse to
trick you into running such a logging program.

Then after you've typed your password into xscreensaver, they have
hacked your password.  Easy hack that is prevented by a simple call
to XSecurityGenerateAuthorization.  

This is just an example of how the "xspy" bug can be used to hack
your password even if you do not use "xhost +".

> That doesn't address the issue of multi-user machines, of course, but to
> hijack a domain socket from another user, you have to have 0wned the
> file system, and if you've done that, you've already won anyway.

Brian