Recent Features
| |||||||||||||
Excellent article, and a sugestionExcellent article, and a sugestionPosted Mar 7, 2012 18:51 UTC (Wed) by cnd (subscriber, #50542)In reply to: Excellent article, and a sugestion by dgm Parent article: The life story of the XInput multitouch extension
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.
(Log in to post comments)
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.
|
|||||||||||||