Hi there, This is a bit general, rather than a specific suggestion, since I don't think I can make tomorrow's meeting maybe people might like to discuss it there.
Reading the more recent OpenSSL man page it occurred to me that there may be a potential with some types of daemons (such as recent OpenSSL run with the 2.x default of --key-method 2) to facilitate remote system entropy exhaustion as a type of DoS. I am aware of entropy gathering daemons but none so much for entropy as an input to overall system management (connection throttling, control group freezing, etc.). Has there been any attempt to integrate system entropy management with any major Linux distribution? Has Gentoo hardened looked at entropy impact of various packages? I think there could be some research potential here. The first step might be to establish suitably automated mechanisms for formal testing of package / package revision entropy impact under various test loads, with a view towards enhancing the visibility and ease of entropy management across hardened gentoo systems. - I'm not sure if there is an automated test suite set up within the Gentoo infrastructure at present, though some packages have built-in tests, and some packages have a USE flag to enable/disable these, it seems difficult to re-run these tests after packages are emerged. - There are also more general testing tools such as the Apache Project's 'ab' and 'bonnie++' that could be used for some types of packages. Whilst it is easily possible to monitor entropy over time (eg: using rrdtool configured to source data from /proc/sys/kernel/random/entropy_avail) I have never heard of any attempt to monitor this availability over time and integrate it in to system management. I have however heard of problems with relatively commonly deployed daemons (I forget which now, but not so long ago it happened to me too) wherein entropy exhaustion causes a complete functional DoS for a process blocking for unavailable entropy. Perhaps a new control group implementation for maximum entropy draw rate per namespace might also be a useful contribution to the kernel? I suppose this sort of thing is tending to increase in importance as the density of services per physical system increases under the continuing trend towards high density virtual hosting (either container based or paravirtualized). First post here ... hope I'm not completely off track with this, just throwing the idea out there. Cheers, Walter
