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