chroot 内的 openssl

发布于 2024-12-22 01:57:49 字数 856 浏览 5 评论 0原文

当我尝试从 chroot 监狱内部建立 ssl 连接时,出现以下错误:

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

我正在使用 openssl 0.9.6 和 pyopenssl 来建立 ssl 连接,并且我正在使用用于 python 2.4 的twisted python 库Linux(centos 5.5)。

经过一些故障排除后,我发现 openssl 失败是因为它试图读取 /dev/random 文件,而失败是因为 chroot 中没有 /dev/random 。我已经确认,如果我在 chroot 中创建 /dev/random 文件,连接就会成功。

  • 我考虑过安装 devfs 文件系统,其中包含我的 chroot 中的 /dev/random 文件,但我的应用程序及其系统管理员有一个坏习惯,即删除 chroot 的根目录而不首先卸载所有内容。
  • 我考虑过在执行 chroot 之前从 /dev/random 文件中读取内容,但我当前的设置是在二进制文件启动之前调用 chroot,并且更改 chroot 发生的位置将对应用程序进行太大的更改我不确定何时或如何完成它。
  • 我想过在 chroot 监狱外运行一个程序,该程序仅从 /dev/random 读取并写入名为 /jail/dev/random 的命名文件管道,可以从 chroot 监狱内部访问它,但我不喜欢这样做运行一个单独的进程只是为了访问随机源。而且,仅仅初始化 openssl 似乎过于复杂。

如果我无法从程序中访问 /dev/random ,初始化 openssl 的正确方法是什么?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

说好的呢 2024-12-29 01:57:50

您可以为 openssl 伪造随机数,例如命令行 openssl:

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

无论如何 openssl 需要随机源,没有随机数它就不可能安全,例如来自维基百科:

为了生成用于安全连接的会话密钥,
客户端使用服务器的公钥加密随机数,并且
将结果发送到服务器。只有服务器应该能够
使用私钥对其进行解密。

如果没有随机源,SSL/TLS 很容易被黑客攻击。

如果您担心 chroot/dev/ 会被删除,为什么不只创建 chroot/dev/randomchroot/dev/urandom安装整个开发?

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

哦,顺便说一句,您还想复制系统 /etc/resolv.conf 以及可能的其他主机、服务、以太坊等...

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...

-黛色若梦 2024-12-29 01:57:50

创建 urandom 和 random 后不要忘记 SELinux

cat /var/log/messages | grep“SELinux 正在阻止”

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

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

┈┾☆殇 2024-12-29 01:57:49

也许更好的方法是按如下所示绑定挂载设备文件:

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

urandom 也是如此。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文