Summary
Bind Smart Policy authorization to a process instance instead of only a PID.
Rationale
SmartPolicyInterface::request_process_access checks that /proc/<pid> exists and then inserts a PID-only entry into the eBPF policy maps. The process can exit between the existence check and the insertion. If the PID is later reused, a stale policy entry can affect the new process.
Affected areas
crates/cardwire-daemon/src/interface/smart.rs
- Smart Policy eBPF maps and their kernel enforcement logic
Required changes
- Capture a kernel-verifiable process-instance identity when a Smart Policy entry is created. A process start-time identity is one possible mechanism.
- Store this identity with the Smart Policy map entry.
- Validate the stored identity against the current process identity during kernel enforcement.
- Ignore or remove policy entries that do not match the current process instance.
- Preserve the intended behavior for
Allow_dGPU, Force_dGPU, and GPU-specific policies.
Acceptance criteria
- A policy created for a process does not apply to a different process that later reuses the same PID.
- Kernel enforcement verifies process-instance identity before it applies a Smart Policy entry.
- The implementation includes tests or another documented validation method for PID reuse or stale-entry handling.
Backlinks
Requested by: @luytan
Summary
Bind Smart Policy authorization to a process instance instead of only a PID.
Rationale
SmartPolicyInterface::request_process_accesschecks that/proc/<pid>exists and then inserts a PID-only entry into the eBPF policy maps. The process can exit between the existence check and the insertion. If the PID is later reused, a stale policy entry can affect the new process.Affected areas
crates/cardwire-daemon/src/interface/smart.rsRequired changes
Allow_dGPU,Force_dGPU, and GPU-specific policies.Acceptance criteria
Backlinks
Requested by: @luytan