[openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Fri, Aug 18, 2017 at 09:22:48AM +0200, Tomas Mraz wrote:
> On Thu, 2017-08-17 at 22:11 +0200, Kurt Roeckx wrote:
> > On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote:
> > > On Thu, 2017-08-17 at 12:22 +0000, Salz, Rich via openssl-dev
> > > wrote:
> > > > I understand the concern.  The issue I am wrestling with is
> > > > strict
> > > > compatibility with the existing code.  Does anyone really *want*
> > > > the
> > > > RNG’s to not reseed on fork?  It’s hard to imagine, but maybe
> > > > somewhere someone is.  And then it’s not about just reseeding,
> > > > but
> > > > what about when (if) we add other things, like whether or not the
> > > > secure arena gets zero’d in a child?
> > > > 
> > > > So let me phrase it this way:  does anyone object to changing the
> > > > default so NO_ATFORK must be used to avoid the reseeding and
> > > > other
> > > > things we might add later?
> > > 
> > > I can hardly see anyone would be broken if the default is to reseed
> > > RNG on fork. However that might not be true for other atfork
> > > functionalities so perhaps there is a need to make each of these
> > > future
> > > atfork functions configurable and either on or off by default
> > > individually and not as a whole.
> > 
> > There might be cases where after fork you're not able to get to
> > /dev/urandom anymore.
> 
> I do not think so. Which particular cases do you have on mind? Yes,
> after fork+exec you could for example switch SELinux domain and won't
> be able to access something but immediately after fork it should not be
> so. Also perhaps the reseeding after fork can be made less strict in
> regards to failures reading /dev/urandom or so.

It seems to me this all depends on the order of things you do to
create a daemon. You could make sure the RNG is inited, chroot,
and then fork for instance. And I suspect there are actually
programs that do it in that order.


Kurt