runc容器运行时中SCMP_ACT_NOTIFY规则导致挂起问题分析

在runc容器运行时v1.2版本中，当使用SCMP_ACT_NOTIFY动作对fcntl系统调用设置seccomp规则时，会出现容器启动挂起的问题。这个问题主要影响依赖于seccomp通知机制的容器网络加速工具如bypass4netns的正常工作。

问题现象

当用户尝试在runc v1.2环境下运行带有特定seccomp配置的容器时，容器启动过程会无响应地挂起。具体表现为：

1. 容器启动命令如runc run会卡住不继续执行
2. seccomp监听代理(如bypass4netns)无法收到任何通知连接
3. 该问题在runc v1.1.13版本中不存在，属于v1.2版本引入的回归性问题

技术背景

seccomp是Linux内核提供的一种安全机制，允许进程限制自己能执行的系统调用。SCMP_ACT_NOTIFY是其中一种特殊动作，它不会直接拒绝系统调用，而是将决定权交给用户空间的监听程序。

在容器场景中，这种机制常被用于实现动态安全策略或网络加速等功能。bypass4netns就是一个利用此机制实现容器网络性能优化的工具。

问题根源

经过分析，这个问题源于runc v1.2版本中引入的一个改动，该改动调整了seccomp通知文件描述符的处理方式。具体来说：

1. runc内部在建立seccomp通知机制的过程中，会使用fcntl系统调用来操作文件描述符
2. 当seccomp策略将fcntl设置为SCMP_ACT_NOTIFY时，这些内部操作会被拦截并转发给监听代理
3. 但由于通知通道尚未完全建立，导致系统调用无法得到响应，形成死锁状态

解决方案

目前有两种可行的解决方向：

1. runc层面：调整内部实现，避免在关键路径上依赖可能被拦截的系统调用。这需要确保seccomp通知机制建立完成前不使用会被拦截的系统调用。

2. 监听代理层面：增强代理程序的健壮性，可以采取以下策略：

   • 对未知文件描述符的操作一律放行
   • 在容器首次exec操作前放宽策略限制
   • 正确处理系统调用拦截失败的情况，避免无限等待

临时规避方法

对于急需解决问题的用户，可以采用以下临时方案：

1. 避免对fcntl系统调用使用SCMP_ACT_NOTIFY动作
2. 改用其他系统调用(如connect)作为通知触发点
3. 暂时回退到runc v1.1.13版本

总结

这个问题展示了容器安全机制与运行时内部实现的微妙交互关系。在使用高级安全特性时，开发者需要考虑运行时自身的实现细节。未来版本的runc可能会提供更明确的指导，说明哪些系统调用可以在seccomp策略中安全地使用NOTIFY动作。

对于安全敏感的应用场景，建议在升级前充分测试seccomp策略与新版本运行时的兼容性，并关注相关项目的更新公告。