Re: The annual setuid question.

>From: "D. J. Raymond" <address@hidden>
>Subject: Compiling ldm-5.0.6 on Debian-2.0
>Organization: New Mexico Institute of Technology
>Keywords: 199901260110.SAA24651 ldm 5.0.6 Debian Linux

> 3. I didn't want the ldm running suid, so I hacked bin/ldmadmin to
> put in a path to ~ldm/logs/ldmd.log.  This seems to work fine.  Is
> there any reason other than logging for the ldm to run suid?
>
> Regards,
>
> Dave Raymond

There are two setuid programs in the the ldm distribution;
'hupsyslog' and 'rpc.ldmd'.

The first program, 'hupsyslog', does only one thing.
It sends a HUP signal to the system log daemon syslogd.
When syslogd recieves a HUP, it closes any files it has open
and re-reads it configuration file. 'hupsyslog' is typically
run periodically to rotate the log files, eg, close and open
a new one. It is called by 'ldmadmin newlog' and other things.

If 'hupsyslog' is not setuid, then only root can rotate the logs.
This is not a big deal. Having 'hupsyslog' setuid is not a security
risk, easily provable by reading the code. In fact, having hupsyslog
is less of a security risk than alternatives, like giving ldm
administrators root.

The second program, rpc.ldmd, is setuid so it can listen on a
privileged port, 388. This is the only reason it is setuid,
nothing to do with logging. When setuid and run by someone other
than root (say, user ldm) the program only operates as root
when opening and closing the port. All child processes run as
the other user, and have lost the ability to become root.
It is harder to prove that rpc.ldmd is safe. We think it is.
Independent reviewers, such as the adminstrators at DOE labs who have
installed the ldm, seem to think it is okay.
'rpc.ldmd' does not do data processing (pqact does), so it has very
little interaction with the file system. The ldm protocol doesn't use
scanf (unlike sendmail, ftp, ...) and can bd shown not to be vunerable
to the buffer overwrite hacks people use.
The program rpc.ldmd will still work without being setuid. In that case
it uses a random unprivileged port. However, for this to work the
rpc portmapper must be running so clients can find the random port.
The portmapper is a root process, running on a privileged port, and
has it own problems. So, you can pick your poison.

The question sometimes arises, "why not use a fixed, non privileged, port?.
We are glad you asked. If we used an unprivileged port, then any user
on a machine could start up some program that claimed to be the ldm.
E.G., it transfers risk to the clients. Isn't it nice to know that the
sendmail server you are handing your mail to is the one 'root' installed?
I think so...

-glenn