In message <43905EB9.4070703@NetBSD.org>, Elad Efrat writes:
>Steven M. Bellovin wrote:
>
>> ntpd.  ftpd has to run as root part of the time, to bind to port 20.  
>> apache keeps a portion of itself as root; suexec, if you use it (and 
>> you probably should), always runs as root.
>
>I'm not familiar with the code of these programs. Are you sure these
>are all programs that fork a root-owned process, chroot, and continue
>operation?

They differ.  ntpd, at least on my system, is running as root:

# ps l14124
UID   PID PPID CPU PRI NI  VSZ  RSS WCHAN STAT TTY    TIME COMMAND
  0 14124    1   0  18  0 1100 3440 pause Ss   ?   0:00.25 /usr/sbin/ntpd 

I know there's a separate uid for it; I have no idea why it isn't being 
used, but I'm using all default options.  If it can run protected, it 
certainly should do so by default.

Leaving out the new change that lets ftpd run (again) as a standing
daemon -- I haven't looked at it yet -- each instance of ftpd runs
as root until login.  After login, it runs as that user (including
user 'ftp' for anonymous) most of the time; it uses seteuid to
regain root permissions to bind to port 20 before some file transfers.
This is done to avoid the need to do permission-checking before
opening a file; it provides absolutely no protection against most
buffer overflows, because the injected code could just do setuid(0)
first.

Apache isn't always (or even commonly) chrooted; it should be.
Part of apache runs as root routinely; most of it does not.

My point, though, is that that chrooted daemons don't run as root.
You're right that they shouldn't -- chroot is not protection against
root -- but my point is that there are such daemons.  Yes, several
of these programs have (as you note in part of your email that I
didn't include) had remote compromise problems; that's one reason
they do run chrooted.  With sysctl, it's harder to lock out root,
because we don't have another access control model.  (I'm still
searching for a good, clean way to prevent mknod is chrooted areas.)
(And you're quite right that ftpd is hardly a model for secure 
software; in fact, I've been using it as a counter-example for years.)

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb