vsftpd-2.1.0 and ptrace() sandboxing

The new sandboxing support mentioned in the vsftpd-2.1.0 announcement post is actually a ptrace() based sandbox.

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=YES in 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 SIGKILL signals around
• 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_user to a value unique to vsftpd)
• Abuse your CPU / bandwidth

The sandbox eliminates most of the above concerns and drastically reduces the attack surface on others. On the downside, there are some minor performance losses such as an extra process per-session and per-syscall overhead but nothing severe. So for extreme paranoia, perhaps there is benefit here. We'll see.