Security

What every sandbox keeps closed

• Deny by default. A sandbox reaches the system's programs and what its policy opens, nothing else.
• A cleared environment. A sandbox's environment is cleared but for PATH, HOME, TERM, COLORTERM, TZ, the locale and who you are, so no token or SSH_AUTH_SOCK from your shell reaches it. On Linux it also gets an empty home folder, an empty /run and a private /tmp, and sees only its own processes (below).
• Link's settings (tokens, keys, the sandbox's rules), and the home exit's folder, ~/.config/lnk/vpn, wherever XDG_CONFIG_HOME puts the settings, stay closed to reading and writing, on macOS and Linux, even with read-home or a --read of a folder holding them. A --read or --write inside them is refused, and so is a --write of a folder holding them (--write ~), whose program could move them aside and write in their place. So the rules of each macOS policy, ~/.config/lnk/sandbox/<name>.sb, are where nothing sandboxed can edit them. A hidden folder, such as other agents' folders, is closed too, even to read-home and a read of a folder holding it, but for the policy's own folders inside it.
• What runs outside from a project. At the top of each folder a sandbox writes, a project's dot files that run outside it are read only, unless its policy names the folder (--write-dot-files, [files] write_dot_files): .git, all of it (its settings run on any git command, its hooks on a commit or a checkout, and a file in it can point git at settings elsewhere), .envrc (direnv runs it on cd), .vscode and .idea (an editor's tasks, settings and run configurations), the hooks folder and included settings files git's settings name in the folder, and what a hook manager reads there (husky's .husky, .pre-commit-config.yaml, lefthook's lefthook.yml and its other names, .lefthook). .husky is kept whole, since the stubs in .husky/_ run the scripts beside them. A hooks folder or included file below the top is read only, and each folder above it, such as scripts for scripts/hooks, can't be renamed or removed, though what else is in it is written. Where one of those folders isn't there, the first part is kept whole instead. A hook manager's settings are held only where they're there, and on Linux a missing .envrc isn't either (known gaps). On macOS, Seatbelt refuses writing each other path, there or not, in any case of its letters. On Linux each is mounted read only; one that isn't there is made empty for the run (a folder, or a file for included settings) and removed when it ends, and a link in its place refuses the sandbox. A mount can't be renamed, removed or linked to, and a folder above one below the top is bound over itself for the run, so .git, .husky or scripts can't be moved aside and made again. The placeholders are made and removed by name in their folder, opened without following a link, so another sandbox swapping a folder for a link meanwhile can't point them elsewhere. An agent's own folder and a guest's are theirs to write; an agent's files folder is yours, and keeps them read only. check tries each.
• What sits beside lnk-sandbox. Every sandbox runs lnk-sandbox (to start under the seccomp filter, and as ssh's ProxyCommand behind the proxy), so it reads that one file, never the folder it's in (by default ~/.local/bin) or anything else there.
• Other programs. No sandbox reaches other programs' memory or environment, and on Linux not their processes at all.
• macOS services. No sandbox reaches the clipboard, the screen, Apple Events to other apps, the Keychain, the privacy database or core services.
• The Linux kernel. A seccomp filter refuses the riskiest system calls inside every sandbox (each).
• Running code the list doesn't name. Where [commands] lists programs, a program can't run code it wrote by giving exec a file descriptor instead of a path: the seccomp filter refuses running one (execveat with AT_EMPTY_PATH, fexecve), and on Linux 6.3 and newer every memory file the sandbox makes can never be run, so a program copied into one (memfd_create) can't be run, by execveat or through /proc/self/fd. The exec watch (below) makes each one itself, as asked but sealed non-executable (MFD_NOEXEC_SEAL), and hands it to the program as the call's answer. A memory file of huge pages (MFD_HUGETLB) is refused, since Linux doesn't keep its seal: its mode could be made executable again. Under another program's seccomp listener (a container runtime's), the kernel gives the watch none: the sandbox still runs and says memory files aren't sealed, and check shows the /proc/self/fd way as a LEAK. On older kernels one still runs through /proc/self/fd, and check shows it as a known gap. memfd_create and mapping its memory executable (a JIT) still work.
• Root's capabilities (Linux). Run by root, the sandbox drops all capabilities, in a user namespace of its own, so its program can't override a file's permissions, reach into another process, or open the exec watch's descriptors. It is still root's user: it reads and writes root's files among its grants, and a service that trusts its caller's user, such as a unix socket only root may use, takes it for root wherever the sandbox reaches it (with network, the machine's abstract sockets). The sandbox sets TAR_OPTIONS=--no-same-owner, so tar keeps unpacked files as root's instead of failing to change their owner.

lnk sandbox check tries each of these (how).

The sandbox on macOS

A Seatbelt profile, run by /usr/bin/sandbox-exec, denies everything, then allows:

• Reading the system's programs and libraries (/usr/bin, /usr/lib, /System, /private/etc, ...), and Homebrew's programs, libraries and certificates. Not Homebrew's var/, with local databases and logs, nor its servers' settings in etc/.
• The few devices programs use (/dev/null, /dev/urandom, /dev/tty, ...), not your other terminals.
• Reading and writing the folders its policy names.
• stat() on any folder: it can tell a folder exists, not what files are in it. Never stat() on files outside its folders, so it can't tell whether other files exist.
• Unix sockets only in its folders.
• Listening on localhost only, on the ports its policy names, and connecting only to those and its proxy's; with network, any address (what can cross).

Nothing else: no other localhost server (databases, dev servers, other apps' APIs), no Keychain service, no LaunchServices, no other network. Each policy's rules are a file in Link's settings, ~/.config/lnk/sandbox/<name>.sb, so a policy's name is letters, digits and dashes only.

The sandbox on Linux

• bubblewrap builds its root from the system's folders only (/usr, /bin, /sbin, /lib, /lib32, /lib64, /libx32, /etc, /opt, /nix, /snap, /sys and /var/lib/ca-certificates), read-only: no other disks, /srv, the rest of /var or other homes.
• It gets an empty home folder holding only its folders, an empty /run (no session bus), a private /tmp, and its own PID, IPC and UTS namespaces.
• A hidden folder is mounted over in order: the folders holding it, then the hiding, then the policy's own folders inside it. So Link's settings stay closed under a --read of ~/.config too.
• Its first program inside is lnk-sandbox sandbox confine, which installs a seccomp filter (x86_64 and arm64) and then becomes the program. Every process in the sandbox runs under it, and it can't be removed.
• The filter refuses the system calls a sandboxed program doesn't need and kernel bugs are most often found in, as container runtimes do:
  • io_uring (ENOSYS, so libuv and others fall back)
  • BPF, userfaultfd, perf events
  • the key store (keyctl, add_key)
  • ptrace and reading other processes' memory, so gdb and strace don't work
  • mounting and the new mount API
  • new namespaces: unshare, setns, clone with a namespace flag; clone3 gets ENOSYS so libc falls back to clone
  • files by handle, loading kernel code, the clock, rebooting, swap
  • iopl, ioperm and modify_ldt (x86_64)
  • TIOCSTI and TIOCLINUX, which type into a terminal
  • every call of another architecture (i386, x32)
  • a few more no program here needs, such as acct, quotactl, syslog and process_vm_writev; and, where [commands] lists programs, running a file descriptor (below)
• Each refused call fails with an error; nothing is killed.
• Where bubblewrap is 0.8 or newer, it also refuses user namespaces itself (--disable-userns).
• lnk sandbox check tries the calls a program can make unprivileged, where python3 is there to make them: a user namespace, io_uring, userfaultfd, keyctl and ptrace.

Ubuntu's rule for user namespaces

• Ubuntu 23.10 and newer let only programs AppArmor names make the user namespaces bubblewrap needs (kernel.apparmor_restrict_unprivileged_userns).
• When that stops the sandbox, lnk sandbox ready offers, in a terminal, to add /etc/apparmor.d/lnk-bwrap with sudo. lnk agent start, lnk agent <harness> check, and lnk sandbox run, check and learn run it first; a guest's session checks it, and refuses without asking.
• The profile is for bubblewrap alone: unconfined as before, with the right to make user namespaces added. Every local user's bubblewrap gains that right, as Ubuntu gives Flatpak's. The kernel attack surface the rule shields from programs in general stays shielded.
• Declined, or with no terminal, lnk prints the two commands, and nothing runs unsandboxed on its own.

What a spec can and can't open

A spec is a file, and a file can come from anyone, so lnk sandbox run --spec checks what it opens before it runs:

• Shown first. A spec not run here before, or one that opens something else since, prints what it opens and asks. Link's settings keep, in ~/.config/lnk/specs/sandbox.toml, each spec's path and a hash of its grants with every path resolved through links and every program as PATH found it, so a changed text or a link moved under a folder it names asks again. A path a link makes elsewhere is shown with where it really is. --yes skips the question.
• Refused in a spec's file, with the flags beside it: what would open Link's settings or agents' folders, let code the program writes run outside the sandbox (in your home's dot folders, on your PATH, in the system's folders or a project's dot files), widen the spec's own next run, or reach other programs' sockets (each).
• Link's settings stay closed to every sandbox, spec or flags, to reading and writing: a grant inside them, or a write of a folder holding them, is refused.
• [localhost] ports = ["*"] is refused: every port of this machine would include other sandboxes' proxies, each another one's way out. So is 40781, the port of main's proxy.
• [commands] limits which files run, by the kernel: Seatbelt on macOS, Landlock on Linux (5.13 and newer; without it, a spec listing programs is refused). An entry in a folder it may write, or in /tmp, is refused, and so is a folder holding one of those. lnk sandbox check --spec tries a program it doesn't list, and each way a program might run code around the list (below).
• A refused program is named (Linux). Where [commands] lists programs, and in lnk sandbox learn, the sandbox's first program (lnk-sandbox) stays as the parent of what it runs, and a seccomp filter hands it each exec before it happens. It reads the path from the calling program's memory, says which file the list refuses (or, for learn, records it), and lets the call go on unchanged: only Landlock decides what runs. The call goes on once its path is read, and the refusal is named after, so it may follow the program's own error. A program can show it one path and run another, which misleads only the message, and one that keeps its memory from being read (non-dumpable, as ssh makes itself) isn't named. learn runs every program, under the spec's other grants. The watch makes itself not dumpable, so no program in the sandbox opens its descriptors (the seccomp listener, learn's pipe) through /proc/<pid>/fd or pidfd_getfd, run by root too, since the sandbox has none of root's capabilities.
• A refused program is named (macOS). Seatbelt reports each program it refuses in the system log, and lnk-sandbox, outside the sandbox as the parent of sandbox-exec, reads them with log stream while it runs, taking only Seatbelt's own lines (their sender), never one another program wrote in its words. A report names a process and its id, not the sandbox, so it's taken for this run's when the process is in the run's tree or already gone: a program another sandbox refuses at the same moment may be named too. It keeps 10,000 reports at most. A run that ends well with no refusal reported stops reading at once, so a refusal reported after that isn't named. Only Seatbelt decides what runs. learn gives its profile (allow process-exec (with report)), so every program it runs is reported. log stream takes an admin user; for another, nothing is named.

Checking a sandbox

lnk sandbox check runs probes inside a sandbox as the flags or spec given would make it, against bait it sets up:

• a file with a random secret in the home folder, in Link's settings folder, in /var/tmp and in each hidden folder there is (agents' folders among them); and a listing of ~/.ssh
• a write into the home folder, and a write into each folder the policy may write, which must work
• a server on a random localhost port, tried as 127.0.0.1, ::ffff:127.0.0.1 and the machine's address
• http://1.1.1.1, or behind a proxy, a tunnel to it through the proxy, and asking the proxy for this machine, your network, a host not listed, and IPv4 written in IPv6's forms
• the folder lnk-sandbox is in, and each dot file that runs outside at the top of each folder it writes
• a program holding the secret in its environment (ps -E on macOS, /proc/<pid>/environ on Linux)
• each localhost port the policy allows: whatever serves it is reachable with its whole API, reported as a known gap
• on macOS, open -a Finder, a search for a throwaway item Link adds to the login Keychain, and a lookup of each system service by name. Those every sandbox gets and those a permission opens count as allowed; the clipboard, the screen, Apple Events, the privacy database and core services never do. lnk-sandbox looks them up inside.

Anything that gets through without a permission allowing it is a LEAK, and the command fails. It removes its bait after. Tests also lnk sandbox run a program that tries to read ~/.ssh, Link's settings and its caller's environment, write the home folder and reach the network.

Its only way out

Where it may connect

Models and secrets

The wire's log

lnk sandbox log reads ~/.config/lnk/sandbox/wire.log (600, in Link's settings, which no sandbox reads or writes). Every proxy writes a line per call: the time, the sandbox's name, the verb, the host and port (or the provider, or the machine's port), and whether it was allowed, refused or failed. When an allowed call ends, another line gives the bytes each way.

• The verbs are connect (HTTPS), tcp (another port), http, mcp (a tool's call), model (hosted), local-model, secret (a service's call, its secret added, such as a Telegram bot's), port (this machine's, Linux), dns (a name looked up, Linux, where it names endpoints), open (a page in your browser), callback (a login's answer let in, Linux), browser (a web page's request, refused, once a minute at most), pause and unknown.
• Never a path, a header or a body.
• The names in it are what a sandbox asked for: cut at 300 characters, and shown without control characters.
• Past 8 MB it becomes wire.log.1, the older ones move up to wire.log.4 and the oldest is dropped, so 40 MB of every sandbox's calls in all.
• A wire refused while paused, stopped or over its limit logs that once a minute, with how many it left out, so a sandbox can't push its own history, or other agents', out with refusals that cost it nothing.
• Whatever its calls end in, a wire logs at most 120 lines a minute of each outcome: allowed, ended, refused, failed. It leaves out the rest, and its next line of that outcome says how many (and 880 more failed since). A flood of calls that fail, or that go through, fills the log no faster than that, and never hides another outcome's first lines. What it leaves out still counts toward a pause.
• Link tells each proxy where the log is, since the proxy runs with the program's environment, whose HOME is a harness's own folder.
• It holds a proxy's calls, not what a sandbox with network does directly.
• Beside it, each running proxy writes what it has carried, two byte counts and its sandbox's name, and for one that carries a model six counts of its requests and tokens, to traffic/<pid>.json, every 5 seconds while they change, and a model's counts as soon as they do (lnk sandbox traffic); a proxy's file goes once it's gone.
• When its program exits, a proxy logs each call it still had open as ended, with the bytes it carried. A proxy killed outright, not stopped, writes no ended line for them.

The kill switch and pausing

• lnk sandbox stop: while ~/.config/lnk/sandbox/stopped exists, every proxy refuses every call with a 403 and ends the calls it has open within a second. Each proxy looks at the file itself, for each call and every second while one is open, so no sandbox can hold it up or undo it. Then stop runs what asked to stop with it (lnk sandbox on-stop, kept in Link's settings, which no sandbox reaches): lnk agent stop for each agent here, which every agent's start registers, since an agent with lan has no proxy. stop --off removes the file; agents stay stopped until started.
• stop closes the proxies, not a sandbox's direct network (an agent's lan, a guest's --allow network): those stop with their program.
• lnk sandbox pause <name>, and the proxy itself: while ~/.config/lnk/sandbox/paused/<name> exists, that sandbox's proxy refuses every call and ends those open, as with the kill switch, until lnk sandbox resume <name> removes it.
• Each proxy watches its own calls and writes that file on a pattern no normal work makes: 30 refusals within a minute, 20 different targets refused within 10 minutes, or a call to a cloud's metadata service (169.254.169.254, metadata.google.internal), however it's written: by the address a name or number resolves to. It logs a pause line and shows a notification where it can. Where it can't, on a box, lnk agent status and lnk sandbox paused say so.
• A pause never fails open: a proxy tells it's paused by the file being there, even if it can't read why, and one it couldn't write (out of file descriptors, say) holds in the proxy until it's written. A proxy has a limit of connections on each listener, and a listener that fails to accept one waits a moment and goes on, so a program can't use up the proxy's descriptors or stop its listeners.
• Nothing inside a sandbox can write the file or undo it. Pausing narrows an agent attacking what the internet reaches, and brings it to light; it doesn't prevent it.

Tools that run outside

lnk sandbox tool add, lnk agent allow tool and --tool: an MCP server you add runs outside every sandbox, with your logins. That's its point, and what it can do is yours to choose.

• Its definition is ~/.config/lnk/sandbox/tools/<name>.json (600), read by the proxies outside: its command, folder, a snapshot of a few variables of your environment, and --env, which may hold a token.
• It runs with your PATH, HOME, user, locale, TMPDIR, SSH agent and desktop session (DISPLAY, WAYLAND_DISPLAY, D-Bus) as they were when added, and nothing else of your shell's.
• A sandbox reaches only the tools its policy names, at /_link/s/<secret>/mcp/<name> on its proxy ($LNK_TOOL_<NAME>), the secret its proxy's, never logged: one request per connection, a body of 8 MB at most, one JSON-RPC message, no batches.
• Each session a client starts is a server of its own; a sandbox keeps at most 8, and at most two start at once (the sandbox's settings' tool_sessions and tool_starts): the rest wait their turn, and one still waiting after 60 s gets a 429. A tool added again with another command, folder or --env (a token replaced) ends the sessions started before: their next request is answered as gone, and the client's next session runs as the tool is now.
• The client's own capabilities are removed from initialize, and what the server asks of the client is refused outside, so no server reaches the sandbox's folders or a model through it. Its notifications stay outside. Everything else, such as listing tools, prompts and resources, passes as it is.
• Each tools/call goes through only if the tool's rules allow it (--allow, or --ask none). A server's hints, such as MCP's readOnlyHint or destructiveHint, are shown and never skip asking. Otherwise the proxy asks you, below.
• A message without an id reaches the server only if it's one of MCP's own notifications (initialized, cancelled, progress, roots/list_changed): a tools/call sent as one, which some servers would run without an id, is refused.
• Removing a tool ends its sessions: the next call is refused.
• Each request is a line in the wire's log (mcp, the tool and a call's name, never its arguments or answer), and refused calls count toward a pause.
• A tool at a URL (--url) is a stdio server of Link's own, lnk-sandbox sandbox mcp-remote, run outside like any other. It reaches https://, or http:// on this machine only, and sends each message as streamable HTTP's POST with the server's session. Its headers, a token among them, are in its definition's environment (LNK_MCP_HEADER_<n>), never in a sandbox or on a command line.

Asking you

The proxy asks one question at a time, allows that call once, and two minutes without an answer is no. Unanswered, the refusal names the --allow that lets it through. It asks in the first way there is:

1. A dialog: macOS's osascript, passed the text as an argument, never as script; or zenity --no-markup or kdialog with the text escaped. They get the desktop session's variables that wrap passes the proxy (--desktop), never the sandbox. They, a notification and your browser are found in the system's folders (/usr/bin, /bin, /usr/local/bin), never on the program's PATH, which can name a folder the sandbox writes.
2. Its controlling terminal, with a random code of four letters to type back. Anything else refuses it.
3. A waiting question in ~/.config/lnk/sandbox/asks/ (600, a random id), said in a notification where one can be shown and at the top of lnk sandbox log. lnk sandbox answer answers it. The first answer is final: it's linked in place, so never a second one or a half-written one. Both files are removed once it's over; those a gone proxy left are removed by the next asks.

Nothing in a sandbox draws on the screen or reaches Link's settings, so it can neither fake a dialog nor answer one or a waiting question. On a terminal, with no desktop or over SSH, the program shares it: it can type (macOS) but not read what's written, so it can't answer, but it can write over the question's text, so what the question names can be faked there. The code you type still allows only the call that asked. A dialog or lnk sandbox asks shows the question as it is, without control characters or those that hide text or turn it around (bidi, zero-width). Each line is cut at 600 characters, and a question cut short says so: allowing it allows what you can't see.

Known gaps

check reports these as open:

• On macOS, with network: every localhost port, through ::ffff:127.0.0.1, IPv4 localhost through an IPv6 socket. Seatbelt doesn't count it as localhost, so network's "any address" covers it, and a rule names only localhost or any host, with (remote ip6 ...) matching IPv4 too, so Seatbelt can't close it. Also the Mac's own LAN address, which isn't localhost to Seatbelt either: a server listening on every address is reachable through it.
• On Linux, with network: every localhost port, since bubblewrap can't tell ports apart and the sandbox shares the machine's network. Also the machine's abstract unix sockets, which belong to the network namespace: X11's (@/tmp/.X11-unix/X0, which a desktop's X server may trust for the same user without a cookie, to read the screen and type keys) and some session buses'.
• A localhost port its policy names (--port, a harness's own ports) is open to that service's whole API, when something serves it.
• On Linux, a missing .envrc isn't held: a sandbox can make one. direnv runs a new or changed .envrc only after direnv allow, which shows it.
• On Linux, where a spec lists programs ([commands]), code run around the list:
  • the program loader, which every program needs, runs any file the sandbox can read (ld.so ./program): it has to stay runnable for every dynamically linked program, so it can't be closed;
  • a listed program loads a library the sandbox wrote when LD_PRELOAD names it: the variable is cleared when the sandbox starts, but a program can set it for a child it runs;
  • on Linux older than 6.3, a program copied into a memory file (memfd_create), which is in no folder.

With [internet] instead of network, the first two are closed and the others remain. These check doesn't report:

• [commands] limits which files are run, not what code runs: a listed interpreter (sh, node, python3) runs any script it's given, and on macOS a listed program that isn't Apple's loads a library the sandbox wrote when DYLD_INSERT_LIBRARIES names it (cleared when the sandbox starts, but a program can set it for a child). On Linux, running any file descriptor (execveat with AT_EMPTY_PATH) is closed where a spec lists programs, and so, on Linux 6.3 and newer, is running a program copied into a memory file; check shows which are blocked on this machine.
• A project's dot files that run outside are read only at the top of each folder a sandbox writes, and nowhere else. A sandbox can make a .git in any folder inside (src/.git, with a core.fsmonitor), and git run there, by you or by a shell prompt that shows git's status when you cd in, runs what it wrote, outside. A repository it clones or makes in a folder inside is its own, hooks and settings: running git there runs what it wrote. A folder holding your projects (--write ~/code) keeps none of theirs. Where --write-dot-files names a folder, it writes them all. A script of the project that your git settings already run (a filter's, an alias's) is the project's, as its Makefile is.
• On macOS, an [internet] tcp endpoint (--tcp) is reached only by a client that connects through a command, as ssh's ProxyCommand does (git over SSH). A database client such as psql, or a driver, can't reach one there: with no network of its own, a name can't be given an address of the sandbox's, and Seatbelt can't send a connection elsewhere.
• A hook manager's settings that aren't there (.pre-commit-config.yaml, lefthook.yml) aren't held: a sandbox can make one. A hook manager runs one only where its stub is in .git/hooks, which is read only, and its install makes the settings when there are none.
• On Linux, removing one of the empty placeholders made in a dot file's place while a sandbox runs (git clean -d does) lets that sandbox make it. A sandbox killed outright leaves its placeholders until the next sandbox on the folder ends.
• On macOS, any program or user of the machine can send the proxy calls without a browser's marks, such as CONNECT to a host it refuses. Those count as the sandbox's: 30 refusals in a minute pause its wire until lnk sandbox resume, they use up its calls a minute and its 512 connections, and they are in the wire's log under its name.
• A hosted model that searches by nature, such as Perplexity's sonar models or OpenAI's *-search-preview on OpenRouter, fetches pages for the sandbox whatever the proxy removes. With a list of hosts and the key on the wire, the proxy refuses it (below); with the key in the harness, it can't see it, and lnk agent start says so. Name a model that doesn't.
• The proxy knows the ways a provider takes a URL to fetch by their keys (any ending in url or _data); a provider's new way under another name isn't refused until Link knows it.
• A port [localhost] ports names (--port) is reached whatever listens on it, Link's own among them: on macOS another agent's proxy (each agent's on a fixed port), or a sandbox's proxy on a free port; an agent's harness served on this machine's loopback (its gateway); the home exit's SOCKS proxy on a box, when it's on the port (40780); a model lnk model serve serves. The sandbox can't tell those ports from others without reading other plugins' settings, so only 40781 is refused: name only ports you know.
• A public address that isn't on one of the machine's interfaces isn't refused by the proxy. On a cloud box behind the cloud's NAT (AWS, Google Cloud), its public IPv4 is such an address, so a sandbox there reaches the box's own services on it where the box's firewall lets the internet in. So does a home router's public address, where the router answers from inside. Keep a box's firewall closed to what shouldn't be public.

Limits

• macOS and Linux only. On Linux: bubblewrap, and user namespaces the kernel allows (Ubuntu's rule).
• On Linux, debuggers and tracers (gdb, strace) don't work inside a sandbox, since ptrace is refused. Run by root, what needs one of root's capabilities fails inside, such as listening on a port below 1024, and a folder it's given that another user owns (a project mounted as uid 1000 in a container run as root) can't be written: its user namespace maps only root, so those files belong to nobody inside. Programs that need io_uring use their fallback, and nothing inside can make a container of its own: Docker, Podman, or bubblewrap again.