Guide to writing secure setuid programs?

[William E. Davidsen Jr]

In article <700 at virginia.acc.virginia.edu> scl at virginia.acc.Virginia.EDU (Steve Losen) writes:
| 
| 2)  Avoid setuid if you can.  I once wrote a very simple print spooler
| 	that puts files in a directory where they are picked up periodically
| 	by a daemon to be printed.  I made the directory 777 instead of using
| 	setuid-to-lp fraud.  Sure a malicious user can remove files in the
| 	print queue. So what?  To my knowlege, no one has ever done that in
| 	the two years since I put the system up.  Ask yourself, "Does this
| 	really need to be setuid?"  For example, I would *never* make a program
| 	setuid just so it could write to a protected logfile.  To hell with it.
| 	make the logfile 622.
  While I agree with much of what you said, I totally disagree on this
point. I can't belive that this is workable of any system available to
hackers (ie. public access, campus machines, etc), and would not really
provide benefits on even a machine loaded with well behaved users.

  While setuid leaves problems, I doubt the proper way to solve them is
to let people do things with system queues without using setuid. I have
spent a great deal of time setting my system so that it is secure (one
of the systems is public access). Here are a few things I've done:

  Scan the entire filesystems with find and identify every program in
the system with setuid on. Any of these which are owned by system uids
are examined carefully for problems.

  I have all my system queues set to require access via setuid, just the
opposite of your method. I have all my lp and uucp stuff locked up,
accessed by a small number of trusted programs. Other programs which
access the queues may be setuid, but are not executable by anyone but
the user and root. When creating files setuid prevents files from having
dubious ownership, such as root. If you leave a file owned by root, it
can be modified.

  I have logins just for working on various subsystems, most commonly
uumaint (uucp) and lpmaint (lp). Logins which access uucico run under
another uid, not uucp. All files and queues are accessable by uucp
(unless other access is needed). No program which does a "system" call
or starts a shell in any way is setuid.

  I have accounting on, running to a write only device. This allows me
to analize system behavior as needed. It has helped me spot and correct
problems, and is checked by a cron script daily and by me when I get a
bad feeling.

  I don't allow users to execute many of the uucp programs, particularly
uucico. I'm not going to post the hole here, but only logins can run the
program on my system.

  I hope that this offers another viewpoint on this area.
-- 
	bill davidsen		(wedu at ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me