hosted by

Sourceforge project page


Download


ESELSTALL

NAME
SYNOPSIS
DESCRIPTION
EXAMPLE
REMARKS
RETURN VALUE
BUGS
SEE ALSO
AUTHOR

NAME

eselstall - Eselstall Secure Environment to Launch Software you don't Trust At aLL

SYNOPSIS

eselstall USER COMMAND ARGS...

DESCRIPTION

Eselstall acts as a wrapper around COMMAND which is run as a non-privileged user in a changeroot environment. It performs the following tasks:
1. changeroot
Eselstall changeroots to USER's $HOME directory.
2. start a new session
Eselstall starts a new session in the background as USER. All privileges are dropped at this point. This is basically the same as if USER would log into the machine, except no password is asked for. Eselstall therefore requires root privileges.
3. clear environment
All environment variables (including basic ones such as $HOME and $USER) are unset.
4. start COMMAND ARGS
Eselstall executes COMMAND and passes ARGS as command line arguments.
The intended use of eselstall is to create a distinct account for each COMMAND you'd like to run in background as non-privileged USER. The user's home directory must contain all files needed to run COMMAND, including a statically linked binary (or dynamically linked plus libraries) of COMMAND itself. Any other privileges of the user (e.g. network access using Linux 2.6's security hooks) should be set up as restrictive as possible.
In an ideal case no binaries or libraries need to be placed in the changeroot directory except a statically linked version of COMMAND. Eselstall does pretty much the same as
chroot USERS_HOME su USER -c 'setsid COMMAND ARGS'
but eliminates the need for setsid and su binaries and related files (such as /etc/passwd) in the changeroot.
Eselstall can then be run at system startup time as root (e.g. from rc.local) to start the different daemons.

EXAMPLE

Imagine a simple server program called simples you want to run on your system. The program requires /etc/simplesrc as configuration file and a spool directory. It listens on port 2345.
To run this program in an eselstall environment set up a user account simplesuser. Disable login for this account. Set the account's home directory to a directory of your convenience, e.g. /var/simples. Create the directories /var/simples/etc and /var/simples/spool. Create the configuration file /var/simples/etc/simplesrc and set the spool directory to /spool in the configuration file. Copy a statically linked executable of simples to /var/simples. Set up the directory rights so that simplesuser is not allowed to write to any files except in /var/simples/spool. Add the line
eselstall simplesuser /simples
to your rc.local init script to start simples at boot time.
If you're using Linux 2.6 or later you might also want to limit access to other resources by preventing simples from opening any ports except 2345 for listening.
Note that you do not need a shell, an su-binary, an eselstall-binary, /etc/passwd, any libraries or anything else in the changeroot directory which is not directly required to run simples.

REMARKS

Although this tool should theoretically compile on most UNIX-like systems it mainly makes sense on Linux. Other operating systems have other mechanisms to establish similar and often more sophisticated functionality (e.g. jail in FreeBSD).
This tool is in no way a substitute for system updates.
*
It can just help the admin win some time to do the actual update.
*
There have been several security issues recently that would have allowed bypassing this tool without any problem combining two distinct leaks. So UPDATE YOUR SYSTEM REGULARLY!
This tool is in no way a substitute for the sysops brain.
*
It can just help the admin implementing a well designed security concept.
*
The following things are probably bad ideas in situations where you would want to use this tool, except in very special cases:
-
Have any setuid executables in the chroot directory. If possible disallow setuid files on the whole filesystem (Linux loop mounts might become handy here). Put only executables into the changeroot that are absolutely necessary.
-
Have a /dev-directory with device files in the changeroot. If possible disallow device files on the whole filesystem (again, Linux loop mounts might become handy here).
-
Have a proc, sys or similar filesystem in the changeroot.
-
Give USER write access to or let him own any of the executables or the directories with executables in them in the changeroot.
-
Have any dynamically linked executables and libs in the changeroot directory. There is nothing wrong with dynamic linking and libraries as such but you should ask yourself if it makes sense to have them in the environment and if it does if eselstall is the right solution for you or if there wouldn't be a better (and more sophisticated) solution somewhere out there.
*
As a general rule any restrictions that can be placed on USER should be placed on user, any files that can be kept out of the changeroot should be kept out.

RETURN VALUE

Eselstall returns 0 on success. On error, 1 is returned and a message is printed to stderr.

BUGS

Just like any other software, eselstall might contain serious bugs. This has two main consequences:
*
Never trust anyone or any software. This applies to eselstall as well as the programs run inside the environment and your operating system. All three parts might be exploitable.
*
If you find a bug, please report it to the author as soon as possible so it can be fixed in order to let other people profit from your discovery as well.

SEE ALSO

chroot(8), login(8), chrootuid(1)
http://eselstall.sourceforge.net

AUTHOR

Christian Ruppert <arc@users.sourceforge.net>