openssl inside a chroot

问题:

I'm getting the following error when I try to make an ssl connection from inside a chroot jail:

twisted.internet.error.ConnectionLost: Connection to the other side was lost in a non-clean fashion.

I'm using the openssl 0.9.6 with pyopenssl to make the ssl connection and I'm using the twisted python library for python 2.4 on Linux (centos 5.5).

After some troubleshooting I've discovered that openssl is failing because it is trying to read the /dev/random file and it is failing because there is no /dev/random inside the chroot. I've confirmed that if I create a /dev/random file inside the chroot the connection succeeds.

• I've thought about mounting devfs filesystem which contains the /dev/random file inside my chroot but my app and it's sysadmins have a bad habit of deleting the root of the chroot without unmounting everything first.
• I've thought about reading from the /dev/random file before I do the chroot but my current setup is to call chroot before my binary is even started, and changing where the chroot happens would be a too big of a change in the app that I'm not sure when or how it could be done.
• I've thought of running a program outside my chroot jail that just reads from /dev/random and writes into a named file pipe called /jail/dev/random tht is accessible from inside the chroot jail but I don't like having to run a separate process just for having access to a source of randomness. Also it seems overly complicated for just initializing openssl.

What is the right way to initialize openssl if I don't have access to /dev/random from my program?

回答1:

Perhaps a better way is to bind-mount the device files as follows:

# touch chroot/dev/random
# mount --bind /dev/random chroot/dev/random

and the same for urandom.

回答2:

You could fake random for openssl, e.g. command-line openssl:

[root@quilt /]# openssl s_client -h
usage: s_client args
...
 -rand file:file:...
...

Anyhow openssl needs a source of randomness, it cannot be secure without random nonce, e.g. from wikipedia:

In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key and sends the result to the server. Only the server should be able to decrypt it, with its private key.

Without source of randomness, SSL/TLS can be easily hacked.

If you are worried that chroot/dev/ can be deleted, why not create only chroot/dev/random or chroot/dev/urandom intead of mounting whole dev?

[root@quilt /]# mknod /dev/random c 1 8
[root@quilt /]# mknod /dev/urandom c 1 9

Oh, btw you also want to copy system /etc/resolv.conf and possibly other hosts, services, ethers, etc...

回答3:

Don't forgot about SELinux after create urandom and random

cat /var/log/messages | grep "SELinux is preventing"

SELinux is preventing /usr/sbin/php-fpm from read access on the chr_file urandom.

If you believe that php-fpm should be allowed read access on the urandom chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do allow this access for now by executing:

ausearch -c 'php-fpm' --raw

audit2allow -M my-phpfpm

semodule -i my-phpfpm.pp