NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
"James D. Marco" wrote:
>
> Anne,
> Some post-mortem info.
> Adminstrative ports will not usually open at the socket layer
> without administrative privlege. Since the port mapper service already
> runs at root privaledge, you don't need it a second time. But, it is
> needed somewhere along the line to open 388, as you say. Typically, the
> rpc.ldm is owned by root & it is setuid root ("stickey bits") as mentioned.
> This causes it to execute as root, regardless of the ownership of the user
> process invoking it, hence opening a socket on 388 is allowed. The user
> process needs permission to run this the same as any other executable file,
> too.
> In todays security conscious world, I expect that this problem
> will resurface as administrators tighten security holes. Setuid programs
> are often a security hole.
> jdm
>
Hi Jim,
I agree with everything you said, although I would qualify it further.
... This causes the ldm to execute as root, regardless of the ownership
of the user process invoking it, *but for a limited period of time*.
*It then reverts back to ldm level priveleges*.
I know that setuid programs can be a security hole. While I'm not an
expert on security, I believe it depends on how the setuid is handled.
For example, some programs setuid and always keep root level priveleges,
or spawn other processes that have root level priveleges. Some setuid
programs execute other programs not owned by root that are thus
insecure. Shell scripts that are setuid are insecure because they can
be modified. Some versions of ftp are/were insecure due to a race
condition that left setuid files on the server.
In contrast, the ldm has root level priveleges just long enough to get
the port, check that no one else is using it, and register with the
portmapper. It then reverts to ldm level priveleges. Although is does
execute other programs not owned by root (particularly pqact and
pqbinstats which are owned by ldm) it does this as user ldm. (I suspect
Robert and Brad's original problem was that the ldm was invoked as root,
and, for security reasons, their machine was configured so that root
would only execute programs owned by root. Once the ldm was invoked as
user ldm, it exec'ed the ldm owned programs as it was supposed to.)
Once the ldm binary is built, we believe it is pretty safe. At least,
we have had no reports yet of unauthorized access via the ldm, which has
been running in this manner for about five years.
Many useful programs use setuid. ssh, for example, runs as root, but
when someone logs in it spawns a process setting the effective user id
to be the login id. sendmail is setuid root, allowing it to write
files in the mail queue area, which normal users are not allowed to do.
I know that people are trying to write system utilities that are atomic
and more secure. But it will probably be some time, if ever, before
setuid programs can be done away with.
Anne
--
***************************************************
Anne Wilson UCAR Unidata Program
anne@xxxxxxxxxxxxxxxx P.O. Box 3000
Boulder, CO 80307
----------------------------------------------------
Unidata WWW server http://www.unidata.ucar.edu/
****************************************************
>
> At 11:01 AM 1/18/2001 -0700, you wrote:
> >Brad Teale wrote:
> >>
> >> I was wondering why the specifications for the ldm say to chown rpc.ldmd to
> >> root. If the ldm is registered with the portmaper (/etc/rpc), then the
> >> portmaper specifies which port ldm will be using. Also, if ldm uses rpc,
> >> why are we specifying the 388 port in the /etc/services file?
> >>
> >> I am asking because, when I run rpc.ldmd as the ldm user, my pqact and
> >> pqbinstats programs start-up and run great. Where as, if rpc.ldmd is
> >> chowned to root, they never start and no errors are produced.
> >>
> >> Thanks,
> >> Brad Teale
> >> Universal Weather & Aviation, Inc.
> >> <mailto:bteale@xxxxxxxxxxxx>
> >> 713-944-1440 ext. 3623
> >
> >Brad,
> >
> >For some historical reason, it was decided that the ldm would use one of
> >the hard-wired, system service ports (ports less than 1024) rather than
> >relying on the portmapper. I believe the ldm will run using the
> >portmapper service if it doesn't have access to port 388.
> >
> >Simply listing the ldm in /etc/services and ldmd in /etc/rpc doesn't by
> >itself allow the ldm to get to the port. My understanding is that those
> >files serve mostly to map from numbers to strings for informational
> >purposes. The ldm still needs root priveleges to get port 388.
> >
> >Our standard installation has rpc.ldmd owned by root and setuid root,
> >and expects the ldm to be started via user ldm. The idea is that the
> >ldm has root priveleges temporarily, just long enough to get port 388,
> >then it reverts back to ldm level priveleges because it was invoked by
> >user ldm. This is what the permissions should look like on rpc.ldmd:
> >
> >-rwsr-xr-x 1 root ustaff 441385 Sep 8 10:54 rpc.ldmd*
> >
> >This has worked for us on many sparc workstations.
> >
> >Were you originally invoking the ldm as root? If you were, it possible
> >that root will not exec programs that it suspects are unsafe. Were
> >there any messages in the system log?
> >
> >Also, it is better to send questions of this nature to
> >support@xxxxxxxxxxxxxxxx, rather than to this list. Please respond to
> >me directly.
> >
> >Thanks!
> >
> >Anne
> >--
> >***************************************************
> >Anne Wilson UCAR Unidata Program
> >anne@xxxxxxxxxxxxxxxx P.O. Box 3000
> > Boulder, CO 80307
> >----------------------------------------------------
> >Unidata WWW server http://www.unidata.ucar.edu/
> >****************************************************
> >
> James D. Marco, jdm27@xxxxxxxxxxx, jmarco1@xxxxxxxxxxxx
> Programmer/Analyst, System/Network Administration,
> Computer Support, Et Al.
> Office: 1020 Bradfield Hall, Cornell University
> Home: 302 Mary Lane, Varna (607)273-9132
> Computer Lab: 1125 Bradfield (607)255-5589
ldm-users archives: