Doing the unexpected

[Barry Shein]

>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