Default Policy and Baseline Paths
This reference describes the restrictive policy OpenShell uses when a sandbox has no other policy, and the filesystem paths that OpenShell adds to sandbox policies at runtime.
When the Default Applies
OpenShell uses the restrictive default only when no global policy is active, the
sandbox has no saved policy, and its image contains no policy. Creating a
sandbox without --policy does not by itself mean the default is active,
because the image or OPENSHELL_SANDBOX_POLICY can supply one. An invalid image
policy keeps the workload from starting until you repair it. It does not select
the default. Refer to Where the Active Policy Comes
From for
the complete selection order.
Default Filesystem Access
The default policy includes the sandbox working directory as read-write and grants read-only access to these paths:
/bin/usr/lib/proc/dev/urandom/etc/var/log
It grants read-write access to /tmp and /dev/null. Landlock user-policy
compatibility is best_effort.
Default Network Access
The default policy defines no network rules or middleware, so all outbound network access is denied. Attached providers can still add network rules to the effective policy. To see them, compare the base and effective policies, as described in Inspect the Selected Policy.
Default Process Identity
The default policy leaves process identity to the compute driver. Docker and
Podman run the workload as the image’s USER when it names a non-root user, and
as UID and GID 1000 when the image declares no user. They reject an image whose
user is root unless the policy you pass when you create the sandbox sets a
non-root run_as_user. Kubernetes and VM sandboxes run as the identity
configured for their driver.
Baseline Filesystem Paths
Sandbox processes that use the network need system paths for shared libraries, DNS resolution, and CA certificates. When the effective policy contains at least one network rule, including a provider-contributed rule, OpenShell adds these baseline paths to the sandbox’s filesystem policy at startup:
OpenShell adds a baseline path only when it is available and your policy does
not already list it, so list the paths your workload needs, such as /app, in
your policy. OpenShell never changes the access of a path you list, so a
baseline read-write path that you list as read-only stays read-only. If the
policy has no filesystem_policy section, OpenShell creates one with
include_workdir: true.
The sandbox saves the enriched filesystem policy as a new revision, so the
added paths appear in openshell policy get --base. OpenShell can reject a
replacement policy that removes filesystem paths, so keep the added paths when
you replace the complete policy.
The runtime also grants the workload read-only access to the sandbox’s TLS CA
certificates under /run/openshell-supervisor-ca. This grant is not saved in
the sandbox’s policy.
GPU Sandboxes
On the Docker and VM compute drivers, a sandbox that requests a GPU receives additional paths when the corresponding GPU device is present:
CUDA writes thread names under /proc during initialization, so GPU enrichment
moves /proc from read-only to read-write. OpenShell adds each path only when
it exists in the workload. These paths apply at runtime and are not saved in
the sandbox’s policy.
Protected Paths
On Docker, Podman, Kubernetes, and VM sandboxes, a mandatory Landlock baseline
protects the private /.openshell directory and requires Landlock ABI v3. Your
filesystem policy is applied on top of that baseline and can narrow access, but
it cannot expose /.openshell. The best_effort compatibility setting does not
disable this protection or allow a kernel without ABI v3.
Inspect the Selected Policy
To see which policy a sandbox uses, print its base and effective policies. While a global policy is active, both commands show the global policy:
Neither view includes the paths that OpenShell grants only at runtime, such as
the CA certificate and GPU paths. To confirm what a running sandbox enforces,
check the revision status with openshell policy list <sandbox> and test
requests.