root@uunet.uu.net (Operator) (05/26/88)
Tonight, one of my users executed the /etc/rc script twice. This had the not-very-amusing effect of causing multiple copies of some daemons such as sendmail to be running. I have noticed before that users can execute the administrative daemons and the user-started daemon will displace the system-started daemon from the distiguished port that that particular daemon listens to. When this happens, all manner of "not-very-amusing" things happen due to protection problems. Is there a solution to this problem? I believe that there are files in the /etc directory that are expected to to be readable with normal user permissions so I don't think I can simply deny access to the directory. I can't think of any way to prevent users from starting sendmail as a daemon without denying ALL execution access to sendmail. I suppose I could make /etc/rc unreadable but this seems to ignore the real problem Any suggestions on how to prevent a user daemon from displacing a system daemon in general? I am using a SUN3/160 running SunOS3.4.2 (until the 4.0 tape arrives). I do not have source to SunOS or any version of BSD. I have the VAX SVR2.2 source tapes from Alexander Graham and friends. += David Linn ==========================================================+ | System Manager, Vanderbilt University School of Engineering |INET: drl@vuse.vanderbilt.edu [129.59.100.1] | |UUCP: ...!uunet!vuse!drl CSNET: drl@vanderbilt.csnet | |AT&T: (615)322-7924 BITNET: linndr@vuengvax | |USPS: P.O. Box 1824, Vanderbilt University, Nashville, TN, USA, 37235 | +======== "I can sing louder than you" - T. S. `Dr. Seuss' Geisel ======+
bzs%bu-cs.bu.edu@bu-it.bu.edu (Barry Shein) (05/26/88)
>Is there a solution to this problem? I believe that there are files >in the /etc directory that are expected to to be readable with normal >user permissions so I don't think I can simply deny access to the >directory. I can't think of any way to prevent users from starting >sendmail as a daemon without denying ALL execution access to sendmail. >I suppose I could make /etc/rc unreadable but this seems to ignore the >real problem > >Any suggestions on how to prevent a user daemon from displacing a >system daemon in general? You could write little wrapper C programs which check args and whatever else (eg. for sendmail you could demand that IF anyargv(-bd) THEN must_be_root .) Then move the originals and have /usr/lib/sendmail (eg.) be your wrapper program which will check args and then exec the renamed original. Obviously you have to get this right, especially on critical systems programs (also watch out for ones run out of /etc/rc that rely on certain disks being mounted, a lot of the stuff that gets run off of /etc [root] is run before the other disks are mounted.) I wouldn't suggest shell scripts for this sort of thing as setuid shell scripts introduce more hazards, also be careful to explicitly use full (root based) path names and you might create copious README files in the appropriate directories and note them in the rc files. Like I said, you should test these carefully as there are subtleties (like effective vs real uid which some daemons may sniff for), diskless suns are wonderful for this kind of banging around because even if you put it into a non-bootable state you can always put it back together by mounting the diskless partition on the server with the nd system down. -Barry Shein, Boston University
rbj@icst-cmr.arpa (Root Boy Jim) (05/28/88)
Date: Wed, 25 May 88 22:46:48 CDT From: Operator <vuse!root@uunet.uu.net> Tonight, one of my users executed the /etc/rc script twice. This had the not-very-amusing effect of causing multiple copies of some daemons such as sendmail to be running. I have noticed before that users can execute the administrative daemons and the user-started daemon will displace the system-started daemon from the distiguished port that that particular daemon listens to. When this happens, all manner of "not-very-amusing" things happen due to protection problems. Is there a solution to this problem? I believe that there are files in the /etc directory that are expected to to be readable with normal user permissions so I don't think I can simply deny access to the directory. I can't think of any way to prevent users from starting sendmail as a daemon without denying ALL execution access to sendmail. I suppose I could make /etc/rc unreadable but this seems to ignore the real problem As you said above, you can't deny access to the entire directory, because there are files that must be world readable. You can trun off the world execute bit on commands you don't want l'users to run tho. Any suggestions on how to prevent a user daemon from displacing a system daemon in general? This is really up to the daemon. In many cases it is not setuid root, so it should die when it attempts to do something privileged. In other cases, the daemon should protect against multiple invocations by the masses, but this is not much consolation if it doesn't. The idea of wrapper programs is a good one if you really need this kind of protection. Perhaps the wrapper would be setgid to some group and the real daemon executable only by this group. The wrapper would validate access invoke the real program if everything is okay and it wasn't previously running. Optionally, you could kill the old daemon to provide a restart capability. Just what daemons gave you problems? (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement My name is in /usr/dict/words. Is yours?
ron@topaz.rutgers.edu (Ron Natalie) (05/28/88)
This is amusing. First, it's unclear to me why your system is set up so that UNPRIVELEDGED users can grab control of the resources required to make these systems programs work. Generally programs need to be running as root to make this work. Programs should generally not be setuid root when they are going to be started from rc, as rc is executed as root to begin with. sendmail is a sticky problem. For some harebrained reason sendmail is setuid root on BSD systems and will allow you to use set daemon mode even if you are only effectively root. Oh well. -Ron
budd@bu-cs.BU.EDU (Philip Budne) (06/09/88)
All this is from experience managing a SOS 3.4 cluster, I have no
knowledge of how things may have changed in 4.0.
One example of how a user running /etc/rc* files can cause mayhem is a
user starting a private copy of inetd. The new inetd will try to bind
local sockets and fail for the ordinary tcp and udp based services,
but will re-register RPC based services with the portmapper.
This happened once here, and all rcp.mountd requests were being
serviced by and failing, returning EACCESS (presumably on an call to
open with the path of the mount (to get an fd to hand to getfh(2))
It took me QUITE a while to track this down after searching for and
finding no applicable references to EACCESS in the source for either
client or server nfs.
portmap and nfsd should be immune to this as they bind to reserved
sockets, but ypbind and ypserv may also have this weakness.
In short portmap does not provide rigorous defense of the ports it
names. In fact any user can call pmap_unset;
/* rpcrm.c -- p budne@bu/dsg */
main( c, v )
int c;
char *v[];
{
if( c != 3 ) {
printf("%s prog version\n", v[0] );
exit( 1 );
} /* wrong number of args */
if( pmap_unset( atoi( v[1] ), atoi( v[2] ) ) )
puts( "OK" );
else
puts( "failed" );
} /* main */