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.
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
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