使用/ dev / urandom生成的秘密令牌是保护守护进程的好方法吗？

Question

我有一个守护进程，可以生成子进程。有时这些子进程需要与守护进程通信。我想确保只有这些子进程被授权与守护进程通信。

我想按如下方式实现：

• 在启动期间，守护程序通过读取/ dev / urandom生成一个随机的128字节密钥令牌。 / dev / random是不好的，因为它可能会阻止读者任意一段时间。
• 守护进程侦听Unix域套接字。
• 守护进程将秘密令牌和套接字的文件名放在环境变量中。它产生的每个子进程都可以使用文件名和秘密令牌连接到守护进程。
• 除非秘密令牌正确，否则守护程序会拒绝连接。

问题：

• 我知道/ dev / random比/ dev / urandom具有更高的熵。但/ dev / urandom足够好吗？如果没有，我应该使用什么？
• 令牌的大小是否足够大？
• 我应该锁定存储令牌的内存吗？我不认为这是必要的，因为守护进程每次启动时都会生成一个不同的令牌，所以当攻击者设法窃取硬盘并从交换文件中提取令牌时，它应该已经没用了。
• 我应该在关机期间使存储令牌的内存无效吗？
• 我还应该做什么？

由于各种要求，我不能使用匿名管道来允许守护进程和子进程之间的通信。

Answer 1

最简单的方法是在服务器中为每个子进程简单地创建一个管道/套接字对。给一个子进程一端并保持另一端。该管道/套接字上的任何内容都必须来自该子进程。

另一种方法是向操作系统询问Unix套接字的凭证（pid，uid，gid）。在Linux上，您将使用getsockopt(sock, SOL_SOCKET, SO_PEERCRED, &cr, &cr_len)（man 7 socket）。 Solaris有getpeerucred。不幸的是，这不是可移植的，但许多系统具有类似的Unix套接字功能。虽然它很复杂，但D-Bus包含code that does this on a number of different systems。

Answer 2

好吧，如果您要将令牌放入环境变量中，那么具有与这些进程相同或更高权限（即UID）的任何人都可以读取然后使用该令牌！这有点让问题的其余部分成为一个有争议的问题！？如果您担心同一个盒子上的进程之间的安全性（您谈到本地IPC），那么不要使用环境变量来存储令牌 - 很容易检查这些（EV）。

Answer 3

如果你正在分叉（但不是exec（）），只需将它们保存在本地内存就足够了。如果你也是exec（）ing，你可能（正如你在Jim的评论中所述）必须通过管道传递令牌（和域套接字路径）。

如果你在无头服务器上运行它，/ dev / random可能有点饿，所以使用/ dev / urandom（可能）会是一个更好的选择，除非你有一个合适的噪声源来提供/ dev / random with。

Answer 4

是的，/ dev / urandom提供的安全性非常好。许多软件将其用于随机性（用于SSL，身份验证等）。几乎唯一的时间/ dev / random是一个好主意，当生成某种需要多年安全的令牌时，例如证书的私钥。

如果你有相同的UID，有人提到了查看进程内存的能力。你可以通过让内核认为它是一个setuid进程来避免这种情况，即如果主进程以root身份运行，你可以fork，exec和setuid（）给非特权用户。具有相同UID的其他进程将无法查看该进程的内存。

凭据查找方法也适用于命名的UNIX套接字，而不仅仅是套接字对。