Seccomp 簡介

Seccomp（全稱 “Secure computing”），早在 2.6.12 版本（2005年3月8日）就引入到內核中，是通過只允許內核支持部分 syscall（系統調用），或者拒絕內核認為可能有危險的 syscall 集合的方式，來限制一個進程所支持的 syscall調用。

最初，Seccomp 只允許使用read、 write、_exit、sigreturn 4個系統調用，一旦調用其他系統調用時，內核就會發送 SIGKILL 信號終止進程。因此也被稱為 Seccomp-strict 模式。但由于其限制過于嚴格，導致實際上，并沒有多少應用能夠用的上這一安全特性。

直到 3.5 版本（2012年7月12日）的內核中引入 Seccomp的第二種匹配模式。

在這種模式下，可以通過所謂的 filter自定義被允許使用的 syscall，而自定義過濾規則是借由BPF 語言來實現，故可以事先在用戶態下定義好需要匹配的系統調用，并且加載到內核中，這種模式也被稱為Seccomp-BPF。

相比于 Seccomp-strict 模式，Seccomp-BPF 極大的增添了 syscall 的可擴展性，并且使用 BPF 編寫也大大的降低了開發者的編寫難度。

現如今，關鍵的程序限制為只允許調用那些「它絕對需要的成功運行的系統調用」，這種思想被越來越多的產品采納。基于瀏覽器的沙箱和在云原生上大火的容器就是就是兩個很好的示例，甚至于 systemd 服務也能夠通過 Seccomp 來限制。

一個 seccomp profile 簡單示例如下：

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "madvise",
                "epoll_ctl",
                "getsockname",
                "setsockopt",
                "vfork",
                "mmap",
                "read",
            ],
            "action": "SCMP_ACT_ALLOW",
        }
    ]
}

如何理解這個 Seccomp profile 呢？

SCMP_ACT_ALLOW 表示syscall 允許通過，將defaultAction 設置為 SCMP_ACT_ERRNO 則不在 syscall白名單范圍內的 syscall 都會被拒絕，還可以將defaultAction 設置為 SCMP_ACT_LOG 則不在 syscall 白名單范圍內的 syscall 會產生日志。

通過 Seccomp Profile 用于可以根據服務所需的 syscall 自行定義，通過 SCMP_ACT_ERRNO 與SCMP_ACT_ALLOW 配合實現對允許的 syscall 放行，對不在 syscall 列表中的 syscall 進行攔截。從而實現 syscall維度服務的安全防護。

SCMP_ACT_LOG與SCMP_ACT_ERRNO 可以在不同場景使用，進而實現不同程度的安全防護即告警和攔截。

Linux 內核主要支持的 Seccomp Filter 動作如下：

Seccomp in Kubernetes

從安全的角度來看，Kubernetes 中包含如下所示的潛在攻擊面：

為了保證集群以及容器應用的安全，Kubernetes 提供了多種安全機制，限制容器的行為，減少容器和集群的攻擊面，保證整個系統的安全性。

本文主要介紹 Kubernetes 中的 Seccomp 功能。Seccomp （Secure computing mode縮寫）代表安全計算模式，自 2.6.12 版本以來一直是 Linux 內核的一個特性。它可以用來設置沙箱化進程的權限，限制它從用戶空間到內核的系統調用。Kubernetes 可以自動將 Seccomp profile 加載到pod 和容器所在的節點。Kubernetes 提供兩種方式用于 pod 綁定 seccomp profile。

通過 annotation 標簽綁定 seccomp profile

用戶可以通過 pod 中的 annotation 標簽向 pod 中添加seccomp 安全配置，并且可以選擇對 pod 添加 seccomp 還是對 pod 中某個容器添加 seccomp 策略。

pod 層面：

annotations:
seccomp.security.alpha.kubernetes.io/pod: "localhost/profile.json"

container 層面：

annotations:
container.security.alpha.kubernetes.io/: "localhost/profile.json"

這里容器運行時會默認從節點上配置的 seccomp 策略文件目錄（k8s 集群上默認為/var/lib/kubelet/seccomp）中加載名稱為 profile.json 的配置文件，這里的配置 value 支持以下三種策略：

runtime/default-使用運行時默認的 seccomp 配置，比如docker 默認的 profile、containerd 的默認 profile

unconfined-不使用 seccomp 過濾

localhost/-使用節點本地 seccompprofileroot 路徑下自定義的配置文件

注意：從 Kubernetes v1.25 開始，kubelet 不再支持這些注解，也不再支持在靜態 Pod 中使用注解，并且當創建帶有 seccomp 字段的 Pod 時不再自動填充 seccomp 注解。后續統一使用下面介紹的 securityContext 配置。

通過 security-context 配置 seccompprofile

社區從 1.19 版本 seccomp 特性 GA 開始在securityContext 配置中增加了 seccompProfile 的字段，用戶可以直接在此配置 Pod 和 Container 維度的 seccomp策略，由于 annotations 配置的方式已經是廢棄狀態，為了今后不必要的兼容性調整，推薦使用該方式配置：

securityContext:
 seccompProfile:
 type: Localhost
 localhostProfile: profiles/audit.json

有三種 seccomp 配置類型：

Unconfined:不啟用 seccomp

RuntimeDefault: kubelet 會啟用默認的 seccomp 配置（默認 seccomp 配置文件是有容器運行時定義的）

Localhost:節點本地seccomp 配置根目錄（一般默認為/var/lib/kubelet/seccomp）下配置文件的相對路徑

所以基于 k8s 提供的 seccomp 配置方式，我們可以實現對 pod 進行 syscall 級別的安全防護。

Seccomp 在云原生場景下的應用方式

云原生場景下，業務一般是通過微服務的方式對外提供服務，一般每個微服務的行為相比與主機業務行為會更為單一。因此當通過一系列的測試手段激發出服務所需的全部syscall 從而生成 syscall 白名單，通過 syscall 白名單限制服務系統調用，可以在 syscall 維度保證服務安全。當有攻擊通過服務漏洞進入到服務對應的 Pod 中，它想要進行一些操作，但這些操作對應的 syscall 不在白名單內，此時攻擊失敗。

我們將 syscall 白名單的生成與使用分為三個階段：學習階段，監視階段，保護階段。

整個過程如圖所示：

學習階段：seccomp controller 組件為 crd 資源，它可以實現對 k8s 集群內指定 pod 進行 syscall 采集并且將采集得到的 syscall 列表落盤到每個工作節點。seccomp controller 的 syscall 學習功能是通過 eBPF實現的，通過eBPF可以獲取工作節點每個進程產生的系統調用，進而獲取到指定 pod 對應的系統調用。通過eBPF的方式，將集群中每個容器產生的 syscall 調用進行收集，生成 syscall 白名單。

監視階段：使用 SCMP_ACT_LOG 過濾方式，可以將不在白名單的系統調用，以日志的形式打印出來，此時測試人員和安全運維人員可以對系統調用進行判斷，確定業務是否需要該 syscall，如果需要則加入到 syscall 白名單中。在監視階段可以完成 syscall 白名單的收斂，進而得到與業務完全匹配的 syscall 白名單。

監視模式創建的 seccomp 配置文件如下所示：（syscall列表只是舉例，實際 Pod 所需 syscall 列表會更多）

{
  "defaultAction": "SCMP_ACT_LOG",
  "architectures": [
      "SCMP_ARCH_X86_64",
      "SCMP_ARCH_X86",
      "SCMP_ARCH_X32"
  ],
 "syscalls": [
     {
         "names": [
             "madvise",
             "epoll_ctl",
             "getsockname",
             "setsockopt",
"vfork",
             "mmap",
             "read",
             "write",
             "close",
             "arch_prctl"
         ],
 "action": "SCMP_ACT_ALLOW"
     }
]
}

保護階段：使用 SCMP_ACT_ERRNO 過濾方式，對每個業務容器進行 syscall 級別的保護。一旦業務容器中存在異常系統調用，對其進行攔截。

SCMP_ACT_ERRNO 對 syscall 攔截發生在內核態，所以不用擔心 seccomp profile 安全防護的效率問題。

保護模式創建的 seccomp 配置文件如下所示：

{
       "defaultAction":"SCMP_ACT_ERRNO",
       "architectures": [
           "SCMP_ARCH_X86_64",
           "SCMP_ARCH_X86",
           "SCMP_ARCH_X32"
      ],
      "syscalls": [
          {
              "names": [
                  "madvise",
                  "epoll_ctl",
                  "getsockname",
                  "setsockopt",
"vfork",
                  "mmap",
                  "read",
                  "write",
"close",
                  "arch_prctl"
      ],
"action":"SCMP_ACT_ALLOW"
           }
]
}

總結

本文從 Seccomp 機制出發，在 linux 內核層面介紹了 Seccomp 可以實現的安全能力即對進程的系統調用限制能力。

Kubernetes 為我們提供了可以對容器進行系統調用層面保護的接口即 Seccomp 能力。在云原生場景，通過使用 eBPF獲取業務系統調用白名單，通過linux 內核支持的 Seccomp 機制對業務容器進行系統調用維度的防護，進而保證業務容器 syscall 層面的安全。

一旦有攻擊者希望通過不在白名單內的 syscall 實現攻擊行為，通過 Seccomp 機制我們可以對攻擊進行告警和攔截，最終保證業務容器的安全。

Seccomp 機制為云原生場景提供了 Syscall 維度的安全保證，后續將對此持續探索。

審核編輯：劉清