Network Security Hacks [Electronic resources] نسخه متنی

Hack 18 Restricted Shell Environments

Keep your users from shooting themselves (and
you) in the foot.

Sometimes a
sandboxed
environment [Hack #10]
is overkill for your needs. If you want to set up a restricted
environment for a group of users that only allows them to run a few
particular commands, you'll have to duplicate all of
the libraries and binaries for those commands for each user. This is
where restricted shells come in handy. Many shells include such a
feature, which is usually invoked by running the shell with the
-r switch. While not as secure as a system
call-based sandbox environment, it can work well if you trust your
users not to be malicious, but worry that some might be curious to an
unhealthy degree.

Some common features of restricted shells are the ability to prevent
a program from changing directories, to only allow the execution of
commands using absolute pathnames, and to prohibit executing commands
in other subdirectories. In addition to these restrictions, all of
the command-line redirection operators are disabled. With these
features, restricting the commands a user can execute is as simple as
picking and choosing which commands should be available and making
symbolic links to them inside the user's home
directory. If a sequence of commands needs to be executed, you can
also create shell scripts owned by another user. These scripts will
execute in a nonrestricted environment and can't be
edited within the environment by the user.

Let's try running a restricted shell and see what
happens:

$ bash -r
bash: SHELL: readonly variable
bash: PATH: readonly variable
bash-2.05b$ ls
bash: ls: No such file or directory
bash-2.05b$ /bin/ls
bash: /sbin/ls: restricted: cannot specify `/' in command names
bash-2.05b$ exit
$ ln -s /bin/ls .
$ bash -r 
bash-2.05b$ ls -la
total 24
drwx------    2 andrew    andrew        4096 Oct 20 08:01 .
drwxr-xr-x    4 root      root          4096 Oct 20 14:16 ..
-rw-------    1 andrew    andrew          18 Oct 20 08:00 .bash_history
-rw-r--r--    1 andrew    andrew          24 Oct 20 14:16 .bash_logout
-rw-r--r--    1 andrew    andrew         197 Oct 20 07:59 .bash_profile
-rw-r--r--    1 andrew    andrew         127 Oct 20 07:57 .bashrc
lrwxrwxrwx    1 andrew    andrew           7 Oct 20 08:01 ls -> /bin/ls

Restricted ksh is a little different in that it will
allow you to run scripts and binaries that are in your
PATH, which can be set before entering the shell:

$ rksh
$ ls -la 
total 24
drwx------    2 andrew    andrew        4096 Oct 20 08:01 .
drwxr-xr-x    4 root      root          4096 Oct 20 14:16 ..
-rw-------    1 andrew    andrew          18 Oct 20 08:00 .bash_history
-rw-r--r--    1 andrew    andrew          24 Oct 20 14:16 .bash_logout
-rw-r--r--    1 andrew    andrew         197 Oct 20 07:59 .bash_profile
-rw-r--r--    1 andrew    andrew         127 Oct 20 07:57 .bashrc
lrwxrwxrwx    1 andrew    andrew           7 Oct 20 08:01 ls -> /bin/ls
$ which ls
/bin/ls
$ exit

This worked because /bin was in the
PATH before we invoked ksh. Now
let's change the PATH and run
rksh again:

$ export PATH=.
$ /bin/rksh
$ /bin/ls 
/bin/rksh: /bin/ls: restricted
$ exit
$ ln -s /bin/ls .
$ ls -la
total 24
drwx------    2 andrew    andrew        4096 Oct 20 08:01 .
drwxr-xr-x    4 root      root          4096 Oct 20 14:16 ..
-rw-------    1 andrew    andrew          18 Oct 20 08:00 .bash_history
-rw-r--r--    1 andrew    andrew          24 Oct 20 14:16 .bash_logout
-rw-r--r--    1 andrew    andrew         197 Oct 20 07:59 .bash_profile
-rw-r--r--    1 andrew    andrew         127 Oct 20 07:57 .bashrc
lrwxrwxrwx    1 andrew    andrew           7 Oct 20 08:01 ls -> /bin/ls

Restricted shells are incredibly easy to set up and can provide
minimal restricted access. They may not be able to keep out
determined attackers, but they certainly make a hostile
user's job much more difficult.