On Thu, Nov 23, 2000 at 07:40:45PM -0400, Peter Cordes wrote: > On Thu, Nov 23, 2000 at 05:50:06PM -0500, Daniel Burrows wrote: > > On Thu, Nov 23, 2000 at 06:35:54PM -0400, Peter Cordes <[EMAIL PROTECTED]> > > was heard to say: > > > > ghostscript uses temporary files to do some of its work. Unfortunately > > > > the method used to create those files wasn't secure: mktemp was used > > > > to create a name for a temporary file, but the file was not opened > > > > safely. > > > There seems to be a lot of this going on. Is it possible to modify glibc > > > so that it flags dangerous actions with stuff in /tmp?
To be a bit pedantic, one can argue that only checking in glibc calls risks missing problems - programs aren't compelled to go through glibc's wrappers. Personally I compile my own kernel and not my own glibc, so I prefer a kernel patch anyway. > > When I link aptitude, I get a warning about "mktemp is insecure and > > should not be used". > > So I think something like this is already done somewhere. > > Yeah, that's at link time. gcc (or ld I guess) warns about gets(), too. Hmm, since when did Debian ld get BSD-like linker warnings? > I was thinking a runtime check would be useful, since then you could actually > check whether the argument was a private directory or a publicly-writable > one like /tmp, and be fairly sure you weren't seeing false alarms. I use a kernel patch; after some refinement I got it to the point where it can accurately identify unsafe file accesses. http://members.nbci.com/colin_phipps/cph4.diff.txt (against kernel v2.2.17ish) It errs on the side of not returning false positives; it logs to syslog any file open(2) such that: - it's in a world writable directory - O_EXCL not specified - file doesn't exist. It's crude but turns up a lot of problems. Don't be surprised to find your syslog busier if you try it, some programs are very bad about temp files :-( (cvs is a bad culprit for instance). -- Colin Phipps http://www.netcraft.com/