On Wed, Nov 22, 2000 at 01:11:30AM -0500, Todd Vierling wrote:
> 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.

If you run ftpd with `-r', or bound to a port > 1024, or use `-P dataport' 
with a port > 1024, ftpd will use setuid(pw->pw_uid) to irrevocably
drop root privs. Of course, it breaks the RFC WRT the dataport being
the ctrlport-1, but ...


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

Another solution is to have a central file descriptor broker daemon,
which you communicate with via an authenticated AF_LOCAL socket.
The broker checks the creds against an access control list (defined in
a config file), and if ok, passes back a file descriptor over the socket.

This same concept could be extended to other files that need to access
a file as another user; just ask the broker which checks your creds
against its ACL for that file.

If this would work as a concept, and we had an API for this (in -lutil
or wherever) could we even use it to solve the $HOSTALIASES problem for
set-id programs? I.e, the application sends a request to the broker for
a file descriptor, the broker forks a child to run as the target uid
which opens the file as the real user and passes the file descriptor
back to the setuid program. Or would that be too inefficient?

Luke.