Why do we need procfs at `/proc`?

Question

So I know the stuff in /proc is not an actual file system but a pseudo-filesystem (647551). Now my question is: Why do we even have it there?

Having the procfs listed like a file system allows possibly dangerous reading & writing to those "files", which opens the door to some exploits (e.g. read/write access to process files).

procfs may be made to be a pseudo-filesystem for generalization and (I assume) easier designs, but Linux should be able to keep all that in memory without exposing process stuff.

So why do we need procfs at /proc?

Answer 1

Wait. You say, "I know the stuff in /proc is not an actual file system but a pseudo-filesystem (647551)".

Pardon me, but given that you read that, your question makes little sense. You need system API calls, and the /proc "filesystem" is those very API calls rendered as files. In other words, you lose nothing, and gain nothing, from the file-availability of the process APIs, except some simplicity of use. Everything you can do through the procfs files, you can do with the appropriate corresponding ioctl/kernel call.

Removing the pseudo filesystem and keeping the APIs would be an example of security through obscurity, and there would be very little obscurity at that. Evildoers would very soon just need to load a different macro include file.

For the same reasons why procfs is not a performance issue, neither it is a security issue.

(Which is absolutely not to say that access to those APIs shouldn't be secured and proof against exploits, of course!)

Answer 2

Why do we even have /proc there?

We have it there so ps can read information about your processes. Which is really useful, if you're debugging something, or think you have a stray background process running and want to kill it. You need to find it first.

Ok, of course /proc isn't the only way to provide that sort of information. The legend goes, that in days of yore, you'd have a privileged ps binary that read the process information straight from the kernel's memory. No files involved, but that hardly feels much safer. Of course, a third option would be creating a dedicated system call or calls to find process information. Here, creating a filesystem instead is a design choice, and presumably when it was made, it was thought useful to be able to access the data there also with regular tools like ls or cat. Also, it's not just process information there, the whole thing works as a gateway for various pieces of random data that are useful to transfer between the kernel and userspace. Making it a filesystem gives a ready framework for hierarchy.

Also, filesystems have ready-made access control systems, which proc uses.

Having the procfs listed like a file system allows possibly dangerous reading & writing to those "files",

Only to processes owned by you. And traditionally, there's not much separation between processes of a single user. Heck, on a few systems you can run a debugger on any running process owned by you, and do whatever the heck you want to it. (But see /proc/sys/kernel/yama/ptrace_scope on Linux.)

which opens the door to some exploits (e.g. read/write access to process files).

The issue presented in the video doesn't seem to be about proc, but about leaving file descriptors open, and then changing to a lower-priority context (back to the user's own UID). They're running a shell there with the fd open and then telling the shell to direct cat to read from (a copy of) that fd. That can be done without proc, the fd's exist without it, even if harder to see. But it's not exactly hard to guess which number an fd will get, since they're allocated in order starting at the lowest...

Also, they're not checking the return value of setuid() in that video, so they could end up running the shell with full root privileges anyway. Also, don't run a compiler as root like they're telling you to do. You do need to trust the compiler to not do anything purposefully malicious in any case, but they're big things and might have bugs even by mistake, and running one as root increases the exposure.

Setuid binaries are hard to do right, already for a lot of other reasons than stray file descriptors. It's not just about going back from a privileged to a non-privileged program, but also about the environment the setuid process inherits from it's caller, a process controlled by a regular user.

procfs may be made to be a pseudo-filesystem for generalization and (I assume) easier designs, but Linux should be able to keep all that in memory without exposing process stuff.

Sure. Don't mount /proc. Though as said, then you don't have a working ps. But since it's a filesystem, you can just run chmod 0550 /proc, leaving only root and members of whatever group owns /proc able to access it.

Or do you mean /proc/$pid/fd in particular? It does allow some weird tricks that the normal concept of processes inheriting stuff from their parents doesn't allow, and you can do a lot of things without it, so maybe it would make sense to remove it. But it won't do much good in itself, there's likely a number of other ways the processes of a user can mess with each other.

Answer 3

1. procfs and sys allow to get information about the current state of the system without writing any code. That was the rationale behind creating it.

2. Using C-language APIs instead of files has its own pitfalls, e.g. once you create APIs it's not easy to extend them because existing applications using these APIs will have to be rewritten/fixed.

Yes, procfs and sys files can be used to exploit the system but normal APIs are actually used for this purpose a whole lot more.

It's perfectly possible to have a complete experience without having these filesystems mounted or even available, e.g. check other POSIX compatible operating systems like FreeBSD/OpenBSD/NetBSD, QNX and others.