ThinLinX Support > ThinLinX Help Desk > Knowledgebase

Search help:

How secure is TLXOS? / TLXOS design overview


It's difficult to answer a generic question about TLXOS "lockdown", because this is a vague term that means different things to different customers.  We have conflicting requirements from customers that want TLXOS to be secured in specific ways, both amongst themselves and compared with customers who want the opposite - maximum convenience and mimimal security.  We can't make everyone happy.

TLXOS RPi is based on Debian (currently version 10, Buster), except for TLXOS RPi IoT, which is based on Raspbian (because Debian doesn't support ARMHF on < ARMv7, which is why Raspbian was created).  Except for AUFS layering - which requires use of a custom kernel - it is a fairly conventional deployment of Debian, with the addition of a few proprietary C binaries and shell scripts to apply settings provided via the TMS management application or the more limited offline configuration utility (Tlxconfig).  The selection of Debian packages that we use is very minimal, without anything resembling a fully functional local desktop (we use the xfwm4 window manager from XFCE, but there is nothing like a full XFCE desktop, let alone Gnome or KDE), or development tools/libraries of any sort.  You can, however, install additional Debian packages in the normal way once you gain root access (but such modifications will not be preserved when you upgrade TLXOS or reset to default settings).

TLXOS uses a three-layer union filesystem model based on AUFS.  The root filesystem is virtual, an amalgam of three separate layers.   The lowest layer of the stack (/actualroot, a compressed Reiser4 filesystem) is the read-only TLXOS "firmware" deployed by our upgrade packages.  This is the known-good state to which you will be reset if you use Reset to Factory Defaults in TMS/Tlxconfig.  In practice it isn't inherently read-only (like, for example, SquashFS), but in future it might be.  Above the base firmware layer is a persistent modification layer (/config, an ext3 filesystem), in which changes to the base firmware state are recorded.  This filesystem gets wiped when you reset to factory defaults.  The highest layer of the stack is a ramdisk (/run/overlay, a tmpfs filesystem) in which changes to the current session only are recorded.  Contents of the top layer are merged down into the middle layer when the device is shut down gracefully.  In the event of ungraceful shutdown, those changes are simply lost, resetting you to the last known-good state (base layer plus middle layer) when you power on again.  The main reasons for this layered filesystem model are (i) minimization of flash wear when using flash-based storage (e.g. the SD card in the Raspberry Pi case) and (ii) assurance - or as near as we can get to assurance - of a known-good state in the event of power loss.  TLXOS firmware downloads are encrypted in order to ensure their integrity.

TLXOS is intended to be as stateless as possible.  Unlike many other commercial thin clients, it uses privilege separation - applications are run as an unprivileged user (tlx), not as root.  The local user exists only for this purpose and does not correspond to any real-world person - TLXOS is never domain joined, and you do not "log on" to it.  For this reason, local logs contain very little meaningful information, and are not retained; they are discarded upon shutdown.  You can download select logs via TMS, but this is intended for diagnostic purposes, not auditing.  With the exception of the local web browser, little or no remote data is stored locally on TLXOS.  The web browser - Chromium, the free version of Google Chrome, with excellent sandboxing - can be put in "kiosk mode" to disable local data caching (see below).

Also unlike most other commercial thin clients, all accounts on TLXOS - including root - are "locked" in the Linux sense, i.e. do not have passwords that can be used to log on (unless someone goes out of their way to gain root access and add them, of course).  Root access to the device can only be achieved by means of SSH public key trust.  TMS provides administrators with the ability to upload SSH public keys to /root/.ssh/authorized_keys.

Because you cannot su/sudo to a root shell from the tlx user, we have not attempted to prevent the operator from getting access to an interactive shell.  We consider such attempts to be pretty futile, there are just too many ways for an intelligent person to exploit applications to get shell access.  By default, users can start a terminal window (xterm) using the <ctrl-alt-t> keyboard shortcut, but this can optionally be restricted by setting a Restricted Feature password (which also restricts access to the local configuration utility) to at least make it difficult for users to launch a graphical window in which to run a shell.

By default, TLXOS operates an iptables firewall, but this can be disabled via TMS should you wish to do so.  The inbound ruleset is very minimal, and the historically the only complaint we have had about it is that it superficially appears to allow rsh access.  In practice this is not actually rsh, it is a very restrictive subset of it intended for remote triggering of authoirized applications only.  We later turned this service off by default and added a TMS option to turn it back on again, since convincing relatively non-technical corporate ICT security staff that rrsh does not have the vulnerabilities of rsh is often difficult.

TLXOS attempts to use SSL encryption (specifically, TLS 1.1 or greater) wherever possible, including connection to the management server.  However, it's not practical for us to force strict SSL server verification in all situations due to widespread use of self-signed certificates and frequent lack of understanding of how SSL works by end users (and some system administrators!).

TLXOS includes a session shadowing (VNC) feature as standard, but we ensure that this is SSL encrypted and manually initiated from the client end (reverse VNC) such that operator consent is implicit.  Due to customer demand, we also added a simpler unencrypted VNC server that operates in the conventional direction without operator consent (but with an optional password), which the customer may activate at their own risk.

In the interests of full disclosure, TLXOS does not store TMS/Tlxconfig-provided passwords securely.  With the exception of the Tlxconfig access password, which uses a non-reversible hash, passwords are only Base64 encoded, and are present in environment variables and files accessible to the unprivileged tlx user.  We can't do any better than this because (a) password hashes have to be reversible, since they have to be passed to local applications (running unprivileged) in the clear, and (b) anyone with shell access (which we really can't prevent) or offline access to root filesystem data (which we can't prevent either) can with trivial ease look at our shell scripts and determine the means by which any reversible hash is decrypted.  For this reason, we recommend against using the "auto login" feature if you have any concerns about possible unauthorized physical access to thin clients.

TLXOS has some support for operation as a kiosk terminal, depending on which application mode you put it in.  Access to the local configuration tool, Tlxconfig, can be password protected.   When the mode-specific kiosk mode sub-option is selected, we attempt to disable app-specific features that would allow the user to exit from a fullscreen application session, or to reconfigure that application on the fly, with varying degrees of success.  We don't limit access to resetting to defaults (via keyboard shortcut), because it removes any recourse to recover a "damaged" system other than reinstalling it.  However, as of TMS 8.1.0, you can configure a client to reset to administrator-defined defaults rather than ThinLinX ("factory") defaults.

In future, we will try to add additional functionality to our management application (TMS) to tailor TLXOS "lockdown", but at present, with the management application available for free and TLXOS at very low cost, we simply do not have the resources to do this quickly.  Eventually we will add the concept of a policy for a group of machines, controlling not only their configuration but also firmware level, installed hotfixes, and so forth.  If we ever have the resources to do so, we may consider extending TMS to function as a multi-user application with delegated administrative privilege and permissions on individual configuration options, but at present this is not realistically achievable.


Related articles What is TLXOS? Is it Linux? What parts of it are proprietary?
How can I reconfigure TLXOS while an app is running / what are the keyboard shortcuts?
Can I install additional software on TLXOS?
Changing system language / correcting RDP keyboard layout
Running multiple fullscreen desktops/applications
Article details
Article ID: 39
Category: Frequently Asked Questions
Date added: 2019-06-09 05:20:16
Views: 891

« Go back