Chrome Remote Desktop for Linux
productforums.google.com
productforums.google.com
I love that Chrome automatically updates with security and performance updates. But an IT professional and someone who is security conscious, it's concerning that users' web browsers automatically install new attack vectors.
I'm sure the NSA, every other three letter agency, and skillful botnet programmers and hackers are just tickled that Chrome is opening up new avenues for infection.
Here's the how-to if you have some spare Google account credentials:
1. Install Chrome and sign in with target's credentials
2. Enable Chrome extension sync
3. Install Chrome remote access extension
4. Wait
5. ???
6. Profit!
Welp, at least Chrome for Windows has group policies to control (some) of this, but the policies often lag behind the new features. Chrome for Linux users? I guess they're SOL. Hope your company's administrators have init.d locked down or something to prevent Chrome from installing its hooks into your system during a regular apt-get/yum update.
Edited in P.S.: Google, are you there? Are you listening? As a system administrator, what would tickle me would be the ability to freeze the attack surface area of user's machines. i.e.: they can't install new extensions and apps, they won't have any features that add new remote access features enabled, etc. I would like to be able to say, "I trust my ability to lock down Google Chrome 37", configure that, and not have to worry about an automatic update annihilating my security policies.
Finally, automatic extension updates give me the creeps. At any moment, bam, suddenly my users' harmless extension is now owned by Shady Joe's Botnets 'R' Us, and their passwords, web traffic, and safety is compromised.
Obviously if they have your Google credentials you are in a world of trouble, and I have no doubt if a 3 letter agency wanted to infect me they could, but the scenario he brings up is still troublesome and not at all restricted to highly technical attackers.
I see what you are saying. But the help page basically describes the steps to install a chrome extension. It doesn't say that this extension is specifically prevented from syncing like other extensions. It mentions an authorization dialogue on first run, but it is unclear whether that is the first run per account or the first run per installation of the extension.
I would actually lean towards the latter, as it is in line with extension syncing behavior I have seen in the past. Usually when I am on a new setup of Chrome, and extensions sync and install, they do pop up some sort of installation or setup window notifying you.
So there may indeed be no issue at all.
To put it another way: if I am a regular end-user and Chrome pops up a dialog asking me to allow the official sounding "Google Remote Desktop App", then why wouldn't I? That doesn't sound scary at all - it's from Google!
I've used Chrome Remote Desktop, and the speculation in this thread about automatic extension sync is absolutely baseless: you need someone at the keyboard to actually install the remote desktop features, the extension by itself is not enough.
Is this really the state of HN discussion? It's great that a Google engineer was able to chime in and dispel the wild fears (thanks Sergey), but it shouldn't have been necessary in the first place.
sudo /etc/init.d/chrome-remote-desktop stop sudo /etc/init.d/chrome-remote-desktop start
You have to install chrome remote desktop on linux and start the service on the machine before you can connect to it elsewhere. I don't see how this is any different than any other remote desktop other than the client is built into chrome now.
Extension sync doesn't automatically enable remote access to your machine. User must explicitly enable access on each machine that needs to be accessible (and to do that the user must be administrator).
Also the remoting service needs to be installed separately from chrome - it's not part of the extension. It's not possible to package native binaries with chrome apps/extensions, by design (except for NPAPI plugins, but extensions with NPAPI plugins are not synced and NPAPI support is being removed from Chrome).
On Linux you can disable automatic update both chrome and CRD. Just set repo_reenable_on_distupgrade to false in /etc/default/google-chrome and /etc/default/chrome-remote-desktop
Now, I don't fault the hangouts team for encountering a bug -- but it's frustrating (perhaps doubly so for Debian/stable users) when something like hangouts stops working -- and that without there being any obvious reason (eg: new features, important fixes) for why something that used to work, suddenly stop working.
But there is still no way to control Chrome's surface area in the future, and features like this give me the heebie-jeebies. Two things:
1. Users that have already enable Chrome Remote Desktop don't need to authorize the set of computers that can access it remotely. You authorize one endpoint, but not the other. And since Chrome will occasionally install new extensions and apps in its regular updates, there's no notification for a lay user to know why they got "Chrome Remote Desktop". For that matter, anyone with access to a Google account can leverage one Chrome sync feature to gain access to others (mainly: from an extensions into completely owning their machine), allowing them to leverage Google account access into a much greater vulnerability on remote physical machines. Passwords, open tabs, history, form data, credit card information.
Let me walk you through this. Alice is using her computer at work. Eve has obtained Alice's credentials, and sets up a Chrome account on a machine and enables full sync, and installs the Chrome Remote Desktop extension on her computer.
Alice sees a new extension appear on her computer. Why is it there? Alice is never informed, and Google adds new apps and extensions with updates occasionally, so Alice proceeds to install Chrome Remote Desktop. Why not? Chrome seemed to think it was safe to put on her front page or in her app bar. Eve can pin it to her bookmark bar with a title like "Connect from home!", or even install multiple bookmarks to do this:
"Connect from home" "now today" "with Google Chrome" "Remote Desktop!"
Now it's just a matter of time. Eve could also use her access to the account to synchronize new extensions silently and in the background, allowing them to siphon off passwords and credit card numbers, even if Alice disallowed those items from synchronizing. Extensions are simply too powerful and the automatic update feature makes every extension from a third party developer a ticking time bomb.
2. You don't really offer a great way of blocking increases to the attack surface area of Chrome. You offer a way to totally turn off all Google Chrome automatic updates, but woe is the administrator that tries to use your policy tools to lock down Chrome. As Chrome is becoming an operating system unto itself, I find myself at a loss to understand why policies for this new operating system lag behind. Your suggestion doesn't prevent Chrome from automatically updating or synchronizing new extensions, and doesn't provide the average user with protection from a hijacked Chrome account. Disabling Chrome's automatic updates, if anything, makes them less secure.
No, what I want is the ability to lock Chrome's surface area to a particular version, not lock Chrome to the version itself. I want to see ways to limit my liability as an administrator to what I know and understand - and the Chrome team seems to think they know better than I do how to keep lay users safe. I disagree - given the fact that me, the security paranoid user, has already been bit by Chrome's security policies, I have no hope that they will avoid the same fate.
Moreover, your scenario presupposes that Eve has Alice's Google credentials. At that point, Alice is already owned. Given that most of a user's information is online instead of on a particular device these days, accessing Alice's desktop is not significantly useful. Eve can already pretend to be Alice and send trojans to her friends and then pretend to be Alice's friends and send trojans to her.
Signing into a target's Google Account won't give you full, unfettered access to their PCs that have the server explicitly installed on them; you must also have a PIN that must be entered before every remote desktop session.
Or perhaps Google could make sure that the PIN also requires a second two part authentication. I mean, the account should already be protected by that in theory, but if someone stumbles upon an active session and the PIN is lying around, at least they'll be stopped by the two part auth.
Even broader: any resolution you want. I genuinely have always wondered what is at the bottom of this problem. Why is it that on an otherwise so versatile and configurable OS it is seemingly so hard to change the resolution when logged in remotely? Is it something in X that makes it like that? Was it originally never meant for headless use? Having used, and cursed the fixed resolution of, VNC for years I still remember the first time I used rdp on Windows, my jaw was like on the floor. That is how it should be: logging in without being bound to a hardware screen, and in a seperate session (latter needs a fix though since the default client on non-server windows doesn't allow it)
[0] https://wiki.archlinux.org/index.php/xrandr#Using_xrandr_wit...
We have this implemented, but the problem is that the current version of Xvfb doesn't support randr extension. See https://bugs.freedesktop.org/show_bug.cgi?id=26391 . With the patch attached to that bug CRD should resize desktop automatically.
Just like all most Google products it looks like it requires both parties to be logged into their Google accounts, so concerns about Google's privacy policies are still valid with it.
PS. Does it use websockets?
1) Tried sudo dpkg -i chrome-remote-desktop_current_amd64.deb 2) It complained about missing dependencies. 3) I tried aptitude and one of its choices was to remove the Linux kernel, nah. 4) So I ran my trusty Synaptic and it immediately detected the broken package, I clicked Fix, Apply, and it worked fine.
It seems quite responsive.
Also it does initial connection handshaking so if you login to chrome from machine B and machine A is already set up for Chrome remote you can just connect there via a list of endpoints without having to know the external-facing IP address and/or setting up firewall tunneling.
Kind of crazy that this got released and we still don't have a Google Drive client for Linux.
Love it when linux gets cool tools like that.