Question

SecureTransport offers the option to be installed to run as a non-root account. What are the benefits and implications of such a setup?

Resolution

Running SecureTransport as non-root adds improved security to your deployment. If a service gets compromised, the attacker would be confined by the OS to the limits of the user SecureTransport runs as, minimizing the damage potential of the attack.

For these restrictions to work, the OS will also impose them on SecureTransport services. The limitations include:

1. Not being able to passive open (listen on) ports lower than 1024

These ports are considered "privileged" or "reserved" in all POSIX (Unix and Linux) operating systems and can only be open inbound by root. Outgoing connections to these ports are unrestricted, meaning SecureTransport will be able to server push to 21, 22, 80, 443 etc. standard service ports even if installed as non-root.

If using privileged ports are a must, consider using NAT on the firewall to translate a publicly visible privileged port (e.g. 22) to a non-privileged port on SecureTransport (e.g. 10022).

2. Not being able to impersonate a user/group

In a POSIX OS, changing user identity (impersonating) is an exclusive privilege of the root account. This enables a root installation of SecureTransport to run agents as the virtual/real user currently logged in, or indeed as any other user. This functionality will not be present in a non-root install and all agents will run as the user that SecureTransport runs as.

3. Not being able to use OS-level filesystem restrictions

Since all agents will run as the same user, in a non-root installation all files must consequently be owned by that same user if they are to be accessible. This includes the entire SecureTransport installation directory as well as all users files. The implications of this are that OS-level filesystem restrictions will not apply and all authorization and access will be internal to ST.

All files being owned by the same user means that in case of a service compromise, the attacker may be able to access the entire ST installation and user files. This is still preferable to being able to access every single file on the host, which could happen when a root service gets exploited.

All of the above restrictions do not come from SecureTransport but are enforced by the underlying OS security model on every non-root application. If these restrictions get in the way, consider installing SecureTransport as root.