Sandboxing

01 Introduction

The security's classical's model (Lessons 12.1–12.5) is the perimeter's defence: the system's boundary (the network's firewall, the user's account) protects the trusted's interior, and the interior's components (the users, the processes, the applications) trust one another. The model's assumption is the perimeter's impermeability, and the modern's threats (the remote's code's execution, the supply chain's compromise, the malicious's insider, the malware) invalidate the assumption: the attacker who breaches the perimeter (or the user who runs the untrusted's code) has the interior's trust, and the damage's scope is the whole system. The sandbox is the answer to the assumption's failure: the untrusted's code runs in the isolated's environment (the sandbox), and the sandbox's walls confine the code's capabilities to the minimum it needs. The compromise's damage is the sandbox's damage, not the system's.

The sandboxing is the security's least privilege's principle (Lesson 12.1's principle 6) applied at the process's (or the process group's) level: the process is granted the minimum resources it needs to do its work, and the kernel's mechanisms enforce the grant. The sandbox's walls are the mechanisms that the operating system provides:

• The namespaces (the isolation's mechanisms: the process's view of the file system, the process's table, the network, the IPC, the users, the hostname, the cgroups, and the time).
• The control groups (cgroups) (the resource's limits: the CPU's share, the memory's cap, the I/O's bandwidth, the process's count).
• The seccomp's filters (the system calls' restrictions: the whitelist or the blacklist of the system calls the process may invoke).
• The capabilities (the fine-grained's privileges: the process's capability's sets' restriction, the CapabilityBoundingSet's design).
• The LSM's profiles (the SELinux's types, the AppArmor's profiles: the mandatory access control's confinement).
• The chroot and the pivot_root (the file system's confinement: the process's root's directory's change).
• The systemd's hardening's directives (the services' confinement: the ProtectSystem, the ProtectHome, the PrivateTmp, the NoNewPrivileges, the RestrictAddressFamilies).
• The Landlock (the unprivileged's sandboxing: the file system's access's restriction for the unprivileged's processes).
• The virtual machines (the strongest's isolation: the hardware's virtualization, the hypervisor's confinement). The VMs are the unit's next's subject (Unit 13), and they are the sandbox's extreme's case.

The sandboxing's design's central's principle is the defence in depth (Lesson 12.1's principle): the sandbox's walls are the multiple's mechanisms, and the compromise requires the multiple's failures. A well-designed's sandbox (the Chrome's, the modern's containers) combines the namespaces, the seccomp, the capabilities' minimization, the LSM's profiles, and the cgroups, so the attacker who escapes one layer is still confined by the others. The observation is the reason the sandboxing is the modern security's central's architecture: the untrusted's code's execution is the unavoidable (the web, the applications, the containers), and the sandbox is the design that makes the execution's risk acceptable.

This lesson presents the sandboxing. It defines the isolation's goals and the confinement's spectrum. It presents the Linux namespaces (the eight namespaces and their isolation's semantics). It presents the control groups (the v1 and the v2 and the resource's controllers). It presents the seccomp's BPF filters (the system calls' restrictions and their design). It presents the chroot and the pivot_root (the file system's confinement), the containers (the Docker, the Podman, the LXC, and the OCI's standards), and the browsers' sandboxes (the Chrome's and the Firefox's designs). It presents the systemd's hardening's directives and the Landlock's unprivileged's sandboxing. It presents the sandbox's escapes' attacks and the sandboxing's design's principles. It closes with the sandboxing's role in the modern systems and the lesson's synthesis.

02 Learning objectives

This lesson contributes to U12.6 and U12.7, and to course learning outcomes CLO1, CLO7, and CLO8.

03 Required reading

• Operating System Concepts — Chapter 16, Security, the sections on the isolation's mechanisms, and Chapter 17, Protection. The standard treatment of the protection's mechanisms and the isolation's goals.
• OSTEP — the Security chapters, and the Virtualization chapters (the discussion of the containers and the VMs). OSTEP's treatment of the virtualization's mechanisms is the clearest available account of the isolation's designs, and it is the basis for the worked example in this lesson.
• Tanenbaum & Bos — Modern Operating Systems, Chapters 7 (the virtualization) and 9 (the security). A complementary treatment that develops the isolation's mechanisms from first principles.
• Kerrisk, M. — The Linux Programming Interface. No Starch Press, 2010. Chapters 20 (the signals), 24 (the process creation), 28 (the process's credentials), 37 (the daemons), and 61 (the sockets). The definitive reference for the Linux process's isolation's mechanisms.
• Kerrisk, M. — The Linux namespaces and the containers. The man 7 namespaces page and the LWN's articles ("The namespaces in the operating system"). The authoritative reference for the Linux namespaces.
• Rosen, R. — Resource Management: The Linux and the SUSE Approaches. The Novell/SUSE's and the RHEL's resource-management's guides. The authoritative references for the cgroups.
• Edge, J., & other LWN's authors. — The LWN's series on the seccomp's filters, the Landlock, and the container's security. The LWN's articles are the authoritative references for the modern's isolation's mechanisms.
• Reis, C. — Docker and the OCI: The container's standards. The OCI's specifications (the Runtime's Specification, the Image's Specification, the Distribution's Specification). The authoritative references for the container's standards.
• Rice, L. — Container Security. O'Reilly, 2020. The comprehensive treatment of the container's security's mechanisms and the escapes' attacks.
• Linux man pages: man 7 namespaces, man 2 clone, man 2 unshare, man 1 unshare, man 1 nsenter, man 2 setns, man 5 proc (the /proc/PID/ns/ interface), man 7 cgroups, man 1 systemd-cgls, man 1 systemd-cgtop, man 1 systemd-run, man 5 systemd.resource-control, man 2 seccomp, man 3 seccomp_init (the libseccomp), man 1 systemd-analyze (the security verb), man 2 chroot, man 1 chroot, man 2 pivot_root, man 8 docker, man 1 podman, man 1 docker-run, man 1 docker-exec, man 1 firejail, man 1 bubblewrap, man 7 landlock (if available), man 2 seccomp_unotify, man 5 systemd.exec, man 5 systemd.resource-control.

04 Core content

4.1 The sandbox and the confinement's spectrum

A sandbox is the isolated's environment in which the untrusted's code (or the untrusted's user's code) runs, with the walls that confine the code's capabilities to the minimum it needs. The sandbox's goals:

• The damage's limitation. The compromise's damage is the sandbox's damage, not the system's: the attacker who compromises the sandboxed's code has only the sandbox's resources.
• The least privilege's enforcement. The sandbox's code has only the resources it needs (the least privilege's principle), so the compromised's code's capabilities are the minimum.
• The isolation's guarantee. The sandbox's code cannot affect the system's other's components (the other processes, the other users, the other applications), and the system's other's components cannot affect the sandbox's code (except through the sandbox's allowed's channels).
• The multi-tenancy's support. The sandboxes can coexist on the same system (the server's containers, the browser's tabs, the mobile's applications), and each sandbox's code is confined to its own's resources.

The sandbox's confinement's spectrum is the range of the isolation's mechanisms, from the weakest (the chroot) to the strongest (the virtual machines):

The spectrum's central's observation: the mechanisms are the complementary, not the alternatives. The modern's sandboxes (the Chrome's, the containers) combine the mechanisms: the namespaces provide the isolation's view, the cgroups provide the resource's limits, the seccomp provides the system calls' filter, the capabilities provide the privilege's minimization, and the LSM's profiles provide the mandatory access control's policy. The combination's design is the defence in depth's principle (Lesson 12.1): the attacker must bypass the multiple's mechanisms, and the multiple's mechanisms' failures are the uncorrelated.

4.2 The Linux namespaces

The Linux namespaces are the kernel's mechanisms that give the processes the isolated's views of the system's resources. The namespace's design: the kernel's resources (the processes, the files, the networks, the IPC's objects, the users) are tagged with the namespace's identifier, and the processes see only the resources with their own's namespace's identifier. The namespaces' types (the eight):

The mount's namespace (CLONE_NEWNS)

The isolation of the file system's mount's points: the processes in the different mount's namespaces see the different file system's hierarchies. The mount's namespace's design: the processes' mount and umount operations affect only their own's namespace, so a container's file system's mounts are the container's, not the host's. The mount's namespace is the chroot's modern's successor: the container's file system's view is the namespace's mount's table, not the process's root's directory's change.

The PID's namespace (CLONE_NEWPID)

The isolation of the process's table: the processes in the different PID's namespaces have the different PID's numbers. The namespace's design: the first process in the new's namespace has the PID 1 (the init's process), and the processes' PIDs in the namespace are the namespace's internal's numbers; the host's kernel's view shows the processes with the host's PIDs (the namespace's PIDs' mapping). The design's consequence: the process in the namespace cannot see the other namespaces' processes (the /proc shows only the namespace's processes), and the PID 1's process's death kills the namespace's other processes.

The network's namespace (CLONE_NEWNET)

The isolation of the network's stack: the processes in the different network's namespaces have the different network's interfaces, the different routing's tables, the different firewall's rules, the different sockets. The namespace's design: the new's network's namespace starts with only the loopback's interface, and the administrator (or the container's runtime) configures the namespace's interfaces (the virtual's Ethernet pairs, the bridges, the IP's addresses). The network's namespace is the containers' network's isolation's mechanism: the container's processes see only the container's network, and the container's network is the virtual's Ethernet's pair, which connects to the host's bridge (or the overlay's network).

The user's namespace (CLONE_NEWUSER)

The isolation of the user's and the group's IDs: the processes in the different user's namespaces have the different UIDs and GIDs' mappings. The namespace's design: the namespace's process can be the root (the UID 0) inside the namespace while the host's kernel sees the process with the namespace's owner's UID (the unprivileged's user's UID), so the unprivileged's user can create the namespace and be the root inside it (the rootless's containers). The namespace's subtlety: the mapping is the explicit (the /proc/PID/uid_map and the /proc/PID/gid_map), and the mapping's design determines the namespace's capabilities (the mapped's UIDs have the namespace's privileges, the unmapped's UIDs have the none).

The IPC's namespace (CLONE_NEWIPC)

The isolation of the System V's IPC and the POSIX's message queues: the processes in the different IPC's namespaces have the different IPC's objects (the shared's memory's segments, the semaphores, the message's queues). The design's purpose: the processes' IPC's isolation, so the container's processes cannot see the host's IPC's objects.

The UTS's namespace (CLONE_NEWUTS)

The isolation of the hostname and the NIS's domain name: the processes in the different UTS's namespaces have the different hostnames. The design's name: the UTS is the Unix Time-sharing System (the historical's name), and the namespace's design's purpose is the containers' hostname's isolation.

The cgroup's namespace (CLONE_NEWCGROUP)

The isolation of the cgroup's hierarchy's view: the processes in the different cgroup's namespaces see the different cgroup's hierarchies (the /proc/PID/cgroup and the /sys/fs/cgroup's views). The design's purpose: the container's processes see only the container's cgroup's subtree, so the container's processes cannot see the host's cgroup's structure.

The time's namespace (CLONE_NEWTIME)

The isolation of the boot's time and the monotonic's clock's offsets: the processes in the different time's namespaces have the different offsets. The namespace's design is the newest (the Linux 5.6), and its purpose is the containers' time's isolation (the containers can have the different CLOCK_MONOTONIC and CLOCK_BOOTTIME's values, so the containers can be checkpointed and restored).

The namespaces' management's mechanisms:

• The clone's system call (man 2 clone). The system call that creates the new's processes with the namespace's flags (the CLONE_NEWNS, the CLONE_NEWPID, the CLONE_NEWNET, the CLONE_NEWUSER, the CLONE_NEWIPC, the CLONE_NEWUTS, the CLONE_NEWCGROUP, the CLONE_NEWTIME). The new's process runs in the new's namespaces, and the process's children inherit the namespaces.
• The unshare's system call and the unshare's command. The mechanism that moves the calling's process into the new's namespaces (without the clone's new's process). The unshare's command (the util-linux's tool) is the administrator's and the developer's tool for the namespace's experiments: unshare --mount --pid --fork --mount-proc /bin/bash creates a new's shell with the new's mount and PID's namespaces.
• The setns's system call and the nsenter's command. The mechanism that moves the calling's process into the existing's namespaces (the /proc/PID/ns/'s file descriptors). The nsenter's command is the administrator's tool for the entering of a container's namespaces: nsenter --target <PID> --mount --pid --net /bin/bash enters the container's namespaces and runs the shell inside them.
• The /proc/PID/ns/'s interface. The kernel exposes the process's namespaces as the symbolic links (/proc/PID/ns/mnt, the /proc/PID/ns/pid, the /proc/PID/ns/net, the /proc/PID/ns/user, the /proc/PID/ns/ipc, the /proc/PID/ns/uts, the /proc/PID/ns/cgroup, the /proc/PID/ns/time), and the process can open the links and pass the file descriptors to the setns's call. The /proc/PID/ns/'s links' values (the mnt:[4026531840]'s format) are the namespace's identifiers, and the processes with the same identifier share the namespace.
• The ip netns's command. The iproute2's tool for the network's namespaces' management: the ip netns add creates a named's network's namespace (the /var/run/netns/'s bind mount), the ip netns list lists them, the ip netns exec runs a command in the namespace, and the ip netns del deletes it.

The namespaces' design's observations:

• The namespaces are the views, not the limits. The namespaces isolate the processes' views of the resources, but they do not limit the processes' usage of the resources. The limits are the cgroups' role (section 4.3), and the two mechanisms are the complementary.
• The namespaces' capabilities' checks are the privileged's operations. The namespace's creation requires the CAP_SYS_ADMIN's capability (the classic's requirement), except the user's namespace (the CLONE_NEWUSER is the unprivileged's since the Linux 3.8), and the user's namespace is the rootless's containers' foundation.
• The namespace's nesting. The namespaces can be nested (the namespace's process can create the new's namespaces within it), and the nesting's design is the containers' the-inside's containers (the Docker's in the Docker's) and the rootless's containers' mechanism.

4.3 The control groups (cgroups)

The control groups (cgroups) are the kernel's mechanisms that limit and account the processes' resource's usage. The cgroups' design: the processes are organized into the hierarchy of the groups (the cgroups), and the resource's controllers (the subsystems) attach to the groups and enforce the resource's limits. The cgroups' two versions:

The cgroups v1 (the classical's design)

The v1's design: the multiple hierarchies, one per the resource's controller (the cpu's hierarchy, the memory's hierarchy, the blkio's hierarchy, the pids's hierarchy, and the others). The process can be in the different groups in the different hierarchies, and the controllers' limits are the separate. The v1's design's disadvantage: the complexity (the multiple hierarchies, the controllers' interactions, the inconsistent's semantics), and the observation is the reason the v2 replaced it.

The cgroups v2 (the unified's design)

The v2's design: the single's hierarchy (the /sys/fs/cgroup/'s unified's tree), with the controllers attached to the groups' nodes (the cgroup.controllers, the cgroup.subtree_control). The v2's design's advantages: the consistency (the single hierarchy, the controllers' coherent's semantics), the delegation (the unprivileged's users can manage the sub-hierarchies), the pressure's information (the cgroup.pressure's interfaces: the /proc/pressure/'s and the cgroup.pressure's metrics), and the nesting (the container's runtime can create the sub-cgroups). The modern's distributions (the Fedora's, the Ubuntu's recent, the Debian's recent) use the v2 by default, and the v1's controllers' migration is the ongoing.

The cgroups' resource's controllers:

• The cpu's controller. The CPU's time's allocation: the cpu.weight (the relative's share: the v2's design, the 1–10000's range) and the cpu.max (the absolute's quota: the <quota> <period>'s format, for example the "200000 1000000" for the 20% of the one CPU).
• The memory's controller. The memory's limits: the memory.max (the hard's limit: the cgroup's processes' total's memory's usage's cap, and the exceeding's allocation fails), the memory.high (the soft's limit: the exceeding's allocation is throttled), the memory.low and the memory.min (the protection's limits: the pages' reclaim's preference), and the memory.swap.max (the swap's limit).
• The io's controller. The I/O's limits: the io.weight (the relative's share), the io.max (the per-device's absolute's limit: the the major:minor the rbps=... the wbps=... the riops=... the wiops=...'s format), and the io.latency (the latency's target: the cgroup's I/O's latency's guarantee).
• The pids's controller. The process's count's limit: the pids.max (the maximum's number of the processes and the threads in the cgroup, and the exceeding's fork fails). The controller's purpose: the fork's bomb's prevention (the process's count's limit bounds the damage).
• The other's controllers. The cpuset (the CPU's and the memory's nodes' binding), the hugetlb (the huge pages' limit), the freezer (the cgroup's processes' freezing), the rdma (the RDMA's resources' limit), the devices (the devices' access's control: the cgroup's allow or deny of the device's nodes), and the net_cls and the net_prio (the network's classification and the priority).

The cgroups' management's mechanisms:

• The /sys/fs/cgroup/'s interface. The cgroups' file system: the administrator creates the cgroups (the directories), sets the controllers' limits (the files' writes), and moves the processes into the cgroups (the cgroup.procs's and the cgroup.threads's files' writes).
• The systemd's integration. The systemd manages the cgroups on the modern's systems: the services are the cgroups (the system.slice, the user.slice, the machine.slice), the services' units' resource's directives (the CPUWeight, the CPUQuota, the MemoryMax, the MemoryHigh, the IOWeight, the TasksMax, and the others) configure the limits, and the tools (systemd-cgls, the systemd-cgtop, the systemctl status) display the cgroups' state.
• The systemd-run's command. The tool that creates the transient's services (the systemd-run --unit=myjob --property=MemoryMax=1G --property=CPUQuota=50% command), and the tool is the administrator's and the developer's mechanism for the ad-hoc's resource's limits.
• The cgroupfs's and the cgroup2's mounts. The v1's multiple's mounts (the /sys/fs/cgroup/cpu, the /sys/fs/cgroup/memory, the others) and the v2's single's mount (the /sys/fs/cgroup/), with the cgroup_no_v1='s and the systemd.unified_cgroup_hierarchy=1's kernel's parameters controlling the version.

The cgroups' design's observations:

• The cgroups are the limits, not the isolation. The cgroups limit the processes' resource's usage, but they do not isolate the processes' views. The isolation is the namespaces' role, and the two are the complementary (the section 4.1's observation).
• The cgroups' metrics. The cgroups expose the processes' resource's usage (the cpu.stat, the memory.current, the io.stat, the pids.current), so the administrator can monitor the usage and tune the limits. The pressure's stall's information (the cpu.pressure, the memory.pressure, the io.pressure) shows the resource's contention, and the information is the modern's monitoring's basis.
• The cgroups' delegation. The v2's design supports the delegation: the unprivileged's user (or the container's runtime) can create the sub-cgroups within the delegated's cgroup (the systemd's Delegate=yes's directive), and the delegation's design is the rootless's containers' and the user's sessions' foundation.

4.4 The seccomp's filters

The seccomp (the secure computing's mode) is the kernel's mechanism that filters the process's system calls. The mechanism's design: the process installs the BPF's filter (the Berkeley Packet Filter's program) that the kernel evaluates on the every's system call, and the filter's action determines the system call's fate: the SECCOMP_RET_ALLOW (the system call's execution), the SECCOMP_RET_ERRNO (the system call returns the specified's error), the SECCOMP_RET_KILL_PROCESS (the process is killed), the SECCOMP_RET_KILL_THREAD (the thread is killed), the SECCOMP_RET_TRAP (the SIGSYS's signal's delivery), the SECCOMP_RET_TRACE (the tracer's notification), the SECCOMP_RET_LOG (the system call's logging), and the SECCOMP_RET_USER_NOTIF (the user-space's supervisor's notification).

The seccomp's modes:

• The strict's mode (SECCOMP_MODE_STRICT). The original's mode: the process can invoke only the read, the write, the _exit, and the sigreturn's system calls. The mode's design's purpose: the minimal's filter for the untrusted's code, and its use is the rare (the modern's systems use the filter's mode).
• The filter's mode (SECCOMP_MODE_FILTER). The modern's mode: the process installs the BPF's program that filters the arbitrary's system calls, and the program's action determines the fate. The mode's design's advantages: the flexibility (the arbitrary's filters), the performance (the BPF's compiled's program's evaluation's efficiency), and the composability (the multiple's filters' stacking, the seccomp's filters' addition's restriction: the additional's filters can only be the more restrictive).

The seccomp's design's observations:

• The seccomp's filter is the attack's surface's reduction. The system calls are the kernel's interface, and the kernel's bugs (the vulnerabilities) are the system calls' exploits. The seccomp's filter reduces the exposed's system calls, so the kernel's attack's surface is the smaller. The observation is the reason the browsers (the Chrome's and the Firefox's sandboxes) and the containers (the Docker's default's profile) use the seccomp's filters: the untrusted's code's system calls are the restricted's set, so the kernel's vulnerabilities' exploitation is the harder.
• The seccomp's filter's design's subtleties. The filter's whitelist (the allow's list: the system calls the process may invoke, and the every's other's system call is the denied) is the stronger's design; the filter's blacklist (the deny's list: the system calls the process may not invoke) is the weaker (the unknown's system calls are the allowed). The filter's granularity: the seccomp's filter can inspect the system call's number and its arguments (the scalar's values, the pointers' values, not the pointed's data), so the filter's design can be the fine-grained (the open's arguments' flags' inspection) or the coarse-grained (the system call's number's only).
• The libseccomp's library. The user-space's library that generates the BPF's filters from the high-level's descriptions (the seccomp_rule_add's calls), and the library is the developers' tool for the seccomp's filters' design. The systemd's SystemCallFilter='s directive uses the library (or the pre-defined's groups: the @system-service, the @basic-io, the @network-io, the @process), and the containers' runtimes use the library for the default's profiles.

4.5 The chroot and the pivot_root

The chroot is the classical's file system's confinement's mechanism: the chroot's system call changes the process's root's directory (the /'s view) to the specified's directory, so the process and its children see the specified's directory as the root. The mechanism's design's purpose: the file system's view's restriction (the process cannot access the files outside the chroot's directory by the absolute's paths). The mechanism's design's weakness: the chroot is not the security's boundary. The process with the CAP_SYS_CHROOT's capability can escape (the chroot's nesting's tricks, the chdir's tricks), and the root's process can escape by the multiple's mechanisms (the /proc's access, the mknod's device's creation, the ptrace's debugging). The observation is the reason the chroot is the convenience's mechanism (the build's environments, the legacy's services), not the security's: the modern's sandboxes use the mount's namespace (the CLONE_NEWNS) and the pivot_root's mechanism instead.

The pivot_root is the modern's mechanism: the pivot_root's system call changes the process's root's and the current's directory to the new's file system, and it moves the old's root to the specified's directory (the put_old). The mechanism's design's difference from the chroot: the pivot_root changes the root's mount, not the directory, so the old's root is the separate's mount (the put_old's directory), and the process can unmount it (the umount's operation), so the escape's paths (the /proc's, the chroot's) are the closed. The pivot_root is the containers' runtimes' mechanism (the runc's, the crrun's, the LXC's): the container's file system is the mount's namespace's root, and the host's file system is the unmounted's (or the hidden's) mount.

4.6 The containers

The containers are the modern's sandboxing's architecture: the processes (the container's processes) run in the isolated's environment (the container), and the environment is the combination of the namespaces, the cgroups, the seccomp's filters, the capabilities' minimization, the LSM's profiles, and the container's file system (the image's layers). The containers' design's observation: the containers are not the virtual machines (the containers share the host's kernel, and the VMs have the separate's kernel), and the containers' isolation is the kernel's mechanisms' (the namespaces and the cgroups), while the VMs' isolation is the hardware's virtualization's (the hypervisor and the separate's kernel).

The containers' components:

• The container's image. The file system's template: the layered's file system (the OCI's image's specification: the layers are the tar's archives, and the layers are the stacked's file systems via the overlayfs's union mount), the image's configuration (the entrypoint, the command, the environment's variables, the exposed's ports), and the image's metadata.
• The container's runtime. The program that creates the container's environment: the low-level's runtimes (the runc, the crun) create the namespaces, the cgroups, the seccomp's filters, and the file system's mounts; the high-level's runtimes (the Docker's containerd, the Podman's conmon, the LXC's lxc-start) manage the container's lifecycle (the image's pulling, the container's creation, the container's start, the container's stop, the logs).
• The container's engine. The user-facing's tool: the Docker's dockerd, the Podman's podman (the daemonless's design), the LXC's lxc-*, the Kubernetes's kubelet (the orchestrator's agent). The engine's design varies: the Docker's daemon's architecture (the client's and the daemon's separation), the Podman's daemonless's design (the rootless's containers' support), and the Kubernetes's declarative's design.
• The container's standards. The Open Container Initiative (the OCI) defines the standards: the Runtime's Specification (the container's configuration and the runtime's interface), the Image's Specification (the image's format and the layers), and the Distribution's Specification (the registry's protocol). The standards' purpose: the interoperability (the same image runs on the different runtimes: the Docker, the Podman, the containerd, the CRI-O), and the standards' design is the container's ecosystem's foundation.

The containers' security's mechanisms:

• The namespaces. The container's runtime creates the container's namespaces (the mount, the PID, the network, the user, the IPC, the UTS, the cgroup), so the container's processes see only the container's resources.
• The cgroups. The container's runtime places the container's processes in the container's cgroup, and the cgroup's controllers (the cpu, the memory, the io, the pids) limit the processes' resource's usage.
• The seccomp's filter. The container's runtime installs the default's seccomp's filter (the Docker's and the Podman's default's profiles: the ~44's blocked's system calls, including the mount, the reboot, the kexec_load, the init_module, the ptrace), so the container's processes' system calls are the restricted's set.
• The capabilities' minimization. The container's runtime drops the unnecessary's capabilities (the Docker's default: the CAP_CHOWN, the CAP_DAC_OVERRIDE, the CAP_FOWNER, the CAP_KILL, the CAP_NET_BIND_SERVICE, the CAP_NET_RAW, the CAP_SETGID, the CAP_SETUID, the ~14), and the --cap-drop=ALL --cap-add=CAP_*'s options let the administrator's finer's control.
• The LSM's profiles. The container's runtime applies the SELinux's or the AppArmor's profile (the Docker's default: the docker-default's AppArmor's profile, or the SELinux's container_t's type), so the container's processes' accesses are the mandatory access control's confined.
• The user's namespace and the rootless's containers. The container's runtime can use the user's namespace (the --userns=host's default's change), so the container's root (the UID 0 inside) is the unprivileged's user (the UID 1000's mapping) on the host, and the container's root's privileges are the bounded (the rootless's containers: the Podman's default's design).
• The read-only's file system and the tmpfs's mounts. The container's file system can be the read-only (the --read-only's option), and the writable's paths are the tmpfs's mounts, so the container's processes cannot modify the image's layers, and the persistence is the explicit (the volumes' mounts).

The containers' design's observations:

• The containers' isolation's strength. The containers' isolation is the kernel's mechanisms' (the namespaces and the cgroups), and the containers' security depends on the kernel's security: a kernel's vulnerability (the Dirty COW, the Dirty Pipe, the OverlayFS's bugs) can be the container's escape's vector, and the containers' shared's kernel is the VMs' separate's kernel's security's difference. The observation is the reason the high-security's multi-tenancy uses the VMs (or the VM's and the container's combination: the Kata Containers, the gVisor, the Firecracker), and the containers' use is the trusted's or the single-tenant's workloads.
• The containers' ecosystem's security's concerns. The containers' security includes the image's security (the base's image's vulnerabilities, the dependencies' vulnerabilities, the secrets' leakage), the registry's security (the images' signing, the trusted's registries), the runtime's security (the runtime's vulnerabilities, the configuration's mistakes), and the orchestration's security (the Kubernetes's RBAC, the network's policies, the secrets' management). The security's concerns are the modern's container's security's central's subjects.

4.7 The browsers' sandboxes

The browsers are the modern systems' most visible sandboxes, and their designs are the sandboxing's case studies. The browsers' threat's model: the web's pages (the JavaScript, the HTML, the CSS, the WebAssembly, the plugins) are the untrusted's code, and the browser must execute the code without the code compromising the user's system. The browsers' sandboxing's designs:

The Chrome's sandbox

The Chrome's design: the multi-process's architecture (the browser's process, the renderer's process per site, the GPU's process, the utility's processes) and the renderer's sandbox. The renderer's sandbox's mechanisms: the chroot (the file system's view's restriction to the minimal's set of the files), the seccomp's filter (the system calls' whitelist, the platform-specific's filters), the clone's namespaces (the Linux: the PID's, the network's, the user's, and the IPC's namespaces), the setuid's and the setgid's sandbox's user (the dedicated's unprivileged's user), the capabilities' dropping, and the pledge's and the unveil's mechanisms (the OpenBSD's), the sandbox_init's (the macOS's Seatbelt's profiles). The renderer's process has no direct access to the file system (the accesses are the broker's process's mediation: the IPC's requests), and the renderer's system calls are the whitelist's set.

The Firefox's sandbox

The Firefox's design: the multi-process's architecture (the parent's process, the content's processes, the GPU's process) and the content's processes' sandbox. The content's sandbox's mechanisms: the seccomp-bpf's filter (the Linux's, the default's enabled), the chroot's (the file system's view's restriction, the macOS's and the Linux's), the user's namespace's (the Linux's), the capabilities' dropping, the file's access's brokering (the parent's process's mediation), and the Windows's and the macOS's platform-specific's sandboxes. The Firefox's sandbox's levels (the content, the socket, the utility, the widevine) and the settings (security.sandbox.content.level) determine the confinement's strength.

The browsers' sandboxing's observations:

• The browsers' sandbox is the multi-process's architecture's application. The renderer's process (the untrusted's code's executor) is the sandboxed's process, and the browser's process (the trusted's broker) is the privileged's process. The architecture's design: the untrusted's code's compromise (the renderer's process) gives the attacker only the renderer's process's resources, and the escape requires the sandbox's bypass (the kernel's vulnerability, the broker's IPC's vulnerability, the configuration's mistake).
• The sandbox's trade-offs. The sandbox's design has the performance's cost (the IPC's brokering's overhead, the process's creation's cost) and the compatibility's cost (the sandbox's restrictions can break the legitimate's pages' features). The observation is the reason the browsers' sandboxes have the escape's hatches (the --no-sandbox's option, the plugin's processes' less restricted's sandboxes), and the hatches' designs are the security's and the usability's tension's examples.

4.8 The systemd's hardening's directives

The systemd is the modern's Linux's init's system and the services' manager, and its sandboxing's directives are the services' confinement's mechanisms. The directives:

• The file system's directives. The ProtectSystem=strict (the /usr, the /boot, the /etc's read-only's mounts), the ProtectHome=yes (the /home, the /root, the /run/user's inaccessibility), the ReadWritePaths= and the ReadOnlyPaths= (the specific's paths' access's modification), the InaccessiblePaths= (the paths' hiding), the PrivateTmp=yes (the private's /tmp and the /var/tmp), the PrivateDevices=yes (the private's /dev with only the null, the zero, the full, the random, the urandom, the tty), and the ProtectKernelTunables=yes (the /proc/sys, the /sys's read-only's mounts).
• The user's and the group's directives. The User= and the Group= (the service's user's and group's identities), the DynamicUser=yes (the transient's user's and group's allocation), the SupplementaryGroups= (the additional's groups' specification), and the RemoveIPC=yes (the IPC's objects' removal on the service's stop).
• The capabilities' and the privilege's directives. The CapabilityBoundingSet= (the service's capabilities' limit), the AmbientCapabilities= (the service's ambient's capabilities), the NoNewPrivileges=yes (the setuid's and the capabilities' programs' privilege's escalation's prevention), and the SecureBits= (the kernel's securebits's flags).
• The namespaces' directives. The PrivateMounts=yes (the private's mount's namespace), the PrivateNetwork=yes (the private's network's namespace with only the loopback), the PrivateUsers=yes (the private's user's namespace), the PrivateIPC=yes (the private's IPC's namespace), the ProtectHostname=yes (the private's UTS's namespace), and the ProtectClock=yes (the clock's modification's prevention).
• The system calls' and the addressing's directives. The SystemCallFilter= (the seccomp's filter: the @system-service's group, the ~@privileged's denial, the specific's system calls), the SystemCallArchitectures= (the system calls' architectures' restriction), the RestrictAddressFamilies= (the socket's address's families' restriction: the AF_UNIX, the AF_INET, the AF_INET6), the RestrictNamespaces= (the namespace's creation's restriction), and the LockPersonality=yes (the personality's system call's restriction).
• The memory's and the kernel's directives. The MemoryDenyWriteExecute=yes (the writable's and the executable's memory's mappings' prevention: the JIT's code's prevention), the RestrictRealtime=yes (the real-time's scheduling's restriction), the RestrictSUIDSGID=yes (the setuid's and the setgid's bits' creation's prevention), the ProtectKernelModules=yes (the kernel's modules' loading's prevention), the ProtectKernelLogs=yes (the kernel's log's reading's prevention), and the ProtectProc=invisible (the /proc's view's hiding).

The systemd's directives' management's tools: the systemd-analyze security's command evaluates the service's sandbox's strength and produces the score (the exposure's level: the OK, the EXPOSED, the MEDIUM, the UNSAFE), the systemd-run's command creates the transient's services with the directives, and the unit's files (/etc/systemd/system/*.service, the [Service]'s section) hold the persistent's configuration. The observation is the reason the modern's distributions ship the services' units with the sandboxing's directives (the ProtectSystem=strict, the NoNewPrivileges=yes, the SystemCallFilter=@system-service): the directives' defaults are the security's sensible's choices, and the observation is the psychological acceptability's principle's application (Lesson 12.1's principle 8).

4.9 The Landlock and the unprivileged's sandboxing

The Landlock is the Linux's mechanism for the unprivileged's sandboxing (the Linux 5.13). The mechanism's design: the process (the unprivileged's, without the CAP_SYS_ADMIN's capability) creates the Landlock's domain and attaches the rules that restrict the process's file system's accesses. The rules' design: the access's rights (the LANDLOCK_ACCESS_FS_EXECUTE, the LANDLOCK_ACCESS_FS_READ_FILE, the LANDLOCK_ACCESS_FS_WRITE_FILE, the LANDLOCK_ACCESS_FS_READ_DIR, the LANDLOCK_ACCESS_FS_REMOVE_DIR, the LANDLOCK_ACCESS_FS_REMOVE_FILE, the LANDLOCK_ACCESS_FS_MAKE_*) are the restricted's operations, and the rules' scope is the specified's paths (the file's or the directory's hierarchy). The mechanism's restriction: the Landlock's rules are the additional's restrictions (the rules can only remove the accesses, not grant them), so the sandbox's design is the least privilege's (the process's accesses are the subset of the accesses the process would otherwise have).

The Landlock's design's advantages: the unprivileged's use (the process does not need the CAP_SYS_ADMIN's capability, so the ordinary's applications can sandbox themselves), the composability (the Landlock's domains can be stacked, and the multiple's domains' rules are the intersection), and the file system's focus (the mechanism's design is the file system's accesses' restriction, which is the common's sandboxing's need). The Landlock's design's limitations: the file system's only's scope (the mechanism does not restrict the network, the IPC, or the other resources: the seccomp and the namespaces are the complementary's mechanisms), and the kernel's version's requirement (the Linux 5.13+, and the ABI's versions' extensions: the Linux 5.19's and the 6.x's additions).

The unprivileged's sandboxing's other's mechanisms:

• The bubblewrap's tool. The container's runtime's lightweight's tool (the Flatpak's and the GNOME's foundation): the bwrap's command creates the sandboxed's environment (the namespaces, the bind mounts, the seccomp's filters, the capabilities' dropping), and the tool's design is the unprivileged's user's (the user's namespace's use).
• The firejail's tool. The user-space's sandboxing's tool: the firejail's command runs the program with the sandbox (the namespaces, the seccomp's filters, the capabilities' dropping, the AppArmor's profiles, the firejail's profiles' library), and the tool's design is the administrator's and the developer's convenience's mechanism.
• The systemd-run --user's mechanism. The systemd's user's services: the systemd-run --user creates the transient's user's services with the sandboxing's directives (the ProtectSystem, the PrivateTmp, the NoNewPrivileges, the SystemCallFilter), and the mechanism's design is the unprivileged's user's sandboxing's convenience.

4.10 The sandbox's escapes and the attacks

The sandbox's escape is the attacker's bypass of the sandbox's walls, and the escape's mechanisms are the sandbox's design's weaknesses:

• The kernel's vulnerabilities. The sandbox's walls are the kernel's mechanisms (the namespaces, the seccomp, the LSM, the capabilities), and the kernel's bugs (the privilege's escalation's vulnerabilities, the use-after-free, the race conditions, the memory's corruptions) are the escape's vectors. The classical's examples: the Dirty COW (the CVE-2016-5195: the copy-on-write's race), the Dirty Pipe (the CVE-2022-0847: the pipe's buffers' overwrite), the OverlayFS's bugs (the CVE-2021-3493, the CVE-2023-0386), and the io_uring's bugs. The observation is the reason the containers' security depends on the kernel's security: the containers share the kernel, and the kernel's vulnerability compromises the every container.
• The configuration's mistakes. The sandbox's strength depends on the configuration: the missing's seccomp's filter, the excessive's capabilities, the disabled's LSM's module, the --privileged's flag (the Docker's flag: the full's host's privileges), the --pid=host's or the --net=host's flags (the host's namespaces' sharing), the mounted's sensitive's paths (the -v /:/host's mount: the host's root's exposure), the docker.sock's mount (the container's control of the Docker's daemon: the full's host's compromise). The observation is the reason the containers' security's practice includes the configuration's review (the CIS's Docker's benchmark, the Kubernetes's hardening's guides).
• The design's flaws. The sandbox's design can have the flaws: the incomplete's mediation (the seccomp's filter's missing's system calls), the incorrect's assumptions (the path's confinement's hard links' bypass: the AppArmor's profile's paths are the names, and the hard links can bypass the path's check), the IPC's channels (the sandbox's broker's interface: the broker's vulnerability is the escape's vector), and the shared's resources (the shared's memory, the device's nodes, the mounted's file systems).
• The side channels. The sandbox's isolation does not cover the side channels: the timing's channels (the CPU's caches' timing), the speculative's execution (the Spectre's and the Meltdown's attacks: the CPU's microarchitectural's leaks), the power's channels, and the electromagnetic's channels. The side channels' defence requires the hardware's mitigations (the microcode's updates, the kernel's mitigations: the page-table's isolation, the branch's prediction's hardening), and the observation is the reason the VMs' or the separate's hardware's designs are the high-security's choices.

The escapes' defensive's practices:

• The kernel's updates. The kernel's security's patches' application is the escapes' prevention's foundation: the vulnerabilities are the published, and the unpatched's kernel is the vulnerable's.
• The configuration's minimization. The sandbox's configuration should have the minimum's privileges: the --cap-drop=ALL and the --cap-add='s specific's capabilities, the --security-opt's options (the no-new-privileges, the seccomp=, the apparmor=), the read-only's file system, the non-root's user, and the no-host's namespaces.
• The defence in depth's layering. The sandbox's walls should be the multiple's: the namespaces, the cgroups, the seccomp, the capabilities, the LSM, the user's namespace, the read-only's file system. The multiple's walls' failures are the uncorrelated, and the escape requires the multiple's bypasses.
• The monitoring and the detection. The sandbox's audit's logs (the SELinux's avc's denials, the seccomp's SECCOMP_RET_LOG's events, the container's runtime's logs) and the system's monitoring (the anomaly's detection: the unusual's system calls, the unexpected's network's connections) can detect the escape's attempts and the ongoing's compromises.

4.11 The sandboxing's design principles

The sandboxing's design applies the Lesson 12.1's principles, and the specific's applications:

• The least privilege (the principle 6). The sandbox's code has the minimum's resources: the namespaces' minimal's views, the cgroups' tight's limits, the seccomp's whitelist's filters, the capabilities' dropped's sets, the LSM's profiles' confined's policies.
• The fail-safe defaults (the principle 2). The sandbox's default is the denial: the container's default's capabilities are the dropped's set, the default's seccomp's filter is the restrictive's set, the default's user is the unprivileged's, and the default's file system is the read-only's.
• The complete mediation (the principle 3). The sandbox's every access is mediated: the namespaces' every view's check, the cgroups' every resource's accounting, the seccomp's every system call's filter, the LSM's every access's policy's check. The incomplete's mediation (the missing's seccomp's rules, the unconfined's paths) is the escape's vector.
• The economy of mechanism (the principle 1). The sandbox's mechanism is the simple and the small: the small reference's monitor (the kernel's mediation), the simple's seccomp's filters, the minimal's capabilities' sets. The complexity (the excessive's rules, the unnecessary's features) is the bugs' and the misconfigurations' source.
• The separation of privilege (the principle 5). The sandbox's critical's operations require the multiple's conditions: the multi-factor's authentication for the privileged's operations, the separation of duties for the sensitive's changes.
• The least common mechanism (the principle 7). The sandbox's shared's resources are the minimized: the per-sandbox's namespaces, the per-sandbox's file systems, the per-sandbox's networks. The shared's kernel is the containers' design's limitation (the VMs' separate's kernel is the alternative).
• The psychological acceptability (the principle 8). The sandbox's mechanism is the usable: the sensible's defaults (the systemd's directives, the Docker's default's profiles), the escape's hatches for the legitimate's needs (the --privileged's flag, the --no-sandbox's option), and the understandable's configuration. The inusable's sandbox (the excessive's complexity, the constant's breakages) is the bypassed's sandbox.
• The open design (the principle 4). The sandbox's mechanism is the public and the auditable: the open-source's implementations (the Linux's kernel, the containers' runtimes), the standardized's interfaces (the OCI's specifications), and the reviewable's configurations.

4.12 Common misconceptions

05 Worked example

The following example traces a sandbox's creation with the unshare's and the bubblewrap's tools, computes the sandbox's walls, and evaluates a service's sandbox's strength with the systemd-analyze security's command.

# The minimal's sandbox: the new's mount and PID and UTS's
# namespaces, with the new's mount's propagation's control
sudo unshare --mount --pid --fork --uts --mount-proc \
    /bin/bash -c '
        echo "The sandbox is running."
        echo "The PID: $$"
        echo "The hostname: $(hostname)"
        echo "The hostname's change:"
        hostname sandbox
        hostname
        echo "The processes:"
        ps aux
    '

# Install a seccomp's filter that denies the 'chmod' system call
# (the 'chmod' is the syscall's number 90 on x86_64)
# The following is the conceptual's demonstration;
# the practical's use is via the libseccomp or the systemd.

# The Python's example with the seccomp's library:
python3 -c '
import seccomp
filter = seccomp.SyscallFilter(defaction=seccomp.ALLOW)
filter.add_rule(seccomp.ERRNO(1), "chmod")
filter.add_rule(seccomp.ERRNO(1), "fchmod")
filter.load()
import os
os.chmod("/tmp/test", 0o777)
'

# Evaluate the sshd's service's sandbox
systemd-analyze security sshd 2>/dev/null | head -40

# Evaluate the systemd's own's service
systemd-analyze security systemd-journald 2>/dev/null | head -40

# The output shows the service's exposure's score
# (the 0.0 is the perfect's sandbox, the 10.0 is the
# unsandboxed's service) and the per-directive's
# assessment (the OK, the MEDIUM, the EXPOSED).

# The example's output (the abbreviated):
#   NAME                                        DESCRIPTION                                       EXPOSURE
#   ✗ PrivateNetwork=                           Service has access to the host's network          0.5
#   ✗ User=/DynamicUser=                        Service runs as root user                         0.4
#   ✗ CapabilityBoundingSet=~CAP_SYS_ADMIN      Service has the CAP_SYS_ADMIN's capability       0.2
#   ✓ PrivateTmp=                               Service has a private's /tmp                       —
#   ...
#   Overall exposure level for sshd.service: 9.6 UNSAFE 😱

# Run a container with the default's configuration
docker run -d --name test-container alpine sleep 3600 2>/dev/null

# Inspect the container's security's configuration
docker inspect test-container 2>/dev/null | \
    grep -A5 -E 'CapDrop|CapAdd|SecurityOpt|ReadonlyRootfs|Privileged|User|PidMode|NetworkMode'

# The output shows the container's dropped's capabilities
# (the CapDrop: the ALL's list, the CapAdd: the default's set),
# the SecurityOpt (the seccomp's filter, the AppArmor's profile,
# the no-new-privileges's flag), the ReadonlyRootfs's status,
# the Privileged's flag, the User, the PidMode, the NetworkMode.

# Show the container's namespaces
ls -la /proc/$(docker inspect -f '{{.State.Pid}}' test-container 2>/dev/null)/ns/ 2>/dev/null

# Show the container's cgroup's limits
cat /sys/fs/cgroup/system.slice/docker-*.scope/memory.max 2>/dev/null
cat /sys/fs/cgroup/system.slice/docker-*.scope/cpu.max 2>/dev/null

# Show the container's seccomp's status
grep Seccomp /proc/$(docker inspect -f '{{.State.Pid}}' test-container 2>/dev/null)/status 2>/dev/null

# Show the container's capabilities
capsh --print 2>/dev/null | head -5
sudo nsenter -t $(docker inspect -f '{{.State.Pid}}' test-container 2>/dev/null) -a capsh --print 2>/dev/null | head -10

# Clean up
docker rm -f test-container 2>/dev/null

06 Interactive activity

07 Knowledge check

08 Unit discussion

09 Practice exercise

10 Summary

• A sandbox is the isolated's environment in which the untrusted's code runs, with the walls that confine the code's capabilities. The sandbox's goals: the damage's limitation, the least privilege's enforcement, the isolation's guarantee, and the multi-tenancy's support. The confinement's spectrum ranges from the chroot to the virtual machines, and the mechanisms are the complementary (the defence in depth).
• The Linux namespaces give the processes the isolated's views: the mount, the PID, the network, the user, the IPC, the UTS, the cgroup, and the time. The management's mechanisms: the clone, the unshare, the setns, the /proc/PID/ns/'s interface, and the ip netns's command.
• The control groups (cgroups) limit and account the processes' resource's usage. The v1's design is the multiple hierarchies (one per the controller); the v2's design is the single hierarchy. The controllers: the cpu, the memory, the io, the pids, and the others.
• The seccomp filters the process's system calls: the BPF's filters with the actions (SECCOMP_RET_ALLOW, SECCOMP_RET_ERRNO, SECCOMP_RET_KILL_PROCESS, the others). The seccomp is the attack's surface's reduction, and it is the containers' and the browsers' central's mechanism.
• The chroot changes the process's root's directory (the file system's view's restriction), and the pivot_root changes the root's mount (the modern's mechanism, the containers' runtimes' design).
• The containers (the Docker, the Podman, the LXC, the OCI's standards) combine the namespaces, the cgroups, the seccomp's filters, the capabilities' minimization, the LSM's profiles, and the image's layers. The containers are the sandboxing's modern's architecture, and their isolation is the kernel's mechanisms' (the shared's kernel is the VMs' security's difference).
• The browsers' sandboxes (the Chrome's, the Firefox's) apply the multi-process's architecture and the renderer's sandbox (the chroot, the seccomp, the namespaces, the sandbox's user, the capabilities' dropping, the broker's IPC's mediation).
• The systemd's hardening's directives configure the services' sandboxing: the file system's directives (ProtectSystem, ProtectHome, PrivateTmp, the others), the namespaces' directives (PrivateMounts, PrivateNetwork, the others), the capabilities' directives (CapabilityBoundingSet, NoNewPrivileges), the system calls' directives (SystemCallFilter, the others). The systemd-analyze security's command evaluates the service's sandbox's strength.
• The Landlock is the unprivileged's sandboxing's mechanism (the file system's access's restriction without the CAP_SYS_ADMIN's capability), and the bubblewrap and the firejail are the user-space's tools.
• The sandbox's escapes are the kernel's vulnerabilities, the configuration's mistakes, the design's flaws, and the side channels. The sandboxing's design's principles apply the Lesson 12.1's principles: the least privilege, the fail-safe defaults, the complete mediation, the economy of mechanism, the separation of privilege, the least common mechanism, the psychological acceptability, and the open design.

11 References

• Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapters 16 and 17.
• Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, the Security and the Virtualization chapters. Available online at ostep.org.
• Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapters 7 and 9.
• Kerrisk, M. The Linux Programming Interface. No Starch Press, 2010. Chapters 20, 24, 28, 37, and 61.
• Kerrisk, M. The Linux namespaces. The man 7 namespaces page and the LWN's articles.
• Rosen, R. Resource Management: The Linux and the SUSE Approaches. The Novell/SUSE's and the RHEL's resource-management's guides.
• Edge, J., & other LWN's authors. The LWN's series on the seccomp's filters, the Landlock, and the container's security.
• Rice, L. Container Security. O'Reilly, 2020.
• The Open Container Initiative (the OCI). The Runtime's Specification, the Image's Specification, and the Distribution's Specification.
• Linux man-pages: man 7 namespaces, man 2 clone, man 1 unshare, man 1 nsenter, man 2 setns, man 1 ip-netns, man 7 cgroups, man 1 systemd-cgls, man 1 systemd-cgtop, man 1 systemd-run, man 2 seccomp, man 2 chroot, man 2 pivot_root, man 5 systemd.exec, man 5 systemd.resource-control, man 1 systemd-analyze, man 1 firejail, man 1 bubblewrap, man 8 docker, man 1 podman.