Security Implications

This approach should not be considered a high security model it has a number of flaws, not least of which is that chroot jails can be broken out of. Breaking a chroot is not a trivial task but it's nowhere near to being impossible and a competant cracker should be able to breach the security offered by chroot. This said it is still a valuable tool in the armoury of the admin.

The DefaultRoot directive is implemented using the chroot(2) system call. This moves the "/" (or root) directory to a specified point within the file system and jails the user into this sub-tree. However this is not the holy grail of security, a chroot jail can be broken, it is not a trivial matter but it's nowhere near impossible. DefaultRoot should be used as part of a general system of security not the only security measure.

A more detailed http://www.bpfh.net/simes/computing/chroot-break.html on this subject and on the breaking of chroot jails has been written by Simon Burr

A more detailed discussion on this subject and on the breaking of chroot jails has been written by Simon Burr (http://www.bpfh.net/simes/computing/chroot-break.html)

This prevention method was developed by Carole Fennelly and her partner. Have a look at the August 1999 Security column of SunWorld Online for the article - see http://www.sunworld.com/sunworldonline/swol-08-1999/swol-08-security-2.html

Have you noticed that the real UID of the ProFTPD process is always 0, even when a user is logged in and an effective UID of said user ?

Thus if a security hole was found in ProFTPD it'd be a quick hop, skip, seteuid(0) to gain root privs and then break out of the chroot() jail.

Other FTP servers do this as well - wu-ftpd was attacked in exactly this way last year. The daemon needs to keep its root privs around when a user is logged in for things like opening sockets on ports <1024.

Required files

Some OSs require files to always exist in an environment for certain things to work. For example you need the following files available for chroot()ed work under Solaris 2.5.1:

/dev/tcp
/dev/ticotsord
/dev/udp
/dev/tcp

So to actually make Proftpd work in a chrooted environment it may be necessary to create $HOME/etc/ $HOME/dev/ and similar directories and create certain files. While files are required will vary from system to system and are generally outside the scope of this guide

svc.conf

For systems which require the svc.conf file, tyically Digital Unix systems, it is essential that a copy of this file is placed within the chroot ($HOME/etc/svc.conf) or all attempts to authenticate will fail with error messages similar to those below.

331 Password required for test.
Password:
230 User test logged in.
ftp> dir
200 PORT command successful.
getsvc: stat of /etc/svc.conf failed
ftp> pwd
getsvc: stat failed: No such file or direc
getsvc: stat of /etc/svc.conf failed
getsvc: stat failed: No such file or direc
150 Opening ASCII mode data connection for
ftp> pwd
226 Transfer complete.
257 "/" is current directory.
ftp> dir
200 PORT command successful.
getsvc: stat of /etc/svc.conf failed
ftp>

Example 1-1. Sample svc.conf file

# WARNING: This file is MANDATORY !
#
# Setup recommendation: As you add distributed services to database
#       entries, it is recommended that "local" is the first service.
#       For example:
#                       passwd=local,yp
#
# Note: White space allowed only after commas or newlines.
#
# File Format
# -----------
# database=service,service
#
# The database can be:
#       aliases
#       group
#       hosts
#       netgroup
#       networks
#       passwd
#       protocols
#       rpc
#       services
# The service can be:
#       local
#       yp
#       bind (hosts ONLY)
#
aliases=local
group=local
hosts=local,bind,yp
netgroup=local
networks=local
passwd=local
protocols=local
rpc=local
services=local
SECLEVEL=BSD   # for backwards compatibility ONLY