"This is a feature of a single displayed instance of X." Running another instance of X would provide a level of isolation. That was obvious. From what I've read in the mailing list it appears that wayland addresses this issue. But yet to see wayland in action. Regards, Julian. On 23/10/12 08:54, Trent W. Buck wrote:
Julian writes:
Do I trust any and all of the x applications I run? Thanks for the software, but I don't sorry. Don't run software you don't trust.
Xinput logs absolutely everything, anywhere. Regardless. Even an X application that opens as a different user (xauth). Don't grant xauth privileges to users/hosts/networks you don't trust.
https://en.wikipedia.org/wiki/X_Window_authorization
By default a typical X session is set up to only allow a local user (and local root) to connect to the X server. Of course, if the attacker has physical access you are probably fucked.
Remember this has nothing to do with xauth or xhost. This is a feature of a single displayed instance of X. Login to your bank, paypal, su as root, whatever and hope xeyes isn't logging your keystokes or run xinput and watch it for yourself. When I log into my bank, it is like this:
xinit -- /usr/bin/midori bank.example.net
That is, X starts, runs nothing but the browser, and when I quit the browser, X stops as well. So I am reasonably confident that information isn't leaking out -- unless a rogue process is already running as me and can therefore find the cookie file and connect to the server.
Russel's idea of using nested X servers is probably equally sufficient. If, unlike me, you were already running X, I think you say
xinit /usr/bin/X :1 -- ...
I also run this every fifteen minutes: http://cyber.com.au/~twb/.bin/twb-privacy
I would be interested to know how this issue compares to other common windowing systems. IIRC the only chord that cannot be intercepted by userland on Windows is Ctrl+Alt+Del...
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main