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 values are read from the environment variables defined in the system.
The following sections give instructions on chrooting the terminal, remote commands, and subsystems.
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 on Linux. 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
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.
By default, file access by the user using the SFTP subsystem is
restricted by the filesystem access controls. On Unix, access can
be further restricted with the usage of the chroot
attribute.
An example of chroot
usage is shown below:
<services> <rule> <subsystem type="sftp" application="sft-server-g3" action="allow" chroot="/home/%username%" /> ... </rule> ... </services>
Here %username%
will be substituted with the current user
name. For a user named example
, the path would be
/home/example
. During an SFTP session, the user is now
restricted to this directory (and its subdirectories).
Note | |
---|---|
Chrooting the SFTP subsystem affects both SFTP and SCP2 operations to
the server, but it does NOT affect OpenSSH-style SCP operations. To chroot
also OpenSSH SCP, you should chroot the |