依靠 /proc/[pid]/status 检查另一个进程的身份答案

【问题标题】：Relying on /proc/[pid]/status for checking another process' identity依靠 /proc/[pid]/status 检查另一个进程的身份
【发布时间】：2014-08-24 22:28:06
【问题描述】：

最近我发现需要检查我的服务通过 IPC 与之交互的进程是否具有足够的特权来执行某些事务。我拥有的关于该进程的唯一信息是它的 pid，我确信这个 pid 不是假的（IPC 足够可靠，可以保证这一点）。我需要检查该进程是否具有特定的 uid 或 pid 或者是某个补充组的成员，然后才允许交易。为此，我阅读了进程的 /proc/[pid]/status 条目，解析 Uid/Gid/Groups 行并采取相应措施。

我的问题是这种检查进程身份的方法是否足够可靠，如果不是，它可能会在哪里失败？我担心流氓进程可能会以某种方式伪造我的服务对其 /proc/[pid]/status 或类似内容的视图。我是不是太偏执了，还是有真正需要考虑的问题？

注意：我之所以选择这种方法，是因为我无法找到另一种方法来获取 Linux 中另一个进程的身份。如果有人也能启发我，我会很高兴。

【问题讨论】：

标签： linux security ipc pid uid

【解决方案1】：

一个古老但仍然很好的攻击是找到一种方法来强制目标进程退出，无论是通过信号还是通过某种错误。然后通过 fork 快速用新进程充斥 PID 空间，直到攻击者获得正确的 PID。

每次检查 /proc/pid/status 确实使这变得更难，但它仍然是模糊的。

成功的攻击如下所示：

服务器 1234 监听
客户端检查 1234 有服务器 UID -> True
恶意kill Server 1234，启动32000个新进程
客户端使用恶意 1234 进行 IPC

【讨论】：

对，但是对每个事务进行检查并且IPC机制保证如果原始进程在事务完成之前死亡，那么事务将失败。换句话说，劫持交易不是一种选择。

【解决方案2】：

查看 /proc 的问题在于，除了可能存在 TOUTOC 风险之外，还有一些选项（man procfs 中的hidepid）意味着您无法访问文件（除非以 root 身份运行）。

如果使用 Unix 套接字（切换到 Unix 套接字）是使用文件系统权限来强制执行访问限制，则另一种方法可能是。（假设是服务器验证客户端）

如果客户端想要验证服务器，那么低 TCP 端口可能就足够了（即服务器以 root 身份运行/启动）或者检查 Unix 套接字的所有权。

【讨论】：