| |||||||||||||
Excellent article, and a sugestionExcellent article, and a sugestionPosted Mar 7, 2012 18:05 UTC (Wed) by dgm (subscriber, #49227)Parent article: The life story of the XInput multitouch extension
The solution of sending touch events to all clients is just brilliant. There's a little caveat: there are applications that may want to prevent other applications from seeing what is being touched. Take for instance an on screen keybord or numpad, when entering a passeword. A solution for such cases would be to define "private" touch zones. Any touch initiated in such zones would be handled exclusively by that application.
(Log in to post comments)
Excellent article, and a sugestion Posted Mar 7, 2012 18:51 UTC (Wed) by cnd (subscriber, #50542) [Link]
You raise a valid point, but I don't know much about security. To be honest, security through X.org is problematic in many ways. Even if you restrict normal touch events, everyone can still get raw touch events.
I believe the "correct" solution is to use the XACE extension, but I'm not very familiar with it. However, I think most distros use the XAUTHORITY mechanism instead, to keep clients from even connecting to displays they shouldn't have access to. It's assumed that if some malicious software has access to your X server you've already failed.
Excellent article, and a sugestion Posted Mar 7, 2012 22:34 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> t's assumed that if some malicious software has access to your X server you've already failed.
This doesn't sound right.
Read literally, this means that if you run angry birds, you should expect that it can see your password as you type it into your screen saver, or when you type your root password into your package manager (or sudo authorization)
I think this is what is meant.
Excellent article, and a sugestion Posted Mar 7, 2012 22:42 UTC (Wed) by daniels (subscriber, #16193) [Link]
Yes, that's right.
Even if you plug what you'd think would be all the obvious holes, there's nothing to stop Angry Birds taking over your browser and hijacking everything. And your terminals. Especially if you're running it as your user, it's already compromised your entire session, for good, and realistically the only way around it is trashing your entire profile and starting anew.
Either that, or just not running apps you don't trust if security is a concern.
Excellent article, and a sugestion Posted Jun 7, 2012 10:27 UTC (Thu) by cheako (guest, #81350) [Link]
No,
X supports running remote applications, just like FireFox supports running JavaScript(Angry Birds). FireFox doesn't let Angry Birds take over your box, why should X be allowed to pass sensitive information to remotely connected clients? Keep in mind that you don't -necessary-(not at all, not ever) trust root on the remote host to be able to read all your passwords.
I know that it's not easy to be secure, even Browsers have had issues with loading some image files. Leaving doors like this open because "There are other security issues" is not acceptable! There are always other security issues and what kind of world do you think we'd have if that excuse worked. Sudo doesn't really need to verify passwords because we already know the user has logged in, network VPNs need to be encrypted but there is no point in verifying the data isn't forged because no one would have the key used to make an encrypted packet. I hope I've made my point, but I'll try and get a few examples more on topic. Email servers can forward the BCC header to every one, it'll be removed on the receiving end by the users MUA. Passwords can be saved along with there hashes, because no one could ever read the shadow file. Hmm, I'm still not happy with any of these. Ahh, SSH doesn't need to be encrypted because there is telnet. Self signed server certificates are just as good as any other because no one really knows what they have installed for trusted CA certs. I really like this last one, a lot.
Excellent article, and a sugestion Posted Mar 8, 2012 8:05 UTC (Thu) by epa (subscriber, #39769) [Link]
This is why ssh changed to not forward X11 by default - it is too hard to make secure. Hopefully Wayland will manage this better, so an app can't see events that weren't deliberately entered into its window.
Excellent article, and a sugestion Posted Jun 7, 2012 10:42 UTC (Thu) by cheako (guest, #81350) [Link]
That makes perfect seance, for SSH to give up exposing an X server by default. I like the Debian Philosophy of binding all servers to the loopback by default. It just makes seance to start with a secure configuration and then let the users loosen security to fit there needs.
However having the default be insecure as this proposal suggests is not the way Linux development should be done. There are a number of applications that should make use of the 'lock keyboard on me' feature to prevent keyloggers, yes prevent keyloggers from getting password and not prevent keyloggers from being run in the first place. They say an ounce of prevention is worth a pound of cure, but simply not having a cure at all because absolute prevention is the better. It sounds wrong, because it is wrong.
If you work hard to prevent keyloggers from being able to log anything useful, then it makes keyloggers useless. If keyloggers are useless then you'll find there are less ppl using keyloggers. Thus your cure becomes your prevention, it's true that a good defense is a great offense. Make multi-touch vary offensive to any application that attempts to collect sensitive information. On the defensive side the user will do there best to make sure applications like that don't connect to the X server. If you don't do your part the team as a whole will suffer.
Excellent article, and a sugestion Posted Jun 7, 2012 10:46 UTC (Thu) by cheako (guest, #81350) [Link]
What I really wanted to say is.
No, that's not why. SSH doesn't expose the local X server to remote systems by default because it's more secure to have this feature disabled unless the user has specific need for it. Not because X is inherently insecure, if anything an SSH client that did not do this would be insecure.
Excellent article, and a sugestion Posted Mar 8, 2012 22:01 UTC (Thu) by dpquigl (subscriber, #52852) [Link]
The correct solution would be XACE. Eamon Walsh worked on XACE and the SELinux module for it and had an impressive demo of a multi-level desktop where an unclassified process couldn't screen scrape or gather input intended for secret and top secret x applications (this can also be used for normal type enforcement examples as well). The problem with this though is that most X frameworks are not written to handle permission failures. So several applications had to be modified to survive permission denials in the event that they did something wrong.
Excellent article, and a sugestion Posted Mar 7, 2012 21:50 UTC (Wed) by mhelsley (subscriber, #11324) [Link]
"A solution for such cases would be to define "private" touch zones. Any touch initiated in such zones would be handled exclusively by that application."
Sounds fine for a touchscreen but it doesn't make as much sense on a touchpad where even a small "private" zone would be a poor use of the small area. I think something similar to a keyboard grab -- except for touch input -- might be suitable for the latter. Yet keyboard grabs can be quite annoying if/when applications fail to release them. So I'm not sure what else could reasonably be done to handle the need for "private" input.
Excellent article, and a sugestion Posted Mar 8, 2012 7:56 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
mhelsley wrote:
> "A solution for such cases would be to define "private" touch zones. Any touch initiated in such zones would be handled exclusively by that application."
> Sounds fine for a touchscreen but it doesn't make as much sense on a touchpad where even a small "private" zone would be a poor use of the small area.
I realise that this train has left, but what is the reason for handling touch screens and touch pads the same? I would naively assume that all touch pad gestures would automatically go to the currently focussed window.
Excellent article, and a sugestion Posted Mar 8, 2012 10:25 UTC (Thu) by daniels (subscriber, #16193) [Link]
Yes, this is exactly what the X multitouch support does.
Excellent article, and a sugestion Posted Jun 7, 2012 10:58 UTC (Thu) by cheako (guest, #81350) [Link]
I think there is a misunderstanding here. I believe that michaeljt is indicating that _only touch pad_ gestures would automatically go to the currently focused window. While it's clear to me that with a touch screen one can interface with any window the user touches.
Thus we are convinced that touch screens and touch pads will have diverging code paths and it would be possible to implement a fix or feature in one with out effecting the other at all.
Thus the solution is to have private zones for a touch screen and use the existing key board locking for a touch pad.
Excellent article, and a sugestion Posted Jun 7, 2012 10:52 UTC (Thu) by cheako (guest, #81350) [Link]
I like the concept of keyboard grab, however there are currently(IMHO) too many cases where applications should use this and don't.
Another solution is needed, not that I have any ideas. I'm just saying that the current situation is not perfect and if we have the chance we should make things better.
Excellent article, and a sugestion Posted Mar 7, 2012 22:12 UTC (Wed) by daniels (subscriber, #16193) [Link]
The problem is that this would preclude any global gestures from taking place anywhere inside your keypad at all, which would be really jarring. If you're allowing untrusted clients to connect and do arbitrary things to your display, then it's just as easy for one of them to pretend to be your keyboard/numpad and sniff your password. Or just cut out the middle man and impersonate your browser.
So what you've suggested doesn't really help in any meaningful way, but imposes a significant usability cost.
Excellent article, and a sugestion Posted Mar 7, 2012 22:27 UTC (Wed) by josh (subscriber, #17465) [Link]
Whenever the onscreen keyboard gets a gesture it doesn't want to handle, it could cause that gesture to get forwarded to the rest of the system; only touch inputs that actually typed on the keyboard would get hidden from the rest of the system.
Excellent article, and a sugestion Posted Mar 7, 2012 22:38 UTC (Wed) by daniels (subscriber, #16193) [Link]
This inverts the order from the rest of the system, where the window manager makes the decision on whether or not to forward to the event to the app. This is particularly problematic for cases where, for instance, you have a three-finger swipe to bring up an Exposé-style app overview. Now, if you do a three-finger swipe with two fingers over your browser and one over your keypad, the keypad has swallowed the gesture as regular movement/drag, and you've given the browser a two-finger scroll.
And even all this still doesn't solve any of the security problems. The long and short of it is that if you give untrusted clients complete access to your X server, then you cannot -- cannot -- win in any way.
Excellent article, and a sugestion Posted Jun 7, 2012 11:07 UTC (Thu) by cheako (guest, #81350) [Link]
Life is hard, it's over when you give up. I like little nuggets like this, they really say something instead of me trying to convey some technical theory.
I don't believe any system is totally secure. I know that a lock on a door can be picked easily. This doesn't stop me from locking my front door every time I leave. Just because something is hard, just because something is challenging and most importantly when something is impossible. Are you just going to give up and let the rest of your life amount to nothing?
That's fine by me, but don't take others with you when you go. If you'r going to write the application equivalent of a poisoned punch(even if it's only fatal vary rarely and even then only for stupid ppl), do go giving it out at a party... That's not cool!
Excellent article, and a sugestion Posted Mar 8, 2012 7:58 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
daniels wrote:
> The problem is that this would preclude any global gestures from taking place anywhere inside your keypad at all, which would be really jarring.
Daniel, sorry for the really stupid question (never used multi-touch) but what is an example of a global gesture in a touch screen/multi-application context?
Excellent article, and a sugestion Posted Mar 8, 2012 9:22 UTC (Thu) by daniels (subscriber, #16193) [Link]
The most obvious example I can think of is using three or four-finger swipes to switch workspace, or bring up the app/window overview.
Excellent article, and a sugestion Posted Mar 8, 2012 3:19 UTC (Thu) by russell (subscriber, #10458) [Link]
Instead of private zones, which won't work for touchpads. Wouldn't it be better to use an active grab. This give exclusive access to the events. Passive grabs only receive events when no active grab is present. Hope I read that right.
Excellent article, and a sugestion Posted Mar 8, 2012 9:45 UTC (Thu) by dgm (subscriber, #49227) [Link]
Active grabs are problematic when applications hang.
Let me explain a bit more my idea: A "private" zone would correspond to parts of the client window. Clients should only allowed to request such zones on the windows they own. Because of that, this would really not apply to touch pads, as they are "relative" input devices and do not map directly to screen coordinates.
The utility of a private zone would be to capture touch events (not gestures) initiating in those zones. Touch events initiated elsewhere should not be affected, even when crossing private zones. Of course, an application should not be allowed to "privatize" the whole screen (even if shown full screen).
|
|||||||||||||