Docker 的 Seccomp 安全配置文件

安全计算模式 ( seccomp) 是 Linux 内核的一项功能。您可以使用它来限制容器内可用的操作。系统seccomp()调用在调用进程的 seccomp 状态上运行。您可以使用此功能来限制应用程序的访问。

仅当 Docker 已构建seccomp并且内核已配置为CONFIG_SECCOMP启用时，此功能才可用。要检查您的内核是否支持seccomp：

$ grep CONFIG_SECCOMP= /boot/config-$(uname -r)
CONFIG_SECCOMP=y

传递容器的配置文件

默认配置seccomp文件为使用 seccomp 运行容器提供了合理的默认设置，并禁用了 300 多个系统调用中的大约 44 个系统调用。它具有适度的保护性，同时提供广泛的应用兼容性。默认的 Docker 配置文件可以在这里找到。

实际上，配置文件是一个白名单，默认情况下拒绝访问系统调用，然后将特定的系统调用列入白名单。该配置文件的工作原理是定义一个 defaultActionofSCMP_ACT_ERRNO并仅针对特定的系统调用覆盖该操作。的效果SCMP_ACT_ERRNO是导致Permission Denied 错误。接下来，配置文件定义了完全允许的系统调用的特定列表，因为它们action被覆盖为SCMP_ACT_ALLOW.最后，一些特定的规则适用于单个系统调用，例如personality和其他，以允许这些系统调用具有特定参数的变体。

seccomp对于以最小权限运行 Docker 容器很有帮助。不建议更改默认seccomp配置文件。

当您运行容器时，它会使用默认配置文件，除非您使用选项覆盖它--security-opt。例如，以下明确指定了策略：

$ docker run --rm \
             -it \
             --security-opt seccomp=/path/to/seccomp/profile.json \
             hello-world

默认配置文件阻止的重要系统调用

Docker 的默认 seccomp 配置文件是一个白名单，它指定允许的调用。下表列出了因不在允许列表中而被有效阻止的重要（但不是全部）系统调用。该表包含每个系统调用被阻止而不是列入白名单的原因。

系统调用	描述
`acct`	会计系统调用可以让容器禁用自己的资源限制或进程会计。也由门控`CAP_SYS_PACCT`。
`add_key`	防止容器使用未命名空间的内核密钥环。
`bpf`	拒绝将潜在持久的 bpf 程序加载到已由`CAP_SYS_ADMIN`.
`clock_adjtime`	时间/日期没有命名空间。也由门控`CAP_SYS_TIME`。
`clock_settime`	时间/日期没有命名空间。也由门控`CAP_SYS_TIME`。
`clone`	拒绝克隆新的命名空间。也由`CAP_SYS_ADMIN`CLONE_* 标志进行门控，除了`CLONE_NEWUSER`。
`create_module`	拒绝内核模块上的操作和功能。过时的。也由门控`CAP_SYS_MODULE`。
`delete_module`	拒绝内核模块上的操作和功能。也由门控`CAP_SYS_MODULE`。
`finit_module`	拒绝内核模块上的操作和功能。也由门控`CAP_SYS_MODULE`。
`get_kernel_syms`	拒绝检索导出的内核和模块符号。过时的。
`get_mempolicy`	修改内核内存和 NUMA 设置的系统调用。已经被门禁了`CAP_SYS_NICE`。
`init_module`	拒绝内核模块上的操作和功能。也由门控`CAP_SYS_MODULE`。
`ioperm`	防止容器修改内核 I/O 权限级别。已经被门禁了`CAP_SYS_RAWIO`。
`iopl`	防止容器修改内核 I/O 权限级别。已经被门禁了`CAP_SYS_RAWIO`。
`kcmp`	限制过程检查能力，已经被丢弃阻塞了`CAP_SYS_PTRACE`。
`kexec_file_load`	它的姊妹系统调用`kexec_load`做了同样的事情，但参数略有不同。也由门控`CAP_SYS_BOOT`。
`kexec_load`	拒绝加载新内核以供以后执行。也由门控`CAP_SYS_BOOT`。
`keyctl`	防止容器使用未命名空间的内核密钥环。
`lookup_dcookie`	跟踪/分析系统调用，这可能会泄露主机上的大量信息。也由门控`CAP_SYS_ADMIN`。
`mbind`	修改内核内存和 NUMA 设置的系统调用。已经被门禁了`CAP_SYS_NICE`。
`mount`	拒绝安装，已由门控`CAP_SYS_ADMIN`。
`move_pages`	修改内核内存和 NUMA 设置的系统调用。
`nfsservctl`	拒绝与内核 nfs 守护进程交互。自 Linux 3.1 起已过时。
`open_by_handle_at`	旧容器破裂的原因。也由门控`CAP_DAC_READ_SEARCH`。
`perf_event_open`	跟踪/分析系统调用，这可能会泄露主机上的大量信息。
`personality`	防止容器启用 BSD 模拟。本质上并不危险，但测试不充分，可能存在很多内核漏洞。
`pivot_root`	Deny `pivot_root`，应该是特权操作。
`process_vm_readv`	限制过程检查能力，已经被丢弃阻塞了`CAP_SYS_PTRACE`。
`process_vm_writev`	限制过程检查能力，已经被丢弃阻塞了`CAP_SYS_PTRACE`。
`ptrace`	跟踪/分析系统调用。在 4.8 之前的 Linux 内核版本中被阻止，以避免 seccomp 绕过。跟踪/分析任意进程已经被 drop 阻止`CAP_SYS_PTRACE`，因为它可能会泄漏主机上的大量信息。
`query_module`	拒绝内核模块上的操作和功能。过时的。
`quotactl`	配额系统调用可以让容器禁用它们自己的资源限制或进程记账。也由门控`CAP_SYS_ADMIN`。
`reboot`	不要让容器重新启动主机。也由门控`CAP_SYS_BOOT`。
`request_key`	防止容器使用未命名空间的内核密钥环。
`set_mempolicy`	修改内核内存和 NUMA 设置的系统调用。已经被门禁了`CAP_SYS_NICE`。
`setns`	拒绝将线程与命名空间关联。也由门控`CAP_SYS_ADMIN`。
`settimeofday`	时间/日期没有命名空间。也由门控`CAP_SYS_TIME`。
`stime`	时间/日期没有命名空间。也由门控`CAP_SYS_TIME`。
`swapon`	拒绝开始/停止交换到文件/设备。也由门控`CAP_SYS_ADMIN`。
`swapoff`	拒绝开始/停止交换到文件/设备。也由门控`CAP_SYS_ADMIN`。
`sysfs`	过时的系统调用。
`_sysctl`	已过时，由 /proc/sys 取代。
`umount`	应该是特权操作。也由门控`CAP_SYS_ADMIN`。
`umount2`	应该是特权操作。也由门控`CAP_SYS_ADMIN`。
`unshare`	拒绝克隆进程的新命名空间。也由门控`CAP_SYS_ADMIN`，但除外`unshare --user`。
`uselib`	与共享库相关的较旧系统调用，已长期未使用。
`userfaultfd`	用户空间页面错误处理，主要用于进程迁移。
`ustat`	过时的系统调用。
`vm86`	在内核 x86 实模式虚拟机中。也由门控`CAP_SYS_ADMIN`。
`vm86old`	在内核 x86 实模式虚拟机中。也由门控`CAP_SYS_ADMIN`。

在没有默认 seccomp 配置文件的情况下运行

您可以unconfined在没有默认 seccomp 配置文件的情况下运行容器。

$ docker run --rm -it --security-opt seccomp=unconfined debian:jessie \
    unshare --map-root-user --user sh -c whoami