Path: utzoo!attcan!uunet!samsung!usc!snorkelwacker!bloom-beacon!eru!luth!sunic!dkuug!freja.diku.dk!skinfaxe.diku.dk!seindal From: seindal@skinfaxe.diku.dk (Rene' Seindal) Newsgroups: comp.unix.questions Subject: Re: Setuid programs Keywords: suid Message-ID: <1990Mar21.143425.11732@diku.dk> Date: 21 Mar 90 14:34:25 GMT References: <1990Mar16.224120.24013@aucs.uucp> <14644@phoenix.Princeton.EDU> Sender: news@diku.dk (The Netnews System) Organization: Department Of Computer Science, University Of Copenhagen Lines: 55 subbarao@phoenix.Princeton.EDU (Kartik Subbarao) writes: > In article <1990Mar16.224120.24013@aucs.uucp> 852028e@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@diku.dk)