Thanks to everyone who replied.
I received a couple of reminders that this is not a programming forum.
However, since system administration often involves programming in order to
automate mundane tasks, I thought that this forum would have been acceptable.
I will refrain from programming posts in the future. I am sorry for any
inconveniences.
Since I am already wasting network resources with this apology, here is the
summary. I haven't had time to verify the web sites yet, so happy hunting.
Sources:
AROSSITE @ us.oracle.com ("Bruce Rossiter")
jstanley @ pcagent.com
mhkohne @ moberg.com (Michael Kohne)
benites @ tryon.cs.unca.edu (Robert Benites)
tel1dvw @ is.ups.com (dave)
vogelke @ c17mis.region2.wpafb.af.mil ("Karl E. Vogel")
cyucel @ is.ku.edu.tr (Cagri Yucel)
jefi @ kat.ina.de (Jens Fischer)
peter.allan @ aeat.co.uk (Peter M Allan)
1. The article I was looking for by Bishop was in the USENIX newsletter in
1987:
Bishop, Matt. "How to Write a Setuid Program." ;login: 12, 1 (Jan/Feb
1987): 5-12.
2. Check out the Chapter in Practical Unix and Internet Security by O'Reilly
3. Good info in Advanced Unix Programming by the TCP/IP and Unix Net
Programming Guru Richard Stevens
4. More info at ftp.uu.net/pub/published
5. More info at http://www.unix.geek.net/~arny/info/library_25.html
6. More info at
ftp://ftp.auscert.org.au/pub/auscert/papers/secure_programming_checklist
7. Friendly advice from a contributor
Don't read random-sized input into a fixed size buffer. Always make sure
your reads will truncate the input, preventing buffer over-runs.
This means you shouldn't use any C library function which might have an
internal buffer, or which uses a user-supplied buffer without havin anyway
to know how big it is. 'gets' is especially vulnerable, as are several
other functions. Basically, you need to think about each library function
and say to yourself 'If I had to implement that, might I do with a static
buffer of some sort?' If the answer is yes, don't use it.
My other piece of advise is to keep the setuid part of the program down to
a minimum. The setuid portion of things is the one the crackers are after,
and the more complex it is, the more likely it is them will find a way to
compromise it, despite your best efforts. If you can arrange things so that
most of the actual processing is done at a lower effective UID, so much the
better. (Of course, proper management of any UID switches within the
program is needed).
8. See the Man Page from COPS on setuid
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:48 CDT