Seccomp user notification moves a policy decision into a privileged broker
A classic seccomp filter makes a fast kernel decision to allow, reject or kill a system call. The SECCOMP_RET_USER_NOTIF action changes that model. The kernel pauses the calling task and sends a notification to a supervising process. The supervisor can inspect the request, answer it, or install a file descriptor in the target process. The filter remains small, while the complex policy moves into user space.
That design can support useful controls. A container runtime might mediate openat, return a pre-opened file, or deny a device operation without giving the workload a broader privilege. It also makes the supervisor part of the security boundary. If an attacker can control the supervisor, forge a notification decision, or influence the path it examines, the policy may be weaker than the filter suggests.
The notification carries a unique identifier and a process ID, with visibility caveats across PID namespaces. The supervisor should validate the identifier before relying on a saved request. The kernel documentation includes SECCOMP_IOCTL_NOTIF_ID_VALID for this state check. A broker that receives a request, spends time resolving a path, and then answers an unrelated or replaced request has created a time-of-check to time-of-use problem.
Path handling deserves particular care. Resolving a pathname in the supervisor and then authorizing the target process to open that pathname again can produce a different object if a directory is renamed or a symbolic link changes. Where supported, the broker should work with file descriptors and the notification file-descriptor operations rather than reconstructing a path and hoping the second lookup matches the first. The kernel's ability to add a file descriptor with SECCOMP_IOCTL_NOTIF_ADDFD is useful precisely because it can make the object being authorized the object the target receives.
The supervisor must also resist recursion. It will itself make system calls, and it may share filters, namespaces or runtime components with the workload. If a broker call triggers another notification, the process can deadlock or loop. Test the broker under the same namespace and privilege configuration as the workload, not only as a standalone service with an unrestricted shell.
Authorization should identify the workload, not just the syscall arguments. A pid and a requested pathname may be insufficient if the peer process can be replaced, if the supervisor cannot see the target's namespace, or if a mount changes beneath both processes. Use stable workload identity, restrict the supervision channel, and make the broker fail closed when the target's trust state cannot be established. Logging every request can also expose sensitive filenames, so retain the minimum decision context and protect the audit stream.
The broker needs a clear policy language. Rules such as “allow writes under /tmp” are difficult to enforce when path resolution, mounts and symlinks are involved. A stronger rule names the owning workload, the operation, the object type, and the expected source. Deny by default. Record why a rule matched. Review broad exceptions as security changes rather than routine troubleshooting.
Seccomp user notification is a useful building block for constrained environments, but it is not a substitute for Linux permissions, namespaces, mandatory access control or a hardened runtime. It shifts the decision to a component that must be more trustworthy than the workload. If that assumption is not tested, the notification path can become a new privilege boundary with more moving parts than the filter it replaced.
Top comments (0)