Sandbox and threat model
cpak starts applications as the current user. The sandbox exposes resources declared by the package and accepted by the user.
Namespace boundary
The runtime uses Linux namespaces for users, mounts, processes, IPC, hostname, cgroups, and networking. The process sees the assembled package root. The package PID 1 owns child cleanup and instance lifetime.
Without network, the private network namespace has no route outside the package. With network, slirp4netns adds internet and LAN access while host loopback stays blocked. cpak refreshes only that userspace helper when the host resolver changes, so a running container survives a Wi-Fi or VPN switch. hostNetwork is the separate explicit permission that shares the host network namespace and localhost.
Nested user namespaces and their mount setup are blocked by default. A package can request userNamespaces for applications such as browsers, Steam, and bubblewrap-based runtimes that create another sandbox inside cpak.
Filesystem boundary
Only the package root, runtime mounts, and declared host filesystem paths are present. Each host path has a read-only or read-write mode. Landlock narrows path access after mount setup when supported by the current kernel.
Landlock adds path restrictions after mount isolation. The kernel does not allow a Landlock-confined process to change filesystem topology, so cpak does not apply Landlock when the package explicitly grants userNamespaces. That permission keeps mount namespace isolation and seccomp, but removes Landlock's second path barrier so the nested sandbox can mount its own filesystems. cpak doctor reports whether the host can apply Landlock to ordinary launches.
System call boundary
cpak applies no_new_privs before the application starts and uses seccomp to block disallowed system calls. A package cannot gain privileges through a setuid executable after this point.
The policy includes the calls required by supported desktop applications and the cpak runtime. Test a new application class against the policy before changing the global filter.
Resource controls
Memory, CPU, and process limits use delegated cgroup v2 controllers. A launch with an unavailable requested limit fails with a specific diagnostic.
The runtime uses the service manager available in the user session. Kernel features and session resources determine host compatibility.
Host communication
Direct sockets and devices are opt-in manifest fields. Narrow system operations use brokers:
- the system broker accepts only built-in action types
- local peer validation ties requests to the running package instance
- compatibility commands are parsed before the broker request is created
- streamed actions preserve output channels, exit status, and cancellation
Every compatibility shim maps to a typed request and its effective package permission.
Native file chooser requests use a separate file grant path. cpak receives the selected object on the host and passes an open descriptor to the application mount namespace. A package without the session-bus permission receives a restricted adapter that handles the chooser without exposing other desktop services. See File chooser access.
User overrides
The manifest defines package defaults. Users can remove access or add a local grant. Updates compare the effective old and new permissions and ask before accepting additions.
cpak update --non-interactive rejects updates that require new permissions. This is the recommended mode for unattended systems.
Limits of the boundary
A package with read-write home access can modify user files. A package with broad session bus rules can call the services allowed by those rules. Full devices, host networking, process sharing, host root mounts, and root inside the environment all expand the trusted surface.
Review the manifest before running an untrusted package. The Store highlights high-risk permissions. The manifest and local override define the authoritative policy.
The boundary above says what a running application may reach. It says nothing about whether the application on disk is still the one that was installed, which is a separate question with a separate answer: see Verified launch.
