Thanks for sending this patch!

Since this load-bearing (lots of useful software, e.g. systemd wants this syscall), (potentially) security critical, and has been in this state for a very long time, I did some extensive digging.

First, some background on what name_to_handle_at(2) and open_by_handle_at(2) actually do: this is more-or-less a two-stage openat(2), as described in the manpage.

name_to_handle_at(2) performs a filesystem lookup, but instead of opening a file, it copies a (opaque) struct file_handle to userspace. That handle contains a string, which is looked up in the kernel as part of the system call.

open_by_handle_at(2) can then be used to open the path described by that file handle (which is dereferenced similarly to how it was saved), without doing a filesystem lookup a second time. Note that this does not defend against TOCTOU issues (e.g. the filesystem changing between calls); it merely allows one to pay the cost of resolving a path in the filesystem once, and amortize that cost over many usages.

This appears to have been added to the kernel to better support userspace network filesystem servers (which open and close many files and thus need all the performance shortcuts they can get), and the kernel implementation actually builds on the infrastructure of the exportfs subsystem used for the in-kernel NFS implementation.

The curious among us might find the following parts of the kernel source interesting:

• fs/fhandle:handle_to_path
• fs/namei:do_filp_open
• fs/namei:do_file_open_root
• fs/namei:do_open

Nonetheless, there are some differences from openat(2): open_by_handle_at(2) requires capabilities(7); specifically, CAP_DAC_READ_SEARCH, but openat(2) requires no privilege. Why is that?

First, let's establish what does not make open_by_handle_at(2) dangerous:

• open_by_handle_at(2) does pass a opaque and kernel-provided data structure back in, over the kernel/userspace boundary. However, the kernel is quite resilient to potentially hostile inputs, and in this specific case, struct file_handle is just structured data and is safely deserialized -- the kernel never tries to use what it gets back from userspace as a normal internal data structure.
• Permissions are checked (the thing that the related CAP_DAC_OVERRIDE capability allows bypassing) during open_by_handle_at(2), in the common do_open used by the entire open(2) family of system calls, so there is no risk of a stored struct file_handle being used to bypass (Unix) permissions.

If there is no risk of attacking the kernel, or bypassing DAC, what is the risk of this system call then? Well, if the user can construct arbitrary struct file_handles (hint: they can) and pass them to the kernel, there is the risk they manage to forge a handle and open a path that they otherwise could not access. Note that 'access' is not in the Unix permissions sense -- I use 'access' here to mean "open a dentry that cannot otherwise be resolved using the visible filesystem."

It's notable that there are several situations where filesystem access is not limited by permissions (e.g. a program has root), but instead by filesystem visibility:

• chroot(2)
• mount namespaces (including pivot_root(2)), which are used in containers (more on this later)

Indeed, if we look at the history of the patch that introduced these system calls:

• The initial version of the patch required CAP_SYS_ADMIN (infamously, 'the new root').
  • The risk of struct file_handle being forged was brought up in one of the earliest reviews.
• The next version of the patch moved to CAP_DAC_OVERRIDE.
  • Presumably the logic here was that forging a handle was similar to 'a process that is trusted to ignore Unix permissions'.
• Subsequent versions decreased the capability to CAP_DAC_READ_SEARCH.
  • As the only risk here is resolving a path that you otherwise could not, 'read' + 'search' (resolve path) are presumably a more granular fit.
  • The patch does note that CAP_DAC_SEARCH would be preferred if it existed, as it would more accurately reflect the threat model.
• The final, merged version of the patch made no changes to the permissions/capabilities model.

Given the above context, it is very clear that name_to_handle_at(2) is a safe operation (all it does is return a value that is useless without its sister syscall), and open_by_handle_at(2) is the dangerous component. So why is name_to_handle_at(2) more restricted?

Before we address that point directly, it helps to think about how Linux containers work (and how they isolate filesystem access). As noted above, we use mount namespaces(7) as part of the containerization. In fact, mount namespaces are one of the most critical forms of isolation making up a container; you can have root inside a container (and thus are allowed to modify any file), but you can't use that root access to affect files outside the container if you can't see the filesystem.

This is in fact false if you can abuse open_by_handle_at(2) to get access to a path you otherwise could not see in your mount namespace; this is the basis of one of the first container escapes, 'shocker.'

Others have already done an excellent job at explaining the exploit; these links should give more background if it is interesting to you:

• http://stealth.openwall.net/xSports/shocker.c
• https://lxc-users.linuxcontainers.narkive.com/9kzuZR09/container-escape-through-open-by-handle-at-shocker-exploit
• https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3

This was ultimately solved in Docker by dropping capabilities by default, beyond a narrow list of innocuous ones (e.g. CAP_MKNOD).

Now we understand this family of system calls, and their risk to containers. However, we still haven't puzzled out why name_to_handle_at(2) was gated behind CAP_SYS_ADMIN; to begin understanding that, let's look at the evolution of the default seccomp profile:

• The first version of the profile blocked open_by_handle_at(2) as it was implicated in shocker.
  • This appears to be something of a 'why not?' situation; the actual escape is solved by dropping the capability, but it doesn't hurt to filter with seccomp as well...
• A subsequent change was to move to an allowlist instead of a denylist; the explicit reference to open_by_handle_at(2) was dropped.
• A later, major refactor redesigned the default seccomp profile to work like it does today: --cap-add implies changes to the seccomp profile (and the profile is once again a denylist). At this time, both open_by_handle_at(2) and name_to_handle_at(2) were gated on CAP_DAC_READ_SEARCH.
  • This appears to be a case of 'guilty by association', i.e. both syscalls share a manpage, and one is behind a capability, so why not block them both?
  • Fun fact: the docs used to mistakenly assert this was gated by CAP_SYS_NICE.
• Finally, name_to_handle_at(2) was moved to CAP_SYS_ADMIN because systemd required it, and did not actually require open_by_handle_at(2).
  • It appears that no one reexamined why this was behind a capability, and assumed that it 'must' be because it was in some way dangerous.

In summary: this was incorrectly moved from CAP_DAC_READ_SEARCH to CAP_SYS_ADMIN (a more restrictive capability) in order to make it easier to run systemd (since systemd implied --cap-add SYS_ADMIN, and it made the command line shorter). However, name_to_handle_at(2) is in fact innocuous and safe, and I assert it should not be filtered in the default seccomp profile at all.

I suggest altering this PR to remove it from the list of filtered syscalls, and creating a new PR to adjust the docs.

LGTM! Thank you for your patience!