Chromium

From Stratodesk Knowledge Base
Jump to: navigation, search

Stratodesk makes sure NoTouch has latest versions of the Chromium web browser integrated. People use the Chromium for example to:

  • access web-based enterprise applications, exclusively or next to VDI connections
  • build a web kiosk system with custom hardware and Stratodesk NoTouch
  • connect to Citrix or other VDI connections that use the browser as frontend.

Using a web browser can compromise your IT security. We want to make you aware of the dangers before you use Chromium - please read the section on #Security considerations. Depending on your security requirements, organisation size and culture and trust in your end users we may even advise you to not use Chromium at all!

As a side note, if you don't like Chromium, you can alternatively use Mozilla Firefox.

Basic configuration

This assumes you are familiar with configuring NoTouch locally or via NoTouch Center and especially how server connections are created and configured. Making your endpoint start a Chromium web browser is easy and requires only two steps:

  1. Create a connection and set the connection mode to "Chromium"
  2. If, and only if you want to start the browser start with a specific URL, such as your company web page, type that URL into the "Connection target" parameter.
  3. Bookmarks, if you want to load multiple bookmarks. The parameter in Connections is comma separated (http://stratodesk.com,http://straodesk.com/kb)

This is enough to get a Browser setup - it's really that easy. From there you can of course change many different options. For instance, you can configure the client to come up automatically after boot time; and you can modify all Chromium options (submenu Chromium web browser) under the Connection options. See below for the configuration possibilities.

Important note: In the default configuration, Chromium is not allowed to do a lot, it can not even access the sound/audio device. Please set the "Force execution as root" parameter to on in the Connection settings and read below about the implications.

Write protection

By default, all writes done by the web browser, such as changing preferences inside Chromium, saving bookmarks, cookies, web cache etc. are all written to the local RAM disk. When closing Chromium and restarting later, all these modifications will be gone. A reboot will clear out even downloaded files. This makes NoTouch a great web kiosk system by default. This behavior can be modified as well as other aspects of the system.

Security considerations

With VDI connections, such as RDP, Citrix, VMware etc. almost no interaction happens between applications inside the user desktop and NoTouch. Running a local browser is different, it is indeed a local application executing code locally! Chromium allows your users to download Linux applications, configuration files, thus modifying the system, install malware, spyware, keyloggers. Yes, typical Windows malware like Win32 code will not work, so most standard attacks fail but you can not rely on that.

In a nutshell, we strongly suggest to put filtering proxy servers in place or otherwise confine Chromium to, say, a Citrix web portal, or similar. (see #URL-based_lockdown_scenarios)

NoTouch has several mechanisms in place to prevent permanent changes made by the user or a malicious software loaded by the user. These mechanisms are not unbreakable, but they provide reasonable protection against common attacks. There are two potential attack scenarios:

  • A local, malicious user with physical access to the machine may outsmart the Linux security mechanisms since Chromium offers more interaction with the system than a regular VDI client
  • A local user could open a prepared website that exploits a Chromium security vulnerability which in turn allows to

Both attacks could lead to keyloggers being installed (remember, there are no user documents to be stolen on the Thin Client, so the most valuable asset are probably user's keystrokes).

To mitigate the risks as much as possible, we suggest:

  • Make sure the "Force execution as root" parameter under Connection->Extended is "off".
  • Public stations, such as reception-floor info terminals, should be placed in a separate subnet with filtered Internet or server connectivity but no access to the corporate network and reinstalled regularly or even PXE-booted.
  • Corporate stations, such as for end users allowed to use the Internet, should be placed behind a filtering proxy server (as should any Windows PCs anyway). If PCs can be accessed by other users (e.g. unlocked cubicles) a certain rest risk can not be eliminated (like on Windows PCs actually).