seccomp 用户态通知：系统调用怎样交给另一个进程处理？

系统调用是应用向内核请求服务的入口，例如打开文件、创建进程或改变网络配置。seccomp 可以用过滤器限制进程允许发起的系统调用。Linux 的 seccomp user-space notification（用户态通知）则允许过滤器把某些系统调用事件交给另一个用户态监督程序处理，监督者检查后再决定如何回应。

它有点像大楼前台接到访客请求后先联系值班人员，而不是让访客直接进入后台区域。应用线程发出系统调用，内核过滤器把事件通知给持有监听器的监督进程；监督进程可以读取请求信息并返回处理结果。它为沙箱、兼容层和受控运行环境提供了在用户态插入决策的能力。

但这里有一个特别重要的安全边界：Linux 手册明确提醒，seccomp 通知机制不应被当作构建安全策略的可靠基础，因为监督者观察与实际系统调用执行之间存在竞态风险。通知中的参数可以帮助监督者理解请求，却不能自动冻结所有相关对象状态。比如监督者检查某个文件描述符或路径之后，应用周围的状态可能变化，导致实际执行对象与监督者当时以为的对象不同。

因此，用户态通知更适合协作式控制、仿真、兼容或可接受竞态的策略补充。若目标是强安全隔离，应优先使用适合的内核强制机制、最小权限、命名空间、文件系统隔离等措施，并把通知监督器视为额外层，而非唯一门禁。过滤器本身有安装时机、线程同步和操作模式等要求，监督者还必须处理超时、恶意输入和崩溃等异常。

系统调用代理看起来像是“把内核功能搬到用户态”，其实不是简单转发。内核负责暂停原任务并传递通知，用户态监督进程需要决定如何安全、正确地回应；它可以拒绝或返回结果，但并非所有操作都能无风险地代替原调用执行。设计上要明确谁拥有文件描述符、路径和权限上下文，以及检查结果与执行动作之间是否可能被攻击者改变。

这项能力很强，也容易被误用。理解它的关键不是“能拦截系统调用”，而是先理解通知机制的竞态限制，再决定它适不适合作为安全边界的一部分。

来源：Linux seccomp_unotify(2) 手册