Date: Thu, 09 Jan 1997 23:18:24 -0700 From: Warner Losh <imp@village.org> To: Steve Reid <steve@edmweb.com> Cc: freebsd-security@freebsd.org Subject: Re: Obvious fix for tempfile race conditions? Message-ID: <E0viaIK-0006bf-00@rover.village.org> In-Reply-To: Your message of "Thu, 09 Jan 1997 22:06:54 PST." <Pine.BSF.3.95.970109214858.1613A-100000@bitbucket.edmweb.com> References: <Pine.BSF.3.95.970109214858.1613A-100000@bitbucket.edmweb.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.3.95.970109214858.1613A-100000@bitbucket.edmweb.com> Steve Reid writes: : Just because it _can_ be done safely doesn't mean that it _is_ being : done safely. But it *IS* being done safely on OpenBSD. I see no reason why it can't be so on FreeBSD. The example you cited was just security ignorance on the part of the /etc/security writer. For example, I have /tmp not on my root, but on my /usr, so /tmp itself is a symlink. This proposed change would work only for systems that had /tmp being its own partion. Other systems would still be volunerable because we can't disable symlinks on / w/o breaking a whole lot of things (remote dumping, and termcap come to mind). In addition, it is nice to have things like tftpboot not on /, but pointing off somewhere else. : I'd bet there are other, less obvious problems in other programs. You are right. I have some changes in my queue to fix that however. : Disabling symlinks in /tmp would greatly reduce a cracker's options. Not really. There are so many holes in FreeBSD right now, I doubt it would slow them down much. Holes I'm working on closing, BTW. Here "so many" mean "at least one known that gives you root." It's a nice idea to have the kernel somehow magically solve the problems of security, but often times there is no substitute for good coding habits. Paraphrasing Brooks, There are no silver bullets in security. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0viaIK-0006bf-00>