Re: [openssl-project] Random devices in chroot environments revisited

2018-10-30 Thread Dr. Matthias St. Pierre


> > ... currently there are two alternative approaches for doing it:
> >
> > #7429 - Conditionally open random devices on initialization
> > #7437 - rand_unix.c: open random devices on first use only
> > ...
> > *  Pull request #7429 fixes the opt-out issue but remains along the lines of
> > the initial solution #7432. ...
> >
> > *  Pull request #7429 works without explicit opt-out, because it opens the
> > random devices on first use only ...
> 
> #7437 I guess

Yes, thanks for the correction. A typical copy error. 

Matthias

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Random devices in chroot environments revisited

2018-10-30 Thread Kurt Roeckx
On Tue, Oct 30, 2018 at 07:23:52PM +, Dr. Matthias St. Pierre wrote:
> Hi,
> 
> I'd like to recall that the following issue
> 
> #7419 - RAND_keep_random_devices_open not working
> 
> still needs to be fixed until 1.1.1a and that currently there are two
> alternative approaches for doing it:
> 
> #7429 - Conditionally open random devices on initialization
> #7437 - rand_unix.c: open random devices on first use only 
> 
> A short recall of the background story: In pull request
> 
> #6432 - Keep /dev/random open for seeding
> 
> a regression was fixed that affected applications in chroot environments.
> It compensated the fact that the new OpenSSL CSPRNG now reseeds
> periodically, which the previous one didn't.
> 
> The solution was to open all random devices early and keep them
> open.  An API call (RAND_keep_random_devices_open()) was added
> for the application to opt-out from this behaviour.
> 
> In issue #7419 it was reported that this opt-out did not work as expected.
> 
> *  Pull request #7429 fixes the opt-out issue but remains along the lines of
> the initial solution #7432. This approach has the side effect that the
> random devices are always opened, even if they are never used
> (for example, because getrandom() is available). Even more, if the
> application forks and execs, these handles will be left open and unused
> in the child process.
> 
> An application which does not want this behavior, could explicitly 
> opt-out,
> but this would require a recompilation, which is somewhat contrary to
> the assumptions of the initial chroot problem.
> 
> *  Pull request #7429 works without explicit opt-out, because it opens the

#7437 I guess

> random devices on first use only (and then keeps them open, unless
> the opt-out was called). The advantage of this approach: If getrandom()
> is available and working, the opening will never happen.
> 
> The lazy opening does not add a regression for applications compiled
> against 1.1.0, because the old SSLEAY CSPRNG used to be initialized 
> on first use, too. So also with 1.1.0 it was necessary to initialize the
> CSPRNG properly before chrooting (unless the random device was
> mounted into the chroot jail).
> 
> Your thoughts?

I prefer the option where it doesn't get opened if getrandom() is
avialable.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[openssl-project] Random devices in chroot environments revisited

2018-10-30 Thread Dr. Matthias St. Pierre
Hi,

I'd like to recall that the following issue

#7419 - RAND_keep_random_devices_open not working

still needs to be fixed until 1.1.1a and that currently there are two
alternative approaches for doing it:

#7429 - Conditionally open random devices on initialization
#7437 - rand_unix.c: open random devices on first use only 

A short recall of the background story: In pull request

#6432 - Keep /dev/random open for seeding

a regression was fixed that affected applications in chroot environments.
It compensated the fact that the new OpenSSL CSPRNG now reseeds
periodically, which the previous one didn't.

The solution was to open all random devices early and keep them
open.  An API call (RAND_keep_random_devices_open()) was added
for the application to opt-out from this behaviour.

In issue #7419 it was reported that this opt-out did not work as expected.

*  Pull request #7429 fixes the opt-out issue but remains along the lines of
the initial solution #7432. This approach has the side effect that the
random devices are always opened, even if they are never used
(for example, because getrandom() is available). Even more, if the
application forks and execs, these handles will be left open and unused
in the child process.

An application which does not want this behavior, could explicitly opt-out,
but this would require a recompilation, which is somewhat contrary to
the assumptions of the initial chroot problem.

*  Pull request #7429 works without explicit opt-out, because it opens the
random devices on first use only (and then keeps them open, unless
the opt-out was called). The advantage of this approach: If getrandom()
is available and working, the opening will never happen.

The lazy opening does not add a regression for applications compiled
against 1.1.0, because the old SSLEAY CSPRNG used to be initialized 
on first use, too. So also with 1.1.0 it was necessary to initialize the
CSPRNG properly before chrooting (unless the random device was
mounted into the chroot jail).

Your thoughts?

Matthias

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project