Setuid programs

[Rene' Seindal]

subbarao at phoenix.Princeton.EDU (Kartik Subbarao) writes:

> In article <1990Mar16.224120.24013 at aucs.uucp> 852028e at aucs.UUCP (Amari  M.  Elammari) writes:
> >
> >Does anybody know about any good references for:
> >
> > - How to write a setuid programs.
> > - What are the security problems with suid programs.
> > - Anything about suid programs...
> >

> b) Security Questions - Quite a lot! You can perhaps think of many, as your
>    program has all of your privileges while being run. Please refer to Kochan
>    and Wood for more details as to how to design leak-proof setuid programs.

I have never seen Kochan and Wood (does anybody have a precise
reference?), but here is what I can immediately think of when writing
setuid programs.  There are probably loads of other things to remember,
so if anyone would comment or add to this list?


* Check that the caller are allowed to call the program.  Never expect
it to be installed with the right permissions, i.e., if setuid to root,
and wanted available only to users in group wheel, check for wheel
membership explicitly.  Don't expect to be owned by root, in group
wheel, and modes 4550.

* Don't give usage messages.  It will only help the bad guys.  Just exit
or say "Permission denied."

* Always initialise the environment completely yourself.  If necessary,
scan the old environment, and transfer the needed values after they have
been validated.  Set USER and HOME from the real uid and the passwd
file, check that TERM is a valid terminal name (if you use it), always
set SHELL to either /bin/sh or a non-existent name, and ALWAYS
initialise PATH to contain only `safe' directories.  Never make you
setuid program customisable through environment variables.  Instead, use
a configuration file in a safe directory.

* Don't forget to set the umask explicitly.  You probably don't want
world writable files left behind in case of abnormal termination.

* Dispose of your privileges as soon as possible.  If you only need the
privileges to open a protected file, or bind a socket to a privileged
port, dispose of the no longer needed privileges immediately afterwards.

* If you have file discriptors to protected files og privileged sockets,
remember to make them `close-on-exec', so programs exec'ed by child
processes won't inherit them.

* Perform all operations with a minimum of privilege.  This can often be
achieved by `swapping' uids or gids at the appropriate times.


Rene' Seindal (seindal at diku.dk)