The study examined the effectiveness of security restrictions within AI agent sandboxes, specifically comparing Linux kernel mechanisms with the gVisor runtime. Tests were conducted on a host running Linux 6.8.0-138-generic and Ubuntu 22.04, using gVisor releases 20260817.0 and 20260831.0.
Experiments with Landlock showed that all three system calls returned ENOSYS in both gVisor releases, indicating the feature was unavailable. While the host returned ABI 4, gVisor failed to implement the interface, meaning security policies relying on Landlock would not be enforced in these environments.
Testing of CGROUP_DEVICE BPF programs revealed that while gVisor successfully accepted the loading and attachment of filters, the restrictions had no actual effect on device access. Files like /dev/null remained accessible even after the filter was applied, confirming that successful configuration does not guarantee enforcement.
A classic BPF socket filter test showed that while Linux correctly dropped packets after filter attachment, gVisor continued to receive data despite returning a successful status for the setsockopt call. This discrepancy highlights that configuration success does not equate to active restriction.
The author proposes a three-step verification process for security wrappers: confirming the action is possible before restriction, verifying the configuration is accepted, and testing that the forbidden action is blocked while permitted actions remain functional. This must be performed within the target environment.
