This document explains the design goals and decisions behind vsftpd.The importance of a secure design=================================In a world full of good, careful coders who do not make mistakes, a securedesign would not be necessary. After all, in the absence of any programmingerrors, security would not differ no matter how the program is arranged.Unfortunately, this is not an ideal world, and coders make plenty of mistakes.Even the careful coders make mistakes. Code auditing is important, and goessome way towards eliminating coding mistakes after the fact. However, wehave no guarantee that an audit will catch all the flaws.So, a secure design acknowledges the possibility of undiscovered flaws, andtakes steps to minimise the security impact these flaws can have. An obviousexample of something we want to do is to apply the principle of leastprivilege, which ensure that every part of the program runs with the privilegeit needs and no more.An example of insecure design=============================Examples of insecure design may be found in most other ftpd's. That's one ofthe reasons vsftpd has been written. We'll pick on wu-ftpd as a specificexample, since it is rumoured to run about half of all ftp services.If I log on to wu-ftpd as an anonymous user, a process is run on my behalf toserve my ftp session. Unfortunately, this process typically runs with fullroot privileges on the remote machine. This means that any security flawpresent in parsing the copious ftp protocol will lead to full compromise ofthat machine. Two concrete examples are the recent wu-ftpd format string bug(June 1999), and a buffer overflow dealing with large paths a few monthsbeforehand.Even OpenBSD's ftpd-BSD had a format string bug leading to remote rootcompromise of the affected machine, illustrating an earlier point about therequirement for secure design even in the presence of heavy auditing.Secure design under UNIX========================vsftpd is written to run under UNIX-like operating systems, and so its securedesign is constrained by the facilities offered by UNIX. Ideally, UNIX wouldhave a proper security model which would offer fine grained access controlto all system interactions (files, network, etc). It doesn't, but it doesoffer some useful and often overlooked facilities which help us to implementthe principle of least privilege:- Strong inter-process communication facilitiesIn UNIX, the process is a strongly defined boundary. Different privilegecredentials may be assigned to different processes, which are not able tointerfere with each other. This is a very basic facility of UNIX.It makes sense to use this facility to totally separate parts of a programwhich do not need to be privileged (most) from those parts that do (typicallyminimal).The privileged and unprivileged parts of the program then communicate viaone of many UNIX IPC mechanisms - perhaps a socketpair or IPC (the formeris attractive because UNIX lets you pass file handles over a socket).The minimal privileged process exercises the "principle of distrust" - itcarefully filters what the unprivileged process asks it to do, so that evenif the unprivileged process is compromised, it cannot ask the privilegedprocess to do anything we don't want to allow.- chroot()chroot() is an often overlooked but useful tool. It can be used veryeffectively as a damage limitation tool.Imagine a remotely compromised process which does not run as root, but alsodoes not use chroot(). Now look at what the attacker can do. Amongst the worstitems are pilfering of all publicly readable files, and also attempting toexecute any publicly executable suid-root programs to try and elevateprivilege.Now imagine the same compromised process with a chroot() to an empty directory.The attackers options to do unpleasant things are substantially diminished.No, chroot() is not the ideal way to do what we have just accomplished, butit is what we have got to work with. In an ideal environment with finegrained security, we would default to having access to _no_ files at all, anddeliberately not ask for access to any.- Capabilities (Linux 2.2+)Like chroot(), capabilities are essentially a damage limitation excercise.They are also much less widespread than the other UNIX facilities detailledabove. Nonetheless, they warrant mentioning because Linux has them, and theyare used in vsftpd because that is the primary devlopment platform.Capabilities split up the all powerful root privilege into lots of sometimesorthogonal privileges. Some of the capabilities represent privileges whichare often the basis for requiring a program to run with full root privileges.Examples include CAP_NET_RAW (ping, traceroute) and CAP_NET_BIND_SERVICE(rlogin).By using capabilities to ensure we only have the privilege we need (withinthe somewhat disappointing granularity they offer), we again limit thepotential damage of security holes.Presenting vsftpd's secure design=================================vsftpd employs a secure design. The UNIX facilities outlined above are usedto good effect. The design decisions taken are as follows:1) All parsing and acting on potentially malicious remote network data isdone in a process running as an unprivileged user. Furthermore, this processruns in a chroot() jail, ensuring only the ftp files area is accessible.2) Any privileged operations are handled in a privileged parent process. Thecode for this privileged parent process is as small as possible for safety.3) This same privileged parent process receives requests from the unprivilegedchild over a socket. All requests are distrusted. Here are example requests:- Login request. The child sends username and password. Only if the detailsare correct does the privileged parent launch a new child with the appropriateuser credentials.- chown() request. The child may request a recently uploaded file getschown'ed() to root for security purposes. The parent is careful to only allowchown() to root, and only from files owned by the ftp user.- Get privileged socket request. The ftp protocol says we are supposed toemit data connections from port 20. This requires privilege. The privilegedparent process creates the privileged socket and passes it to child overthe socket.4) This same privileged parent process makes use of capabilities and chroot(),to run with the least privilege required. After login, depending on whatoptions have been selected, the privileged parent dynamically calculates whatprivileges it requires. In some cases, this amounts to no privilege, and theprivileged parent just exits, leaving no part of vsftpd running withprivilege.5) vsftpd-2.0.0 introduces SSL / TLS support using OpenSSL. ALL OpenSSLprotocol parsing is performed in a chroot() jail, running under an unprivilegeduser. This means both pre-authenticated and post-authenticated OpenSSL protocolparsing; it's actually quite hard to do, but vsftpd manages it in the name ofbeing secure. I'm unaware of any other FTP server which supports both SSL / TLSand privilege separatation, and gets this right.Comments on this document are welcomed.