Date: Tue, 27 Feb 2001 16:50:40 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> Cc: Kris Kennaway <kris@FreeBSD.ORG>, Terry Lambert <tlambert@primenet.com>, "Jacques A. Vidrine" <n@nectar.com>, arch@FreeBSD.ORG Subject: Re: rand(3) (was Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <p05010408b6c1c0453bd0@[128.113.24.47]> In-Reply-To: <200102271952.f1RJqSs35224@cwsys.cwsent.com> References: <200102271952.f1RJqSs35224@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:51 AM -0800 2/27/01, Cy Schubert wrote: ><... putting my manager's hat on> >... Could we not implement a solution similar to malloc()'s >/etc/malloc.conf and MALLOC_OPTIONS? The default could be set to >rand() calling random(), while setting the appropriate option would >revert to the "old" behaviour. Or, #ifdef. Either way we satisfy >both camps. I suspect that is unworkable. If there is some security issue where it is important that rand = random, then you won't want that security diluted if someone setting an environment variable... (I might set the environment variable because of my simulation written in fortran, and have it then effect some other program which I am also running, where it is a security issue). Something #ifdef-ish might be workable to everyone's satisfaction. ><putting my security administrator's hat back on> >Ideally, rand() is insecure and should be removed or should call >random(), protecting clueless developers from themselves and more >importantly protecting clueless end users from clueless developers. > >We three choices: > >1. Status quo. >2. A more secure rand(). >3. A hybrid. Well, I've been trying to sit here and think of a good hybrid solution, but for the last hour I've been interrupted every 2 minutes with something or another. Perhaps some warning at compile time, except I can't quite think of how to do that. I can imagine something silly at link time, such that references to 'rand' generate an warning like mktemp. People who want statistically-random numbers would avoid that by changing the source so they get random instead of rand. People who want the historical rand behavior would '#define randold rand' (where randold is a duplicate of rand), thus avoiding the direct reference to rand at load time. Anything where calling 'rand' is a security risk is hopefully something that is compiled often enough that this would quickly address that issue. I can't stop today's interruptions long enough to tell if I really like the above idea, but at first blush it sounds plausible. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05010408b6c1c0453bd0>