问题标签 [seccomp]

我有一个现有程序，我想使用 seccomp (v2) 进行沙箱处理。

我怎样才能找到我需要为程序允许的 seccomp 规则？

我已经尝试添加seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(…), 0)由 打印的所有系统调用strace -xfc a.out，但显然这还不够，因为当我使用 seccomp 运行程序时，我仍然收到“SIGSYS，错误的系统调用”。

我想在不知道 Seccomp 配置文件的情况下获取正在运行的容器的可用系统调用列表。我怎样才能实现它？

我需要将自定义 seccomp 配置文件传递给在 Docker swarm 上运行的容器。它可以很容易地完成，并且可以使用 --security-opt 选项与独立容器一起正常工作。当您尝试将其传递给在 swarm 上运行的容器时，就会出现问题。Docker compose file ver 3 文档明确指出，集群部署忽略了 --security-opt 选项：https ://docs.docker.com/compose/compose-file/#security_opt

在集群上部署时，如何将自定义 seccomp 配置文件传递给容器或服务？有没有其他方法可以改变容器的系统限制？cap_add 和/或 cap_drop 不是一个选项。有任何想法吗？太感谢了！

问题： docker 在哪里存储它的默认 seccomp 配置文件？

似乎这在任何地方都没有记录（至少我找不到它）。我能找到的是 github 上文件的内容：https ://github.com/moby/moby/blob/master/profiles/seccomp/default.json 。

语境：

我目前有两台 docker 主机和一个要运行的容器。该容器在一台主机上工作，但在另一台主机上不工作。经过一些调试和在线搜索后，我发现了如何使 docker 在另一台主机上运行，​​这可以通过添加来实现--security-opt seccomp:unconfined

这解决了我遇到的问题。现在我想知道 docker seccomp 配置文件之间的确切区别，因此我想知道 docker 的 seccomp 配置文件存储在哪里。

操作系统：Ubuntu 服务器 16.04

工作 Docker 主机：Docker version 1.12.3, build 6b644ec

失败的 Docker 主机：Docker version 17.05.0-ce, build 89658be

我正在编写一个用 C++ 编写的开源跨平台应用程序，它针对 x86 CPU 上的 Windows、Mac 和 Linux。应用程序生成需要验证的数据流（整数），我的应用程序将根据验证结果执行操作。有多个验证器，我们称之为“模块”，它们可以相互交换。

任何人都可以编写模块并与其他用户共享，所以我的应用程序必须确保恶意编写的模块不会以任何方式伤害用户（也许除了通过高 CPU 使用率，在这种情况下，我的应用程序应该能够在一段时间后杀死模块时间量 - 这可以通过使用代理过程来完成）。此外，数据流正在以高速率（高达 100kB/s）发送。

幸运的是，这些模块中的代码通常是对流中数据的简单算术运算（通常在恒定时间内处理每个传入的整数），它们不需要进行任何系统调用（甚至不需要堆分配）。

我考虑了以下可能性（所有这些可能性都有一些缺点）：

• 基于内核的沙盒

  • 在 Linux 上，我们可以使用安全计算 ( seccomp )，它可以防止进程进行任何系统调用，除了使用已经打开的文件解压缩器进行读取和写入。模块创建者会将他们的模块编写为单个函数，该函数接受输入和输出文件描述符（使用 C 或 C++ 等语言）并将其编译为共享对象，然后分发该共享对象。

    我的应用程序可能会准备输入和输出文件描述符，然后是fork()它自己或exec()代理进程，并且这个子进程使用dlopen()anddlsym()来获取指向不受信任函数的指针。然后在执行不受信任的功能之前，将启用严格的安全计算模式。

    缺点：dlopen()实际运行共享库中的构造函数存在问题。这也必须进行适当的沙盒处理，我想不出办法。另外，当然，这个东西只能在 Linux 上运行。据我所知，没有办法在 Windows 上禁止 WinNT 系统调用，因此在 Windows 上类似的解决方案不会很安全。

• 应用程序级沙盒

  • [[ 任何形式的应用程序级沙盒意味着我们不能运行任何形式的不受信任的机器代码。不受信任的函数可以覆盖其调用堆栈之外的返回值或数据，从而危及整个应用程序（并有效地获取原始应用程序拥有的任何权限）。]]

  • 使模块使用一种不支持任何系统调用的简单脚本语言——只是纯粹的算术运算，也许还有读取输入流的能力。我的应用程序将包含该语言的解释器。

    缺点：不幸的是我还没有找到这种脚本语言。许多脚本语言具有广泛的功能（例如 Python），而沙箱（例如PyPy 的沙箱）只是过滤 OS 系统调用。我会在我的应用程序中附带大量无用的解释器代码，并且可以说由于解释器中的错误，它比除了简单的计算和控制流指令（基本上是一个不进行任何系统调用的函数）。此外，在 C++（机器代码）和脚本语言之间编组数据通常是一个缓慢的过程。

  • 使用不支持任何系统调用的“安全”编译语言分发模块。我的应用程序将包含该语言的 JIT。
    不需要编组，因为我的应用程序会调用不受信任模块的 JITted 机器代码，因此跨此边界的性能应该很快。由于语言限制和“安全”语言的检查，不受信任的模块现在将无法破坏堆栈、尝试面向返回的编程或执行任何其他恶意操作。WebAssembly 是第一个也是唯一一个想到的语言（如果它可以被称为一种语言）。（据我所知，WebAssembly 似乎为我的用例提供了安全保证，对吧？）

    缺点：WebAssembly 的现有实现似乎都是基于浏览器的，所以我不得不从开源浏览器中窃取一个实现。考虑到我必须将它与所有 JavaScript 和其他浏览器位分离，这看起来确实需要做很多工作。但是，基于 LLVM 的独立 WebAssembly JIT似乎正在开发中。

问题：

在 Windows、Mac 和 Linux 上有效执行不受信任的功能的最佳方法是什么？

现在，我认为脚本语言方式可能是最安全的，并且对于模块编写者来说是最简单的。但是对于更有效的解决方案，WebAssembly 可能更好。我是对的，还是有我没有想到的更好或更简单的解决方案？

（备注：我想这个问题中使用的几对标签以前从未一起见过！）

CentOS Linux 版本 7.5.1804（核心）

配置生产集群，ES拒绝启动：

好的，所以我去检查 seccomp 的存在：

因此，存在 seccomp 的外观和气味。

接下来是什么？

Centos 7.5 上的弹性搜索 6.4.2

我需要关闭 bootstrap.system_call_filter （因为它阻止启动，出于我不明白的原因，在此处概述）

当我添加：system_call_filter=false

对于 jvm.options，elastic 根本没有启动。

这套在哪里？

我可以在集群级别启用 pod 以使用默认的 secomp 和 apparmor 配置文件，还是我需要制作自己的准入控制器以将注释插入对象？

将其留给用户不是一种选择。

我将详细描述我的问题，并请原谅我的不守规矩和粗鲁。

我在 seccomp-BPF 和信号处理方面做了一些实验。一开始我遵循了这个教程。

添加 SIGSYS 信号处理（syscall-reporter.c）后，如果程序执行一些无效的系统调用，我可以在下面得到一些输出：

execve我想知道如果我使用函数或其他方法执行任何其他可执行文件，如何打印系统调用名称。

我尝试过这样的事情：主进程（刚刚命名为 P0 的进程）首先添加 SIGCHLD 信号处理，然后分叉一个子进程（名为 P1）。P1 将添加 seccomp-bpf 规则并对无效的系统调用执行 seccomp 操作SCMP_ACT_TRAP，然后使用该execve函数将 P1 替换为可执行文件（名为 E）。当执行 E 并调用一些无效的系统调用时，P1 将抛出一个 SIGSYS 信号并退出，然后向 P0 发送 SIGHLD 信号。似乎 P0 无法从ucontext_t收到的 SIGHLD 信号中获取无效的系统调用名称。

P1 不能打印系统调用名称本身，因为

在 execve(2) 期间，已处理信号的处置被重置为默认值；

（来自sigaction 手册页）

对不起我的英语不好。

在man 2 seccompSECCOMP_SET_MODE_STRICT部分中，据说：

请注意，虽然调用线程不能再调用 sigprocmask(2)，但它可以使用 sigreturn(2) 来阻塞除 SIGKILL 和 SIGSTOP 之外的所有信号。

我无法弄清楚如何做到这一点。sigreturn是syscall那个

这个 sigreturn() 调用撤消了所有已完成的操作——更改进程的信号掩码、切换信号堆栈（参见 sigaltstack(2)）——以便调用信号处理程序。

进一步来说：

使用之前保存在用户空间堆栈中的信息
sigreturn() 恢复进程的信号掩码、切换堆栈并恢复进程的上下文（处理器标志和寄存器，包括堆栈指针和指令指针），

信息通过以下方式存储：

保存的进程上下文信息放置在 ucontext_t 结构中（请参阅 参考资料）。该结构在信号处理程序中是可见的，作为通过 sigaction(2) 使用 SA_SIGINFO 标志建立的处理程序的第三个参数。

我认为这是不可能的，因为以下两个原因：

1. 由于TERM信号的动作不需要返回到用户空间，所以没有办法dying通过使用atexit或类似的东西来阻止。

   ucontext_t2.虽然可以用man 2 getcontext或man 3 makecontext填写 a ，但这无助于进程阻止信号，因为所有用于安装处理程序和屏蔽信号的系统调用都被禁用（除非sigreturn使用 siganl 掩码东西本身）。