Guide to writing secure setuid programs?

[Jack Jansen]

Well, some things I check a set-uid program for (most of them
learned in the time I wasn't interested yet in writing secure
setuid program but in find bugs in setuid programs:-)

- Never take for granted that the user will not do this-or-that. She
  will.
- Check, double-check and triple-check *each* library or system
  call. Try to think of devious ways of making it do things it
  shouldn't. Hints: think of IFS, links, symbolic links, running
  in removed directories(!), environment variables in general,
  job control, etc etc etc.
- Never take for granted that the user will not do this-or-that. He
  will.
- Always be aware of the time-sharing aspect of unix. Never write
  code like
  if( stat(file, &sb) < 0 ) {
      /* Now we're sure the file doesn't exist so it'll be owned
      ** by us.
      */
      fd = creat(file, mode);
  }
- Never take for granted that the user will not do this-or-that. She
  will.
- Never think that setgid or setuid to bin is less dangerous than
  setuid to root.
- Never take for granted that the user will not do this-or-that. He
  will.
- Never allow interrupt routines, *not even with a signal catcher*
  to clean up in a critical section. 'ulimit stacksize' can be
  very useful at times..........
- The difficult one: never trust any other machine. Given control
  over one machine on an ethernet, for instance, I can impersonate
  *any* other machine by first crashing the original, trusted, machine
  and then impersonating it.

And, of course, the general rule is not to write setuid programs
in the first place, but that has been handled by other people.
-- 
	Jack Jansen, jack at cwi.nl (or jack at mcvax.uucp)
	The shell is my oyster.