It is experimental and therefore off by default. It only currently supports i386 Linux (but there's no reason you couldn't hack the Makefile to build 32-bit on 64-bit Linux). When enabled, it only engages when using
one_process_model, i.e. simple anonymous-only configurations. To (try and) enable it, set
sandbox=YESin your config file. If you do try, please e-mail or leave a comment, even if it works!
But was it worth the effort? That's a very astute question; vsftpd already pioneered privsep support as a way of limiting the damage of a compromise of the FTP parsing code (or more likely OpenSSL, if enabled).
Let's briefly examine the damage that can be done in the event of a compromise of the low-privileged end of a privsep-based solution. Let's also assume the low-privileged end is running in a suitable
chroot()jail with no sensitive, writeable or setuid files. With arbitrary code execution, the attacker can still:
- Mount attacks against the kernel API to gain root
- Connect to internal RFC1918 networks, i.e. firewall bypass
- Connect to localhost, i.e. attack local-only services
- Cause a nuisance by spraying
- Mess with any shared objects (e.g. POSIX shared memory) with inappropriate permissions
- Subvert other processes with the same UID / GID via
ptrace()(vsftpd defends against this as long as you set
nopriv_userto a value unique to vsftpd)
- Abuse your CPU / bandwidth