[13799] in bugtraq
Re: Tempfile vulnerabilities
daemon@ATHENA.MIT.EDU (Horst von Brand)
Thu Feb 10 17:54:08 2000
Message-Id: <200002091403.LAA17597@sleipnir.valparaiso.cl>
Date: Wed, 9 Feb 2000 11:03:11 -0300
Reply-To: Horst von Brand <vonbrand@SLEIPNIR.VALPARAISO.CL>
From: Horst von Brand <vonbrand@SLEIPNIR.VALPARAISO.CL>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Message from Seth David Schoen <schoen@LOYALTY.ORG> of "Mon, 07
Feb 2000 16:01:21 -0800." <20000207160121.V4856@cty-alum.org>
Seth David Schoen <schoen@LOYALTY.ORG> said:
[...]
> An intermediate possibility is to have multiple RNGs with multiple sources
> of entropy, or multiple RNGs with entropy divided among them somehow, or
> a single RNG which enforces a reasonable policy of some sort when multiple
> processes want to access it at once.
Linux has /dev/random (real random) and /dev/urandom (generated with help
of a RNG if not enough entropy in /dev/random). Just shut off people from
using /dev/random.
> Modern multiuser operating systems have solved all _kinds_ of problems around
> concurrency and dealing with contention over a shared resource. There is
> no reason that they should not be able to do exactly the same thing for an
> entropy pool, if it becomes an issue.
The problem here is not a shared resource, it is a finite resource. And
solutions there (f.ex. disk space) are quotas or manual intervention. Sou
you'd have a /etc/random.quotas file saying which UID is allowed to use how
much entropy, and the kernel keeps track from there after being primed on
boot. Yuck.
--
Horst von Brand vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viqa del Mar, Chile +56 32 672616
