Re: [gentoo-hardened] Entropy Management?

[Matthew Thode]

On 09/18/2012 06:27 PM, Walter Stanish wrote:
> 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
>

Like you said, there are some entropy gathering daemons (I use em in
VMs), so that's a good place to start I think.  After that, I would
probably go with some hardware rng solution if you determine this to be
that much of a risk.

Since you can keep http connections open for long periods of time with
HTTP/1.1 that can also be used to help mitigate some exhaustion (rate
limit people).  In fact, rate limiting in general is probably good.

-- 
-- Matthew Thode (prometheanfire)