停止担忧"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

以下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

但是，如果我们将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来确认此行为，然后再尝试执行权限提升，使用一个小型实用程序：

 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);
    }
}

这个小小的过程正是容器运行时在创建新的容器化进程时所做的事情。例如，这是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权限的进一步漏洞的风险。

如果您没有在工作负载上关闭它，是否很糟糕？可能不是。将其视为您尚未启用的（又一个）加固机制。这不是会让您被黑客攻击的原因。除非您是一个成熟的安全团队，否则您最好首先专注于容器安全路线图中更高价值的项目。

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

常见问题解答

“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审阅本文。

深入解析Kubernetes安全配置：allowPrivilegeEscalation的真相

本文深入探讨Kubernetes安全上下文中的allowPrivilegeEscalation选项，通过实际代码演示说明其工作原理，澄清常见误解，并分析其在容器安全防护中的实际作用与局限性。