Phillip Susi wrote:
>David Wagner wrote:
>> Nope, I don't think so. If they could, that would be a security hole,
>> but /dev/{,u}random was designed to try to make this impossible, assuming
>> the cryptographic algorithms are secure.
>>
>> After all, some of the entropy sources come from untrusted sources and
>> could be manipulated by an external adversary who doesn't have any
>> account on your machine (root or non-root), so the scheme has to be
>> secure against introduction of maliciously chosen samples in any event.
>
>Assuming it works because it would be a bug if it didn't is a logical
>fallacy. Either the new entropy pool is guaranteed to be improved by
>injecting data or it isn't. If it is, then only root should be allowed
>to inject data. If it isn't, then the entropy estimate should increase
>when the pool is stirred.
Sorry, but I disagree with just about everything you wrote in this
message. I'm not committing any logical fallacies. I'm not assuming
it works because it would be a bug if it didn't; I'm just trying to
help you understand the intuition. I have looked at the algorithm
used by /dev/{,u}random, and I am satisfied that it is safe to feed in
entropy samples from malicious sources, as long as you don't bump up the
entropy counter when you do so. Doing so can't do any harm, and cannot
reduce the entropy in the pool. However, there is no guarantee that
it will increase the entropy. If the adversary knows what bytes you
are feeding into the pool, then it doesn't increase the entropy count,
and the entropy estimate should not be increased.
Therefore:
- It is safe to allow non-root users to inject data into the pool
by writing to /dev/random, as long as you don't bump up the entropy
estimate. Doing so cannot decrease the amount of entropy in the
pool.
- It is not a good idea to bump up the entropy estimate when non-root
users write to /dev/random. If a malicious non-root user writes
the first one million digits of pi to /dev/random, then this hasn't
increased the uncertainty that this attacker has in the pool, so
you shouldn't increase the entropy estimate.
- Whether you automatically bump up the entropy estimate when
root users write to /dev/random is a design choice where you could
reasonably go either way. On the one hand, you might want to ensure
that root has to take some explicit action to allege that it is
providing a certain degree of entropy, and you might want to insist
that root tell /dev/random how much entropy it added (since root
knows best where the data came from and how much entropy it is likely
to contain). On the other hand, you might want to make it easier
for shell scripts to add entropy that will count towards the overall
entropy estimate, without requiring them to go through weird
contortions to call various ioctl()s. I can see arguments both
ways, but the current behavior seems reasonable and defensible.
Note that, in any event, the vast majority of applications should be
using /dev/urandom (not /dev/random!), so in an ideal world, most of
these issues should be pretty much irrelevant to the vast majority of
applications. Sadly, in practice many applications wrongly use
/dev/random when they really should be using /dev/urandom, either out
of ignorance, or because of serious flaws in the /dev/random man page.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
