From other, separate discussion with simonb about security issues with ftpd
needing to "twiddle" the euid to bind to port 20 (ftp-data), the following
possible solutions came up, which I'm posting here to gather possible
insight.

Both methods involve ftpd *permanently* revoking root privileges after
authentication (and possible chroot).  What I'm hoping to gather here are
people shooting holes in the security implications of these possible
solutions.

1. A process flag, cleared on exec, allowing reserved port binding.

   This would entail somehow setting this privilege flag on the struct proc
   before revoking privileges, but the process could still bind privileged
   ports.

2. A socket option that creates a duplicate of a bound socket.

   This approach allows ftpd to create its data socket before revoking
   privileges, prebound, but not connected to a remote system.  It could
   have other useful non-security-related applications as well.

   The basic usage in userland would be, in pseudo:

     fd = socket(family, type, proto);
     setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &1, sizeof 1);
     bind(fd, addr_and_port);

     setuid(geteuid()); /* revoke privileges */

     loop {
       int newfd;

       parse_commands();
       connect(fd, dest_addr_and_port);
       transfer_data(fd);

       newfd = socket(family, type, proto);
       setsockopt(newfd, SOL_SOCKET, SO_REUSENAME, &fd, sizeof fd);
       shutdown(fd, 2);

       fd = newfd;
     };

   Here, the required port binding is established while the process still
   has privileges, and the binding is duplicated in another socket, which
   is then connected.  A bonus here is that even a connected socket could
   have its binding (name) copied, so ftpd need not have two sockets open
   whenever a transfer is in progress.

...Thoughts?

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  http://www.wasabisystems.com/
-- Speed, stability, security, and support.  Wasabi NetBSD:  Run with it.