Chrooting (Unix)

By default, file access by users is restricted by the filesystem access controls. On Unix, access can be further restricted with the usage of the chroot attribute. The chroot attribute can be used with the subsystem, terminal, and command elements.

The chroot attribute must be a directory path. Values %username%, %homedir%, and %hostname% will be substituted with the username, user's home directory, and the FQDN of the connected client, respectively.

The following sections give instructions on chrooting the terminal and remote commands. For chrooting with the SFTP subsystem, see Chrooting SFTP (Unix).

Chrooting Terminal

An example of chrooting the terminal is shown below:

<services>
  <rule>
    <terminal action="allow" chroot="%homedir%" />
   ...
  </rule>
  ...
</services>

When users are restricted to the chrooted environment, they cannot access the normal shell binary. This means that the shell specified in the /etc/passwd file for the user has to be present in the equivalent place under the chrooted directory. For example, if /etc/passwd lists /bin/bash as the shell and the user is chrooted to the home directory, a statically linked %homedir%/bin/bash should exist.

If the user's shell is dynamically linked, you must make sure that the required shared libraries are also in the chrooted environment. You can resolve the dependencies with the ldd command:

$ ldd /bin/bash
        libtermcap.so.2 => /lib/libtermcap.so.2 (0x40026000)
        libdl.so.2 => /lib/libdl.so.2 (0x4002a000)
        libc.so.6 => /lib/libc.so.6 (0x4002d000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ ls lib
ld-linux.so.2  libc.so.6  libdl.so.2  libtermcap.so.2  libtermcap.so.2.0.8

Also note that shared libraries can have other dependencies:

$ ldd libtermcap.so.2.0.8 
        libc.so.6 => /lib/libc.so.6 (0x40017000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

The user's environment might also need some other tools, such as:

ls for listing files
stty for setting tty modes

You might also need some device files under the user's virtual root directory. At least A /dev/null file is needed. You can create it as follows:

$ mkdir dev
$ cd dev
$ ls -l /dev/null
crw-rw-rw-    1 root     root       1,   3 Jan 30  2003 /dev/null
$ mknod null c 1 3
$ chmod go+w null
$ ls -l null

Chrooting Remote Commands

An example of chrooting a remote command is shown below:

<services>
  <rule>
    <command application="date" action="allow" chroot="%homedir%" />
   ...
  </rule>
  ...
</services>

Now, the user is restricted to the home directory when running sshg3 with the remote command date:

$ sshg3 user@server date

The command to be run has to be statically linked and available under the chrooted environment. In the above example when the user is chrooted to the home directory, a statically linked date command should exist in %homedir%/bin.

If the command is dynamically linked, you must make sure that the required shared libraries are also in the chrooted environment. See Chrooting Terminal above.