深入解析Kubernetes allowPrivilegeEscalation安全机制

本文详细解析Kubernetes中allowPrivilegeEscalation安全选项的工作原理，通过实际代码演示其如何防止容器内权限提升攻击，并澄清常见误解，帮助开发者正确配置容器安全策略。

停止担心’allowPrivilegeEscalation'

Kubernetes安全上下文允许您在Pod或容器级别配置安全选项。虽然某些参数很好理解，但其他参数可能更加晦涩和令人困惑。在本文中，我们将揭穿关于allowPrivilegeEscalation选项的迷思。

TL;DR—allowPrivilegeEscalation是一个安全加固选项，不多也不少。如果您能够将其关闭作为快速胜利，请务必这样做！否则，它本身不会让您被黑客攻击。如果您没有明确禁用它，您可能没问题。

什么是’allowPrivilegeEscalation’？

询问任何安全工程师是否应该允许您的应用程序"提升权限"，您可能会收到茫然的目光、困惑的表情，甚至可能有人质疑您的理智。

“提升他们的权限”？

幸运的是，这里存在误解。当您问：

如果我没有明确将"allowPrivilegeEscalation"标志设置为false，有关系吗？

…您的安全工程师听到的是：

如果我不安全的Java应用程序可以逃逸其容器并在我们的集群中像1999年一样跳舞，可以吗？

好消息！你们至少有一个共同点：你们都不知道allowPrivilegeEscalation标志的含义——老实说，谁能责怪你们呢？

关于’allowPrivilegeEscalation’的常见误解

让我们开门见山：虽然关闭allowPrivilegeEscalation可能很有价值，但它是一个安全加固设置，您可以利用它来增加容器化环境的安全性。

特别是，如果您将allowPrivilegeEscalation保留为true（其默认值）：

  • 它不会神奇地允许容器中的非特权进程将其权限提升到root
  • 它不会允许在容器内运行的进程逃逸容器
  • 它不会允许Pod在集群内执行任何类型的权限提升

“但是Christophe，“我听到您问，“那它到底做什么呢？“让我们首先看看它确实可以防止的攻击类型示例。然后，我们将深入探讨容器运行时如何实现它。

‘allowPrivilegeEscalation’实战

让我们重现一个场景，其中漏洞允许非特权进程在容器内将其权限提升到root。这可能发生在内核级漏洞中，如DirtyCow、DirtyPipe或OverlayFS中的CVE-2023-0386。我们还可以测试一个更简单（但同样现实）的方法：滥用具有setuid位设置的root拥有的二进制文件。首先，让我们重现这个场景。然后，我们将看到关闭allowPrivilegeEscalation如何防止成功利用。

我们将使用以下程序，它使用setreuid（如"设置真实和有效用户id”）和setregid来有效地将权限提升到root。根据设计，这仅在二进制文件由root拥有且具有setuid位设置时才有效：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

int main(void) {
    // 提升到root
    setreuid(0, 0); 
    setregid(0, 0);

    // 生成shell
    char* const argv[] = {"/bin/bash", NULL};
    char* const environ[] = {NULL};
    execve("/bin/bash", argv, environ);
}

1
2
3

gcc escalate.c -Wall -o /tmp/escalate
sudo chown root:root /tmp/escalate
sudo chmod +s /tmp/escalate

我们现在可以使用非特权用户来确认这个易受攻击的程序允许我们将权限提升到root。

以下Dockerfile模拟了一个Alpine容器镜像，以非特权用户身份运行应用程序，其中包含易受攻击的二进制文件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

FROM alpine:3.20 AS builder
WORKDIR /build
RUN cat > escalate.c <<EOF
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <errno.h>

int main(void) {
    // 提升到root
    setreuid(0, 0); 
    setregid(0, 0);

    // 生成shell
    char* const argv[] = {"/bin/bash", NULL};
    char* const environ[] = {"PATH=/bin:/sbin:/usr/bin:/usr/sbin", NULL};
    if (-1 == execve("/bin/bash", argv, environ)) {
        printf("Unable to execve /bin/bash, errno %d\n", errno);
    }
}
EOF
RUN cat /build/escalate.c
RUN apk add --no-cache gcc musl-dev
RUN gcc escalate.c -Wall -o escalate

FROM alpine:3.20 AS runner
WORKDIR /app
COPY --from=builder /build/escalate ./escalate
RUN chown root:root ./escalate && chmod +s ./escalate
RUN adduser app-user --uid 1000 --system --disabled-password --no-create-home
RUN apk add bash
USER app-user
ENTRYPOINT ["sh", "-c", "echo Application running && sleep infinity"]

让我们构建它并在Kubernetes集群中运行它，明确打开allowPrivilegeEscalation（尽管这是默认值）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 构建镜像
docker build . -t my-app:0.1

# 创建kind集群并在其上运行镜像
kind create cluster
kind load docker-image my-app:0.1

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 1000
  containers:
  - name: my-app
    image: my-app:0.1
    securityContext:
      allowPrivilegeEscalation: true
EOF

正如预期的那样，我们能够利用漏洞将权限提升到root。

但是，如果我们以allowPrivilegeEscalation设置为false启动我们的pod，我们会得到：

发生了什么？对setreuid和setregid的调用失败了。如果我们向我们的"利用"代码添加错误处理，错误会变得更加明确：

1
2
3
4
5
6
7

// 提升到root
if (setreuid(0, 0) != 0) {
    printf("setreuid(0, 0) failed: %s\n", strerror(errno));
}
if (setregid(0, 0) != 0) {
    printf("setregid(0, 0) failed: %s\n", strerror(errno));
}

‘allowPrivilegeEscalation’如何工作

根据Kubernetes文档：

AllowPrivilegeEscalation控制进程是否可以获得比其父进程更多的权限。此布尔值直接控制是否将在容器进程上设置no_new_privs标志。

no_new_privs标志是在3.5（2012年发布）中引入的内核功能。启用后，它确保没有子进程可以获得比其父进程更多的权限。

我们可以通过手动设置no_new_privs来确认此行为，然后再尝试执行我们的权限提升，使用一个小型实用程序：

  • 使用prctl系统调用设置no_new_privs
  • 创建一个新的sh进程，该进程将"安全"地防止权限提升漏洞

我们需要第二步，因为新设置的标志不会追溯应用于我们已经在运行的shell进程。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <errno.h>
#include <sys/prctl.h>

int main(void) {
    // 设置no_new_privs
    if (-1 == prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
        printf("Could not set prctl: %s\n", strerror(errno));
    }

    // 生成shell
    char* const argv[] = {"/bin/sh", NULL};
    char* const environ[] = {"PATH=/bin:/sbin:/usr/bin:/usr/sbin", NULL};
    if (-1 == execve("/bin/sh", argv, environ)) {
        printf("Unable to execve /bin/sh, errno %d\n", errno);
    }
}

当我们编译并运行此实用程序时，我们看到它正在我们的新shell进程中正确设置no_new_privs标志，正如我们可以通过读取/proc/self/status看到的那样。

如果我们现在再次尝试我们的权限提升，请注意它现在被阻止了——就像我们将allowPrivilegeEscalation设置为false时一样。

这个小舞蹈正是容器运行时在创建新的容器化进程时所做的事情。例如，这是来自runc的容器初始化代码，它被大多数容器运行时使用，如containerd、CRI-O和Docker：

1
2
3
4
5
6

// 如果NoNewPrivileges为true（由allowPrivilegeEscalation直接控制），则调用prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) [编者注]
if l.config.NoNewPrivileges {
    if err := unix.Prctl(unix.PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0); err != nil {
        return &os.SyscallError{Syscall: "prctl(SET_NO_NEW_PRIVS)", Err: err}
    }
}

您可以看到它正在执行与我们完全相同的过程：

  • 检查NoNewPrivileges是否为true（这由我们的Kubernetes安全上下文allowPrivilegeEscalation字段直接控制）
  • 如果是这种情况，在创建容器进程之前打开no_new_privs

那么问题是什么？

安全——就像大多数试图处理系统性故障的学科一样，是关于构建不同层以确保单个缺陷不会变成数据泄露。

在这种情况下：是的，明确关闭allowPrivilegeEscalation是一个合法的良好安全加固实践。关闭它可以大大增加攻击者入侵非特权应用程序无法将其权限提升到容器内的root的信心，从而降低利用需要root权限的进一步漏洞的风险。

如果您没有在工作负载上关闭它，是否很糟糕？可能不是。将其视为您尚未启用的（又一个）加固机制。这不是会让您被黑客攻击的原因。除非您是一个成熟的安全团队，否则您可能最好首先专注于容器安全路线图中更高价值的项目（请参阅我的KubeCon EU 2024演讲和帖子，了解一些关于从哪里开始的威胁知情想法）。

也就是说，这不是您应该忽略的设置；确保它是您容器安全路线图的一部分。

常见问题解答

‘allowPrivilegeEscalation’的默认值是什么？

默认值为true。请参阅相关代码和相关问题以在文档中使其更清晰。

如果我的工作负载在容器内以root身份运行，关闭’allowPrivilegeEscalation’有什么意义吗？

不，完全没有意义。如果您的工作负载以root身份运行，它们在容器内无法实现进一步的权限提升。

如果我的工作负载以"privileged"运行或具有CAP_SYS_ADMIN能力，关闭’allowPrivilegeEscalation’有什么意义吗？

不，没有意义。事实上，您甚至不能这样做——API服务器将拒绝您的请求（请参阅相关验证代码）：

1

The Pod "my-app" is invalid: spec.containers[0].securityContext: Invalid value: cannot set `allowPrivilegeEscalation` to false and `privileged` to true

关闭’allowPrivilegeEscalation’是否防止容器内的所有类型的权限提升？

不。例如，如果攻击者利用允许他们提升权限的内核缺陷，它将无济于事。也就是说，它应该阻止所有通过利用setuid/setgid工作的权限提升。

‘allowPrivilegeEscalation’和’privileged’之间有什么联系吗？

没有。关闭allowPrivilegeEscalation是一个安全加固机制。如果您将其保留为默认值，容器内的进程仍然不能轻易提升其权限，也不能逃逸容器。

启用privileged运行工作负载使它们运行起来就像它们是主机上的直接进程一样，使得容器逃逸在设计上变得微不足道。

如果攻击者设法在容器内提升到root，这不是世界末日吗？

又一个误解，有时由推动安全行业的FUD愉快地传播。在容器内以root身份运行的进程不能轻易逃逸到容器外。它将不得不利用另一个漏洞或错误配置。

结论

希望本文提供了关于’allowPrivilegeEscalation’是什么、不是什么以及使用它的明显好处的更深入概述。当我第一次发现它时，我自己也很困惑，而且它似乎是许多人困惑的根源，也许是由于其不幸的命名。

感谢阅读，让我们在Hacker News、Twitter或Mastodon上继续讨论！

感谢我的同事Rory McCune审阅了这篇文章。

comments powered by Disqus
© 2020 - 2025 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次