[X2Go-User] RHEL 7 beta

[Stefan Baur]

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