Re: Is fork() hook ever possible?

From: Oliver Pinter <oliver.pntr_at_gmail.com>
Date: Tue, 15 Nov 2011 02:11:03 +0100
On 11/15/11, Andrey Chernov <ache_at_freebsd.org> wrote:
> On Mon, Nov 14, 2011 at 06:08:55PM -0500, David Schultz wrote:
>> Not quite.  OpenBSD's implementation is more careful.  I just
>> noticed a funny thing about FreeBSD's KERN_ARND sysctl: If the
>> random device isn't (or can't be) loaded, KERN_ARND silently
>> decides to initialize itself with the output of random().  This
>> means that whatever minuscule amount of entropy it might have
>> picked up from the clock is reduced to a maximum of 31 bits.
>> That's a fantastic way to provide a false sense of security...
>
> I agree.
>
> Lets separate two things: "no /dev/random for jails" and "no random kernel
> module is loaded".
> IMHO kernel module should _not_ be optional anymore, it solves problem you
> describe and all similar problems at once.
>
> Adding KERN_ARND to arc4random() at this moment solves "no /dev/random for
> jails" problem alone and _not_ pretends to solve "no random kernel module
> is loaded" problem. When random kernel module will become non-optional,
> KERN_ARND automagically makes good security in that place too.
>
> P.S. Do I answer your doubts about &rdat key initialization in my prev.
> posting?

I think it's a much correct solution, rather than the original patch,
while it initializes the whole structure, not only the key array...
(&rdat.key vs &rdat; and uninitialized pid and tv):

 	fd = _open(RANDOMDEV, O_RDONLY, 0);
 	done = 0;
 	if (fd >= 0) {
-		if (_read(fd, &rdat, KEYSIZE) == KEYSIZE)
+		if (_read(fd, &rdat, sizeof(rdat)) == sizeof(rdat))
 			done = 1;
 		(void)_close(fd);
-	}
+	}



>
> --
> http://ache.vniz.net/
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
Received on Tue Nov 15 2011 - 00:11:06 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:20 UTC