在本文中，我们提出了一种在利用后保护您的容器应用程序的新颖方法。这种额外的保护称为 Seccomp-BPF。

许多企业正在采用容器作为用于管理和运行其应用程序的基础技术。如果您经常使用容器，很容易理解原因：它们实现了全新级别的可移植性和可扩展性。但是，与任何其他新技术一样，容器的采用也意味着开发应用程序的新方法。

根据容器的配置，被利用的应用程序最终会导致运行容器的主机受到危害。还有其他一些影响需要考虑，例如作为环境变量存储在容器中的潜在秘密以及它们可以访问的内容。如果您想详细了解 Docker 容器安全最佳实践，GitGuardian 提供了一份有用的备忘单。

成熟的软件开发生命周期已经包括漏洞扫描和软件组成分析等安全流程，但还需要更多。大多数可用的应用程序安全技术的存在是为了防止应用程序受到攻击，但没有多少会包含成功利用应用程序时可能造成的损害。为了解决这个问题，我一直在研究一种新颖的方法来保护您的容器应用程序后利用。在这篇文章中，我将分享它是什么以及如何将它无缝集成到您已经建立的软件开发流程中。我所指的附加保护称为 Seccomp-BPF，在深入了解如何使用它之前，我需要解释一下它是什么。

背景

我们在计算机上运行的程序严重依赖底层操作系统来做任何事情。打开文件和产生新进程之类的任务在现代编程语言中被抽象出来，但在底层，代码正在发出称为系统调用（或系统调用）的内核请求。系统调用对于程序运行有多重要？嗯，Linux 内核中大约有 400 个系统调用可用，甚至还有一个基本的“Hello, World!”。用 C 语言编写的程序有 2 个：写入和退出。

在所谓的“用户空间”中运行的代码在不经过内核的情况下无法执行任何操作。最终，一些聪明的 Linux 内核开发人员决定利用这一事实来创建强大的安全功能。2012 年 7 月，Linux 版本 3.5 发布，增加了对称为 Seccomp-BPF 的支持。

Seccomp-BPF 是一个 Linux 内核功能，它允许您通过创建一个特殊的过滤器来限制进程可以进行的系统调用。

理论上，您可以创建一个 Seccomp-BPF 过滤器，它只允许一个进程进行它需要运行的确切系统调用，仅此而已。这在应用程序被意外利用以允许对手产生额外进程的情况下很有用。如果 Seccomp 不允许该进程进行新的系统调用，它很有可能会阻止攻击者。

Seccomp 非常酷，它甚至可以集成到容器运行时和 Docker 和 Kubernetes 等编排工具中。它引出了一个问题：“为什么 Seccomp 没有被广泛使用？” 我认为答案是没有足够的资源来弥合像 Seccomp 这样的低级内核功能和现代软件开发流程之间的差距。并不是每个组织都有一个对系统调用非常了解的低级代码开发人员。还需要确定程序需要哪些系统调用并使用您在代码中实现的每个新功能进行更新。

我在考虑如何解决这个问题，我想到了一个想法：“如果我们记录程序在运行时发出的系统调用会怎样？” 我正在告诉我的一位同事我的想法，第二天他给我发了一个链接，指向他在 GitHub 上找到的一个工具。事实证明，Red Hat 的一些人已经制作了一个名为的工具oci-seccomp-bpf-hook，它完全符合我的要求！

创建 Seccomp-BPF 过滤器

该工具oci-seccomp-bpf-hook适用于 Linux 容器。OCI 代表“Open Container Initiative”，它是一组容器运行时标准，定义了它们应该能够提供哪些类型的接口。符合 OCI 的容器运行时（如 Docker）提供了一种称为“挂钩”的机制，允许您在容器启动之前和容器被拆除之后运行代码。与其解释 Red Hat 的工具如何使用这些钩子，我认为做一个演示会更清楚。

Red Hatoci-seccomp-bpf-hook为与他们的容器运行时 podman 一起使用而开发。Podman 在很大程度上与 Docker 向后兼容，因此如果您使用过 Docker，我的示例中的语法看起来很熟悉。此外，OCI 挂钩目前仅在 Red-Hat 相关的 DNF 存储库中可用，除非您从源代码安装它。为了让这个演示变得不那么复杂，我只使用了一个 Fedora 服务器（如果你没有 Fedora 环境，我建议在 Virtualbox 或 VMware 之类的东西上运行一个 Fedora 虚拟机）。

要开始使用，您需要做的第一件事oci-seccomp-bpf-hook是确保将它与 podman 一起安装。为此，我们可以运行以下命令：

sudo dnf install podman oci-seccomp-bpf-hook

现在我们有了 podman 和 OCI 钩子，我们终于可以深入研究如何生成 Seccomp-BPF 过滤器了。从自述文件中，语法是：

sudo podman run --annotation io.containers.trace-syscall="if:[absolute path to the input file];of:[absolute path to the output file]" IMAGE COMMAND

让我们ls在基本容器中运行命令并将输出通过管道传输到/dev/null. 当我们这样做时，我们将记录该ls命令发出的系统调用并将它们保存到/tmp/ls.json.

sudo podman run --annotation io.containers.trace-syscall=of:/tmp/ls.json fedora:35 ls / > /dev/null

由于我们将ls命令的输出通过管道传输到/dev/null，因此终端中应该没有输出。但是，在命令完成后，我们可以查看保存系统调用的文件。在那里我们看到该命令确实有效，并且系统调用被捕获：

cat /tmp/ls.json{"defaultAction":"SCMP_ACT_ERRNO","architectures":["SCMP_ARCH_X86_64"],"syscalls":[{"names":["access","arch_prctl","brk","capset","chdir","close","close_range","dup2","execve","exit_group","fchdir","fchown","fstatfs","getdents64","getegid","geteuid","getgid","getrandom","getuid","ioctl","lseek","mmap","mount","mprotect","munmap","newfstatat","openat","openat2","pivot_root","prctl","pread64","prlimit64","pselect6","read","rt_sigaction","rt_sigprocmask","seccomp","set_robust_list","set_tid_address","sethostname","setresgid","setresuid","setsid","statfs","statx","umask","umount2","write"],"action":"SCMP_ACT_ALLOW","args":[],"comment":"","includes":{},"excludes":{}}]}

这个文件是我们的 Seccomp 过滤器，我们现在可以将它与任何支持它的容器运行时一起使用。让我们尝试将过滤器与ls我们刚刚运行的相同容器化命令一起使用：

sudo podman run --security-opt seccomp=/tmp/ls.json fedora ls / > /dev/null

没有输出也没有任何错误，表明该命令能够在应用了 Seccomp 过滤器的情况下成功运行。有趣的来了。我们将向容器添加一些在记录系统调用时不存在的功能，以制作我们的 Seccomp 过滤器。我们要做的就是将-l标志添加到我们的ls命令中。

sudo podman run --security-opt seccomp=/tmp/ls.json fedora ls -l / > /dev/nullls: /: Operation not permittedls: /proc: Operation not permittedls: /root: Operation not permitted…

如您所见，我们现在收到一堆错误，告诉我们无法执行命令尝试执行的某些操作。在-l我们的命令中添加标志为ls进程添加了一些新的系统调用，这些系统调用不在我们的 Seccomp 过滤器的允许列表中。如果我们使用该命令生成一个新的 Seccomp 过滤器ls -l，我们可以看到新过滤器有效，因为它现在具有所有必需的系统调用。

sudo podman run --annotation io.containers.trace-syscall=of:/tmp/lsl.json fedora ls -l / > /dev/nullsudo podman run --security-opt seccomp=/tmp/lsl.json fedora ls -l / > /dev/null

如您所见，将 Seccomp 过滤器应用于您的容器极大地限制了它的功能。在攻击者可以利用您的应用程序的情况下，它可能会阻止他们造成损害，甚至完全阻止利用。

通过使用 Red Hat 的 OCI 挂钩，您不再需要深入了解 Linux 内核的系统调用来创建 Seccomp 过滤器。您可以轻松地创建一个特定于应用程序的过滤器，该过滤器不允许您的容器做任何超出它需要做的事情。这是弥合内核特性和高级软件开发之间差距的一大步。

结论

尽管如此，oci-seccomp-bpf-hook该工具本身并不能完全达到我将 Seccomp 集成到成熟的软件工程工作流程中的期望。运行该工具仍然存在开销，作为软件开发人员，您不希望每次更新应用程序都花时间手动更新 Seccomp 过滤器。为了弥合最后的差距并尽可能轻松地在企业应用程序中使用 Seccomp，我们需要找到一种方法来自动生成 Seccomp-BPF 过滤器。幸运的是，当我们看到现代软件开发是如何发生的时，已经有一个完美的地方可以实现这种自动化：在 持续集成 (CI)期间。

CI 工作流已经是成熟软件开发生命周期中成熟的一部分。对于那些不熟悉 CI 的人，它使您能够在每次将代码提交到 git 存储库时执行自动化单元测试和代码安全扫描等操作。那里有很多 CI 工具，因此它是为您的容器化应用程序自动生成 Seccomp 过滤器的理想场所。

这篇文章的时间已经不多了，所以我将在另一篇文章中展示如何创建一个 CI 工作流程，每次更新代码时都会生成一个 Seccomp 过滤器。然后，您最终将有能力利用 Seccomp 的系统调用限制并保护您的应用程序！