Comment by codedokode

In practice, you need to do more than use existing file descriptors. You want a sandboxed program to be able to display windows, use graphic acceleration, play and record audio, have limited access to dbus, integrate with other sanboxed programs. This is where you cannot get away with 112 lines of code.

For example, to play audio, one has to use pulseaudio protocol and create a fake ALSA device in the sandbox because pipewire doesn't have simpler way to share the access between different users. Also this does not prevent the untrusted program from reading audio card vendor and name.

Some applications like Chromium use privileged SUID helper so I am not sure if it is possible to sandbox them at all. Electron-based apps are also a pain to make work in a sandbox, for example, without /proc and graphic acceleration.

The state of sandboxing on Linux is pretty sad at present moment, and almost everything runs without any restrictions. Compare to Android or iOS where sandboxing was implemented from the start. It is easier and more reliable just to use a virtual machine with a full OS for sandboxing.

There is flatpak, but as I understand, it doesn't prevent the application from reading OS and hardware identifiers via /proc and /sys for example. Also some flatpak apps use "classic" confinement which contrary to the name means no confinement at all.