为什么我们需要 `/proc` 处的 procfs?

为什么我们需要 `/proc` 处的 procfs?

所以我知道里面的东西/proc不是一个实际的文件系统,但是一个伪文件系统(647551)。现在我的问题是:为什么我们要把它放在那里?

像文件系统一样列出这些内容procfs可能会导致对这些“文件”进行可能危险的读取和写入,这为某些漏洞利用打开了大门(例如对进程文件的读/写访问)。

procfs可以将其制作为伪文件系统以实现泛化和(我认为)更简单的设计,但 Linux 应该能够将所有内容保留在内存中而不暴露进程内容。

那么为什么我们需要procfsat/proc呢?

答案1

等待。你说,“我知道 /proc 中的东西不是实际的文件系统,而是伪文件系统(647551)”。

请原谅我,但考虑到你读过,你的问题没有什么意义。你需要系统 API 调用,/proc“文件系统”是那些呈现为文件的 API 调用。换句话说,您不会从流程 API 的文件可用性中失去任何东西,也不会获得任何好处,除了使用起来有些简单之外。您可以通过 procfs 文件执行的所有操作,都可以使用相应的 ioctl/内核调用来执行。

删除伪文件系统并保留 API 就是一个例子通过默默无闻实现安全,这样就不会有什么晦涩难懂的地方了。作恶者很快就只需要加载一个不同的宏包含文件。

出于同样的原因,这procfs不是性能问题,也不是安全问题。

(这绝对是不是当然,不应该保护对这些 API 的访问并防止漏洞利用!)

答案2

为什么我们还要在/proc那里?

我们有它,因此ps可以阅读有关您的流程的信息。如果您正在调试某些内容,或者认为您正在运行一个杂散的后台进程并想要终止它,那么这非常有用。你需要先找到它。

好吧,当然/proc不是提供此类信息的唯一方法。传说,在过去,你会拥有一个特权ps二进制文件直接从内核内存读取进程信息。不涉及任何文件,但这并不感觉更安全。当然,第三种选择是创建一个或多个专用系统调用来查找进程信息。在这里,创建文件系统是一种设计选择,大概在创建文件系统时,人们认为能够使用 或 等常规工具访问其中的数据很有lscat。此外,它不仅仅是处理信息,整个过程还充当各种随机数据的网关,这些数据对于在内核和用户空间之间传输很有用。使其成为一个文件系统,为层次结构提供了一个现成的框架。

此外,文件系统具有现成的访问控制系统,可以proc使用。

像文件系统一样列出 procfs 可能会导致对这些“文件”进行可能危险的读取和写入,

仅适用于您拥有的进程。传统上,单个用户的进程之间没有太大的分离。哎呀,在一些系统上,您可以在您拥有的任何正在运行的进程上运行调试器,然后执行不管你想要什么到它。 (但请参阅/proc/sys/kernel/yama/ptrace_scopeLinux 上的情况。)

这为某些漏洞打开了大门(例如对进程文件的读/写访问)。

视频中出现的问题似乎不是关于proc,而是关于将文件描述符保持打开状态,然后更改为较低优先级的上下文(返回到用户自己的 UID)。他们在那里运行一个打开 fd 的 shell,然后告诉 shell 直接cat读取该 fd(的副本)。这可以在没有 的情况下完成proc,fd 没有它就存在,即使更难看到。但猜测 fd 会得到哪个数字并不难,因为它们是按从最低的顺序开始分配的......

此外,他们没有检查setuid()该视频中的返回值,因此他们最终可能会以完全 root 权限运行 shell。另外,不要像他们告诉你的那样以 root 身份运行编译器。您确实需要相信编译器在任何情况下都不会执行任何故意恶意的操作,但它们是大问题,甚至可能因错误而产生错误,并且以 root 身份运行会增加暴露风险。

Setuid 二进制文件是难的做正确的事,除了杂散文件描述符之外还有很多其他原因。这不仅涉及从特权程序返回到非特权程序,还涉及 setuid 进程从中继承的环境呼叫者,由普通用户控制的进程。

procfs 可能会被制作成一个伪文件系统,以实现通用化和(我认为)更简单的设计,但 Linux 应该能够将所有内容保留在内存中而不暴露进程内容。

当然。不要挂载/proc。尽管如前所述,那么您就没有工作ps。但由于它是一个文件系统,您可以只运行chmod 0550 /proc,只留下 root 和任何组拥有的成员/proc能够访问它。

或者你的意思/proc/$pid/fd是特别的?它允许一些奇怪的技巧,进程从其父级继承东西的正常概念不允许,并且您可以在没有它的情况下做很多事情,所以也许删除它是有意义的。但它本身并没有多大好处,用户的进程可能会通过许多其他方式相互干扰。

答案3

  1. procfssys允许在不编写任何代码的情况下获取有关系统当前状态的信息。这就是创建它的理由。

  2. 使用 C 语言 API 代替文件有其自身的缺陷,例如,一旦创建 API,它就会不是易于扩展它们,因为使用这些 API 的现有应用程序必须重写/修复。

是的,procfs文件sys可用于利用系统,但普通 API 实际上用于此目的更多

它是完美无需安装这些文件系统甚至不可用即可获得完整的体验,例如检查其他 POSIX 兼容操作系统,如 FreeBSD/OpenBSD/NetBSD、QNX 等。

相关内容