/proc hardening

[cyphar]

Right now, we do a few security checks when operating on /proc, namely:

• That /proc has an fs_type of PROC_SUPER_MAGIC (which can't be faked by FUSE), to make sure we're dealing with a real procfs.

• That /proc has an inode number of 1 to indicate that it is the root of a procfs mount -- which is part of the API of Linux and will always be the case.

Unfortunately, this method is still vulnerable to potential attacks if we're in a situation where /proc (usually thanks to a confused deputy) has been set up in such a way to trick us into thinking (for instance) that we are writing an AppArmor label when in fact we aren't.

Effectively we need to use the resolution capabilities of libpathrs for /proc (which leads to some fun re-entrancy issues since libpathrs depends on using /proc during resolution). So that will need some attention.

Note that checking that a given Handle has PROC_SUPER_MAGIC is not sufficient at all because you can always bind-mount another process's procfs file to your own -- and for write-related requests you can just bind-mount a file which no-ops on write like /proc/self/sched.

The set of underlying features currently required are:

• RESOLVE_NO_XDEV support for resolvers (RESOLVE_NO_XDEV support for emulated backend #8).
• O_EMPTYPATH kernel support (upstream kernel hardening: O_EMPTYPATH #16).
• pidfd_open("exe") kernel support (upstream kernel hardening: pidfd_open("exe") #17).
• A way to opt-in to a "hardened" mode which makes it an error if none of the core features above can be used on the running system. (allow users to opt-out of fallbacks #19)
• readlinkat2(AT_EMPTY_PATH) kernel support (readlinkat2(AT_EMPTY_PATH) #18) -- optional.

[the8472]

A way, at least for sufficiently privileged processes, to avoid bind-mount attacks is to create a private procfs instance with new mount API and then operate on the detached, untainted tree.

Edit: Nevermind, I see that's already mentioned in one of the linked issues.

[cyphar]

Yeah that is one of the options. Ideally that will be the long-term solution (with subset=pids,hidepid=4 we should be able to make creating a private procfs instance safe for unprivileged users). But for now we can only do that for privileged users.

[cyphar]

cyphar/filepath-securejoin#13 has an implementation of most of this, though it only works for privileged users and on a new enough kernel (Linux 5.8-ish).