Am 19.03.2014 11:46, schrieb GZ Nianguan E.T.:
Yes there is indeed a chance of exploiting holes in codecs etc... but hows that any bigger issue than it is for EVERY user in the world that views video on their desktop anyway? This is certainly not a bigger concern on a netbooted stateless thin client than it would be on your average desktop setup, now is it?
It's less of an issue for the average Joe working on a stateless, netbooted ThinClient, yes. It is an issue for someone running Windows clients that are firewalled off completely (i.e. no NAT where outbound traffic is allowed, but really "no one gets in, no one gets out") from the internet and may only connect to an X2Go server for surfing the Internet. Because in that scenario, all untrusted code is executed on the X2Go server only. And you would break that by passing audio/video streams 1:1 to the client.
Sure... a transcoder can be thrown into "the mix" but that kind of goes a against the basic core idea of being gentle with the server side resources.
Well, it depends. I can imagine scenarios where you would happily invest in a more powerful server to do transcoding - when the transcoded data stream output is compressed that much that you can watch videos via a GSM or UMTS connection. That's actually something that's bugging me with our curent pulseaudio setup in X2Go - there is no way (or at least, nobody has ever come up with a plan or sample code) to compress audio depending on the available bandwidth.
But who is to say the transcoder would not be the actual target for attack..?
That's why I said adding a transcoder would lower the risk of an attack, but not completely remove it. An attack would have to be crafted especially for the transcoder.
Just simply always get the latest security updates for the stuff your running....
That's indeed something one should always do - but I have a bad feeling about Telekinesis in a "graphical firewall" scenario, since it allows for an additional attack vector. What isn't present cannot be exploited, you know.
In use cases with need for extreme security, you would probably not want to be trusting your "graphical firewall" client software either, to be running on your sensitive hardware.
Well, if you do need Internet access in such a scenario, running X2Go or any other open source solution for remotely accessing an Internet-allowed machine is your best bet. The smaller the client's code footprint, the better, though. (Easier to audit and less likely to contain errors.)
If your in possession of something that someone with resources really wants... and your targeted... you targeted... and your "graphical firewall" could turn into their entry point... be it X2Go, RDP, Citrix or VNC or what ever else...
Spear phishing is one thing, especially if the attacker knows what solution you're using. However, history has shown that exploits are almost always turned into easily-deployed "takeover" scripts that every script kiddie can use, and such an exploit would probably go right through a Telekinesis-enabled server and hit all the clients. Whereas without Telekinesis, it would damage the server only (which is in a DMZ, so things can't spread further).
Anyway, do not worry! You will not be forced to run Telekinesis or mTelePlayer... it will be a separate package you would need to explicitly install.
Good. Though I'd love to see improvements in Audio/Video transfer in X2Go that are compatible with a graphical firewall use of X2Go. A transcoder would be acceptable, I guess, if its code is small and clean enough.
That said, I do appreciate your efforts and I can see that a lot of X2Go users (who do not have the security needs my customers have) will be happy with your solution once it is released.
-Stefan