Guide to writing secure setuid programs?

[William Sommerfeld]

In article <8468 at eddie.MIT.EDU> jbs at eddie.MIT.EDU (Jeff Siegal) writes:
>#1 [listing the directory] can be prevented, if necessary by setting the
>directory mode to 733 rather than 777.  This effectively prevents
>#2 [reading and/or writing files in the directory] and #3 [deleteing
>files] if you use obscure file names.  #2 can be absolutely prevented
>in any case by setting the mode of each file in the directory
>appropriately.  #3 can be absolutely prevented on BSD 4.3 systems by
>setting the sticky bit (mode 1733) on the directory.

Of course, this implies that the daemon which reads this queue runs as
root, which may not be desirable either.

Secure systems should be able to withstand attacks when the attackers
have complete access to all design documentation, source, and object
code.  "Security through obscurity" is not security at all.

 - How do you seed the random number generator used to generate the
100-character `obscure' filename such that knowing, for example, the
approximate starting time and process ID of a process which dropped
something interesting in the queue doesn't make things any easier.

A much better approach would be to have a pseudo-user for for whatever
facility you were creating, and a _short_, _auditable_ setuid program,
without shell escapes and other similar nonsense, to deposit things in
the spool directory.  If you need to put a fancy user-interface on it,
build the user interface as a separate process and have it fire up a
setuid backend process to do the `real work'.

					- Bill