Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!umd5!brl-adm!adm!bzs%bu-cs.bu.edu@bu-it.bu.edu From: bzs%bu-cs.bu.edu@bu-it.bu.edu (Barry Shein) Newsgroups: comp.unix.wizards Subject: Doing the unexpected Message-ID: <14784@brl-adm.ARPA> Date: 26 May 88 15:35:28 GMT Sender: news@brl-adm.ARPA Lines: 33 >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