Am Freitag, 11. Juni 2021, 05:59:52 CEST schrieb Sandy Harris: Hi Sandy, > The basic ideas here look good to me; I will look at details later. > Meanwhile I wonder what others might think, so I've added some to cc > list. > > One thing disturbs me, wanting to give more control to > "the user who should be free to choose their own security/performance > tradeoff" > > I doubt most users, or even sys admins, know enough to make such > choices. Yes, some options like the /dev/random vs /dev/urandom choice > can be given, but I'm not convinced even that is necessary. Our > objective should be to make the thing foolproof, incapable of being > messed up by user actions. Thank you for your considerations. I would think you are referring to the boottime/runtime configuration of the entropy sources. I think you are right that normal admins should not have the capability to influence the entropy source configuration. Normal users would not be able to do that anyway even today. Yet, I am involved with many different system integrators which must make quite an effort to adjust the operation to their needs these days. This includes adding proprietary patches. System integrators normally would compile their own kernel, I would see no problems in changing the LRNG such that: - the entropy source configuration is a compile time-only setting with the current default values - the runtime configuration is only enabled with a compile time option that is clearly marked as a development / test option and not to be used for runtime (like the other test interfaces). It would be disabled by default. Note, I have developed a regression test suite to test the LRNG operation and behavior. For this, such boottime/runtime settings come in very handy. Regular administrators would not recompile their kernel. Thus Linux distros would simply go with the default by not enabling the test interface and have safe defaults. This implies that normal admins do not have the freedom to make adjustments. Therefore, I think we would have what you propose: a foolproof operation. Yet, people who really need the freedom (as otherwise they will make some other problematic changes) have the ability to alter the kernel compile time configuration to suit their needs. Besides, the LRNG contains the logic to verify the settings and guarantee that wrong configurations cannot be applied even at compile time. The term wrong configuration refers to configurations which would violate mathematical constraints. Therefore, the offered flexibility is still ensuring that such integrators cannot mess things up to the extent that mathematically something goes wrong. On the other hand, when you refer to the changing of the used cryptographic algorithms, I think all offered options are per definition safe: all offer the same security strength. A configuration of the cryptographic algorithms is what I would suggest to allow to administrators. This is similar to changing the cryptographic algorithms for, say, network communication where the administrator is in charge of configuring the allowed / used cipher suites. Ciao Stephan
