Paul de Weerd wrote, On 08/15/14 14:51:
At any rate, this changes that to allow world readable files (still
not taking world writable files). We can't check S_IWOTH over tftp,
we should probably assume 0777 for files transferred that way. But,
if you're trusting the kernel you're getting over tftp, then why the
hell are you not trusting random.seed? That attacker that could maybe
influence your randomness would NEVER touch your kernel to ensure it
only produces well known (to them) randomness. That would be way too
easy...
Good point.
Index: boot.c
===================================================================
RCS file: /cvs/src/sys/stand/boot/boot.c,v
retrieving revision 1.43
diff -u -p -r1.43 boot.c
--- boot.c 19 Feb 2014 22:02:15 -0000 1.43
+++ boot.c 15 Aug 2014 21:41:01 -0000
@@ -153,7 +153,7 @@ loadrandom(char *name, char *buf, size_t
}
if (fstat(fd, &sb) == -1 ||
sb.st_uid != 0 ||
- (sb.st_mode & (S_IWOTH|S_IROTH)))
+ (sb.st_mode & (S_IWOTH)))
goto fail;
(void) read(fd, buf, buflen);
fail:
Nonetheless, on a generally secure internal network it's a benefit to
have this the extra random source. But if it doesn't exist or it is
known to the world, like Theo previously said, "it isn't worse."
The only downside is if the random.seed was used in a compromise of the
PRNG of the client (not sure if that's possible). But then I guess I
revert to Paul's point above.
