This Filesystem Is Born To Fail

Sandboxing a Linux process usually means spending a lot of effort deciding what it isn’t allowed to see. You might put it in a mount namespace, bind-mount a few directories into place, hide some others, add a chroot, and generally construct a carefully restricted version of the filesystem. But a new Linux kernel feature is about to change all of that. Instead of carefully hiding most of the filesystem, why not just take the filesystem away?

That’s essentially the idea behind FailFS, a tiny pseudo-filesystem expected to land in Linux 7.3. As the name suggests, it doesn’t do very much. In fact, that’s the point: every operation that reaches FailFS returns EOPNOTSUPP, meaning “operation not supported.”

The interesting bit is what happens when a process uses FailFS as its root or current working directory. At that point, normal pathname lookup essentially ceases to work. Absolute paths fail. Absolute symbolic links fail. Relative paths using the normal current-directory mechanism fail. If the application tries to open /etc/passwd, there simply isn’t a useful /etc to find.

Instead, the process has to start filesystem operations from an explicit file descriptor it already owns. For example, a sandbox manager could open a directory, hand that descriptor to the application, and the application could access files below it using calls such as openat(). Anything not reachable from one of those deliberately supplied descriptors might as well not exist.

Instead of starting with an entire filesystem and constructing rules that say, “not that, not that, not that,” you start with nothing and explicitly hand over the pieces the program needs.

There are some interesting consequences. At present, putting a process completely inside FailFS also prevents it from launching ordinary dynamically linked executables. ELF binaries generally specify their dynamic loader using an absolute pathname such as /lib64/ld-linux-x86-64.so.2. Absolute paths don’t work, so neither does the loader.

FailFS also has an interesting sibling called NULLFS, introduced earlier. NULLFS is another deliberately useless filesystem, but it behaves slightly differently: it contains a permanently empty directory and failed lookups return ENOENT, as though the requested file simply doesn’t exist. It was originally introduced to provide an immutable bottom layer beneath the real root filesystem and make operations such as pivot_root() cleaner.

Neither replaces all the other pieces needed for a secure sandbox. Processes still have system calls, networking, IPC, inherited descriptors, and plenty of other ways to cause trouble. But for controlling filesystem access, FailFS has a nice, simple philosophy.

Of course, if your file system is unwritable, that works, too.