Restricting access to ThinLinc servers

In some cases it might be desirable or required to restrict the users’ access to the ThinLinc servers and their ability to move data in and out of the system. This chapter describes some ways this can be achieved, as well as the consequences of such restrictions.

Disabling SSH access

The system’s SSH server often includes a lot of functionality for accessing the system. Completely disabling this service is a quick way to restrict most of the external access to the system. However the native ThinLinc client requires SSH to function so users will be limited to only using the web client ThinLinc Web Access.

Many SSH servers also support limiting access to just certain users. OpenSSH has settings such as AllowGroups and Match that can limit functionality without completely disabling the SSH server.

Disabling shell access

User sessions are normally started via the user’s configured shell, so restricting the shell is a good method to restrict what kind of sessions the user can start. Primarily, this is useful to prevent users from running custom commands via SSH.

Changing the configured shell

Commonly the user’s shell is configured to /bin/false in order to disable shell access. Unfortunately this also prevents access to ThinLinc as it needs to run the commands thinlinc-login and /opt/thinlinc/etc/xsession via the user’s shell. As an alternative it is possible to configure /usr/bin/thinlinc-login as the shell. This will allow ThinLinc to function whilst preventing any other type of session.

Note that this method prevents any terminals inside the session from functioning as well. In most cases it also does not prevent users from running custom scripts and shell commands as they can use a text editor to construct such scripts.

Using ForceCommand

OpenSSH has the ability to ignore the user’s configured shell and run a different command instead. This makes it possible to keep a normal shell for the user and only restrict access when connecting via SSH. However this prevents the native ThinLinc client from connecting as it needs to be able to run the command thinlinc-login with specific arguments. The following script can be specified as ForceCommand to allow only ThinLinc access via SSH:

#!/bin/bash
thinlinc-login -c "${SSH_ORIGINAL_COMMAND}"

It is also possible to apply this restriction only to a subset of users by using the Match setting. Please see OpenSSH’s documentation for how to configure this mechanism.

Disabling port forwarding

ThinLinc relies on SSH port forwarding in order to function. However it is possible to limit that port forwarding in order to avoid unwanted network access. ThinLinc only requires forwarding via the loopback interface, so the SSH server can always be configured to only allow this without limiting ThinLinc in any way. For OpenSSH this is configured by specifying the following in sshd_config:

GatewayPorts no
PermitOpen 127.0.0.1:*

Note that it is also necessary to disable shell access in order to completely prevent users from forwarding ports as otherwise they could run their own forwarding software over the shell channel.

Disabling remote port forwarding

It is possible to use ThinLinc with remote port forwarding completely disabled. However this will prevent local devices such as sound, drives and printers from functioning. In OpenSSH this is configured by adding the following to /etc/ssh/sshd_config:

AllowTcpForwarding local

It is also possible to apply this restriction only to a subset of users by using the Match setting. Please see OpenSSH’s documentation for how to configure this mechanism.

Note

Local port forwarding cannot be disabled as it is required for even the basic ThinLinc functionality.

Disabling clipboard

It is possible to disable clipboard transfers in either direction in order to avoid easily moving data to and from the server. The first step is adding -noclipboard to the ThinLinc setting /vsmagent/xserver_args. This prevents the user from later changing the clipboard settings. Next add -AcceptCutText=0 to disable clipboard transfers going to the server, and -SendCutText=0 to prevent transfers going from the server.

Disabling local drives

ThinLinc local drives redirection relies on being able to ask the kernel to mount a NFS share. This is a privileged operation that only root is permitted to perform, and as such this feature requires a setuid helper binary. This helper is called /opt/thinlinc/libexec/tl-mount-personal and the setuid permission can be removed by running the follow:

$ sudo chmod u-s /opt/thinlinc/libexec/tl-mount-personal

Note that this only disables the ability to use the kernel NFS client. If a user can start some other NFS client then they can still access the local drive redirection. The setuid permission is also restored each time ThinLinc is upgraded.

Restricting write access to users’ home directories

When accessing directories from CIFS and NCP servers, these are mounted in subdirectories of the users’ Linux home directory. It is not possible to place the Linux home directory on a CIFS or NCP server, since these typically do not support the necessary POSIX file system semantics (such as hard links). In a typical setup, applications such as Mozilla uses the Linux home directory for settings (~/.mozilla), while the user saves documents in ~/MyDocuments. In this case, it might be desirable to restrict access to the Linux home directory: Forbid saving arbitrary files to it. This can be solved by using a feature of ThinLinc called homecreatefilter.

To activate homecreatefilter, create a symbolic link in the xstartup.d directory:

$ sudo ln -s /opt/thinlinc/libexec/tl-homecreatefilter.sh \
   /opt/thinlinc/etc/xstartup.d/06-tl-homecreatefilter.sh

Configuration

The configuration file /opt/thinlinc/etc/homecreatefilter.conf controls which files and directories are allowed. By default, all files starting with a dot are allowed, as well as the files necessary for KDE to start.

The configuration file is line-based. A line not starting with a colon specifies a file object pattern that should be allowed. A line starting with a colon specifies a command line pattern. Processes matching this pattern will also be allowed write access, even if no file object pattern allows access.

Security considerations and limitations

The homecreatefilter feature is based on the LD_PRELOAD mechanism, which means it does not support statically linked applications. Since environment variables can be modified by the user, the user can disable the filter at will. homecreatefilter should not be regarded as a security mechanism, but rather a mechanism that prevents the user from saving documents to the Linux home directory by mistake.

In addition to the home directory, homecreatefilter restricts write access to the ~/Desktop directory.