852028e@aucs.uucp (Amari M. Elammari) (03/17/90)
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... Thank you Amari -- Amari Elammari. Acadia University, Wolfville, N.S., Canada P.O.BOX 1236 Wolfville, N.S. Canada BOP 1X0 BITNET 852028e@Acadia Internet 852028e@AcadiaU.CA
subbarao@phoenix.Princeton.EDU (Kartik Subbarao) (03/18/90)
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... > a) Writing a SUID program is no different from writing a normal program. The only difference is upon execution, the program will run as your userid (i.e. have all privileges that you do). For example, if you wanted to write a game, and wanted users to only have access to the high score list when they played the game, you could make the game SUID to you, and simply write to the file during the game. Also, /bin/su and other programs are setuid to root, for need of permission. As to the mechanics of CREATING a suid program, just do chmod u+s <filename> to give set user id, and chmod g+s to give set group id. (Thats 4xxx and 2xxx for you octal fans.) 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. -Kartik -- subbarao@{phoenix,bogey or gauguin}.princeton.edu - Internet subbarao@pucc.princeton.edu - Bitnet
seindal@skinfaxe.diku.dk (Rene' Seindal) (03/21/90)
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)