[luau] daemons running as root

[MonMotha]

tburns at despammed.com wrote:
>>Why would you want to start [sshd] as nobody? You are supposed to
>>start sshd as root. The application itself handles dropping
>>privileges and chrooting.
> 
> 
> If only! sshd ends up running as root, both if I start it manually or if I reboot/restart the service. 
> 
> And as I say, many (all?) of my other daemons run as root also, isn't this considered a security problem? Could I have messed up my passwd file or something? What would make my init process run everything as root? What log file should I be peeping at to find "hey, I tried to lower my privileges, but I failed."
> 

SSHD normally can't drop privilages because it needs to authenticate users, then 
setuid to the user (after authentication) to start their shell AS THAT USER 
(setuid is only available to root).  However, OpenSSH has a partial solution:

OpenSSH has something known as privilage separation.  What this does is have two 
processes running, with some sort of IPC between them (I'm not familiar with the 
internals).  The daemon is initially run as root, binds to port 80 and drops as 
many capabilities as it can, then it spawns a child process to handle the actual 
authentication and shell setup.  This part is THOUROUGHLY audited because it has 
to retain root privilages.  However, the part that handles accepting connections 
and gathering authentication information (to be passed on to the root level 
process) binds to port 80 then setuid's to another uid (this is your privsep 
user, like sshd, pretty much totally unprivilaged) so that if there is a problem 
(such as a buffer overflow leading to arbitrary code execution) in that portion, 
it only yields access to the system as an unprivilaged user, rather than an 
instant root compromise.

It's a really cool idea.  Unfortunately, it apparently doesn't get along well 
with PAM (which include just about every major distribution, save Slackware and 
Gentoo if you USE="-pam" at bootstrap time), so you may have trouble setting it 
up on a Redhat system.

Of course, all of this is rather worthless if you leave an ancient version of 
wu_ftpd around running as root and listening publicly, allowing anonymous logins 
(yes, I've seen people go to all that trouble securing the SECURE SHELL, only to 
leave a known vulnerible version of *FTP* running).

> Diffused Dave
> 
> 

Hope this helps.

--MonMotha