Devices and hooks: preserve the actual trust boundary

A character or block device node identifies a device type and major/minor pair. Supplying the node, whether by creation or an appropriate bind mount, makes a name available but does not alone establish that the process may open or use it. Ordinary ownership and mode checks, relevant LSM rules, device policy, and driver-specific checks still participate. A readable directory listing is not an access test. A permission denied response likewise does not uniquely identify which layer rejected the operation.

Linux cgroup v2 device control uses attached cgroup BPF programs rather than the cgroup v1 devices.allow/devices.deny file interface. Decisions distinguish creation with mknod from read and write access to an existing device and inspect type and major/minor identity. A task able to create a node is not thereby guaranteed access through that node. Conversely, a previously supplied descriptor and a driver API may involve different operation boundaries than a new pathname open. Audit the actual setup and use path rather than assuming one flag governs all cases.

OCI v1.3.0 distinguishes createRuntime, createContainer, startContainer, poststart, and poststop hooks, while prestart is deprecated. The phase and namespace are part of the hook contract. For example, createRuntime executes in the runtime namespace, while createContainer executes in the container namespace even though its executable path is resolved in the runtime namespace. The specification explicitly leaves some setup details underspecified at those creation phases, so a hook must not assume every cgroup and LSM operation is already complete.

A hook binary, its arguments, environment, and input state cross a trust boundary. Host-side hooks must be managed as trusted runtime code, not loaded from an arbitrary writable image path because a name looks convenient. Use the runtime's documented ordering and failure handling, bounded execution, and validated inputs. A hook that returns success can still have left an incorrect device or mount configuration, so verify the resulting state. Keep vendor-specific setup narrowly scoped instead of granting the final workload all of the hook's temporary privileges.

List each required device identity and operation, then test the application with its intended UID, groups, capability sets, seccomp profile, cgroup, and LSM label. Read/write permission is not a complete description of every ioctl's security meaning, and raw pointer inspection limitations still apply to seccomp filters. Record compatible driver/runtime versions and distinguish container setup failures from application initialization failures. Removing an unnecessary broad permission should leave a targeted test explaining which required operation remains supported.

The probability lab illustrates only sampled compatibility coverage. Reset, explicitly set p=0.20 and n=5, interpret success as encountering an omitted required device path, predict the zero-success bar, then Play or Step. For a separate comparison Reset and explicitly set p=0.20 and n=10. Independence and the detection probability are stipulated, not measured. The model does not represent major/minor IDs, device BPF, driver ioctls, hooks, namespaces, or host privilege. An operation matrix and actual runtime observations supply that evidence.