OPSaid – 运行时安全

Docs: AppArmor

Mon, 04 Dec 2023 14:10:28 +0800

简要概述

AppArmor 是一个 Linux 内核安全模块，用于补充系统用户和组的权限，将程序限制在一组有限的资源中。

它通过调整配置文件以允许特定程序或容器所需的访问，如 Linux 权能字、网络访问、文件权限等。每个配置文件都可以在强制（enforcing）模式（阻止访问不允许的资源）或投诉（complain）模式（仅报告冲突）下运行。

有三个主要版本，分别是 2.x 系列（旧版本但仍受支持）、3.x 系列（当前版本）和 4.x 系列（开发中）

快速开始

确认环境

查看宿主上是否启用：

cat /sys/module/apparmor/parameters/enabled

查看宿主上规则加载：

apparmor_status

目录结构

AppArmor 工具的配置在 /etc/apparmor/ 目录下。

AppArmor 策略存储在 /etc/apparmor.d/ 目录下，各目录用途如：

目录	说明
/etc/apparmor.d/abstractions/	包含用于构建 AppArmor 抽象配置的文件，可在多个配置文件中重复使用，以提高可维护性和复用性
/etc/apparmor.d/apache2.d/	包含与 Apache2 Web 服务器相关的 AppArmor 配置文件
/etc/apparmor.d/cache/	预编译的二进制策略文件
/etc/apparmor.d/disable/	包含一些符号链接，这些链接指向需要禁用的配置文件，禁用配置文件意味着它们不会对系统中的进程生效
/etc/apparmor.d/force-complain/	包含一些符号链接，这些链接指向需要强制使用 complain 模式的配置文件，在该模式中，违反策略的行为将被记录，但不会导致实际的限制
/etc/apparmor.d/libvirt/	包含与 libvirt 虚拟化工具相关的 AppArmor 配置，用来限制与虚拟机和容器相关的进程的权限
/etc/apparmor.d/local/	本地管理员创建的自定义的配置文件通常存储在这个目录中，这样可以确保不会与系统提供的配置文件发生冲突
/etc/apparmor.d/namespaces/	TODO;
/etc/apparmor.d/pam/	包含与 PAM 相关的 AppArmor 配置
/etc/apparmor.d/tunables/	TODO;

具体取决于你的操作系统供应商和版本，你的系统可能具有上述目录中的一些或全部。策略的编写是通过特有的语法 AppArmor_Core_Policy_Reference 为各个应用编写成配置文件，然后使用 apparmor_parser 编译并加载到内核中。

限制本地应用测试

编写规则

cat << EOF >> /etc/apparmor.d/local/usr.bin.touch
#include <tunables/global>

profile /usr/bin/touch {
 #include <abstractions/base>

 /tmp/** r,
}
EOF

这个规则说明禁止 /usr/bin/touch 在 “/tmp/” 目录下写，仅允许读。

生效规则

apparmor_parser --add /etc/apparmor.d/local/usr.bin.touch --verbose

或者替换现有规则

apparmor_parser --replace /etc/apparmor.d/local/usr.bin.touch --verbose

只有通过以上两个命令才可真正生效规则。

这个时候可以通过 apparmor_status 查看当前系统所有生效的规则列表。

测试规则

root@limiqi-dell-01:/etc/apparmor.d/local# touch /tmp/hello2.txt
touch: cannot touch '/tmp/hello2.txt': Permission denied
root@limiqi-dell-01:/etc/apparmor.d/local#

创建文件 “/tmp/hello2.txt” 此时被拒绝。

限制 Kubernetes 应用测试

编写规则

cat << EOF >> /etc/apparmor.d/local/kubernetes-app-demo-1
profile kubernetes/app-demo-1 {
 file,
 deny /root/** w,
}
EOF

这个规则说明禁止往 “/root/*” 目录下写文件。

生效规则

第一部分同限制本地应用测试 / 生效规则；

第二部分为启用的 Pod 添加注解，格式为：

container.apparmor.security.beta.kubernetes.io/<container_name>: <value>

其中 “<container_name>” 对应 Pod 内需要启用的容器名，如有多个可单独配置，“value” 可配置以下三个值：

value	说明
runtime/default	指默认运行时配置文件，见默认规则
localhost/<profile_name>	使用本地自定义规则，该宿主上必须存在，否则无法启动 Pod
unconfined	这相当于为容器禁用 AppArmor

对应以上规则使用 “kubernetes/app-demo-1” 的规则为：

apiVersion: v1
kind: Pod
metadata:
 annotations:
 container.apparmor.security.beta.kubernetes.io/nginx: localhost/kubernetes/app-demo-1
 name: nginx

测试规则

root@limiqi-dell-01:/etc/apparmor.d/local# kubectl exec -i -t nginx /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ # echo "hello world" > /root/test.txt
/bin/sh: can't create /root/test.txt: Permission denied
/ #
/ # ^C
command terminated with exit code 130
root@limiqi-dell-01:/etc/apparmor.d/local#

常见问题

查找使用默认 containerd 的 AppArmor

由于 containerd 在宿主上生成的 profile 名称为 “cri-containerd.apparmor.d” 所以可以通过查找即可知道哪些容器使用了：

apparmor_status | grep cri-containerd.apparmor.d
 cri-containerd.apparmor.d
 /usr/local/bin/kube-apiserver (6428) cri-containerd.apparmor.d
 /usr/local/bin/kube-controller-manager (6759) cri-containerd.apparmor.d
 /coredns (18598) cri-containerd.apparmor.d
 /metrics-server (19028) cri-containerd.apparmor.d
 /usr/bin/dumb-init (19826) cri-containerd.apparmor.d
 /nginx-ingress-controller (19838) cri-containerd.apparmor.d
 /usr/local/nginx/sbin/nginx (19864) cri-containerd.apparmor.d
 /usr/local/nginx/sbin/nginx (19869) cri-containerd.apparmor.d
 /usr/local/nginx/sbin/nginx (19870) cri-containerd.apparmor.d
 /usr/local/nginx/sbin/nginx (19871) cri-containerd.apparmor.d
 /usr/local/nginx/sbin/nginx (19872) cri-containerd.apparmor.d
 /usr/local/nginx/sbin/nginx (19873) cri-containerd.apparmor.d
 /usr/local/nginx/sbin/nginx (19874) cri-containerd.apparmor.d
 /usr/local/nginx/sbin/nginx (19875) cri-containerd.apparmor.d
 /usr/local/nginx/sbin/nginx (19876) cri-containerd.apparmor.d
 /usr/local/nginx/sbin/nginx (19877) cri-containerd.apparmor.d
 /usr/bin/kube-controllers (56874) cri-containerd.apparmor.d
 /usr/local/bin/kube-scheduler (62513) cri-containerd.apparmor.d
 /usr/local/bin/etcd (64804) cri-containerd.apparmor.d

或者使用 ps 添加 -Z 标志，以显示每个进程的安全配置文件。

Docs: Seccomp

Tue, 05 Dec 2023 10:55:56 +0800

简要概述

Seccomp（Secure Computing）是自 2.6.12 版本后内核的一个特性，它背后思想是限制进程可以使用的系统调用。

Linux 内核有几百个系统调用，但大多数进程并不需要它们，然而，如果一个进程受到入侵并被使用本身功能之外的其他系统调用，可能导致安全漏洞，从而危及整个系统的安全性。通过限制可以调用哪些系统调用，它是构建应用程序沙盒的关键组件。

目前存在两种主要的模式，分别是严格模式（Strict Mode）和过滤器模式（Filter Mode）：

严格模式

除了最基本的 read ，write ，_exit ，_sigreturn 四个之外，一旦出现其他的系统调用，进程会被立刻终止 (SIGKILL)。

过滤器模式

允许应用程序定义一组自定义的系统调用过滤规则，过滤器模式使用BPF（Berkeley Packet Filter）语言来编写，适用于需要更精细控制的场景。

在应用中使用

严格模式

未使用 seccomp 编译执行

cat << EOF >> /tmp/test1.c
#include <stdio.h>
#include <sys/prctl.h>
#include <sys/socket.h>

int main(int argc, char* argv[]) {
 printf("Install seccomp\n");

 printf("Creating socket\n");
 int sock = socket(AF_INET, SOCK_STREAM, 0);

 return 0;
}
EOF

$ gcc -o test1 test1.c
$ ./test1
Install seccomp
Creating socket
$

此时编译执行成功。

添加 seccomp 代码使用严格模式

cat << EOF >> /tmp/test2.c
#include <stdio.h>
#include <sys/prctl.h>
#include <sys/socket.h>

#include <linux/seccomp.h>

int main(int argc, char* argv[]) {
 printf("Install seccomp\n");

 // 使用 Seccomp 严格模式
 prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT);

 printf("Creating socket\n");
 int sock = socket(AF_INET, SOCK_STREAM, 0);

 return 0;
}
EOF

$ gcc -o test2 test2.c
$ ./test2
Install seccomp
Creating socket
Killed
$

此时编译成功，执行应用在调用创建 socket 时马上被 KILL。

过滤器模式

cat << EOF >> /tmp/test3.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/prctl.h>
#include <sys/socket.h>
#include <stddef.h>

#include <linux/filter.h>
#include <linux/seccomp.h>

int main() {
 printf("Install seccomp\n");

 // 使用 Seccomp 过滤器模式
 prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER);

 // 定义允许的系统调用规则
 struct sock_filter filter[] = {
 BPF_STMT(BPF_LD | BPF_W | BPF_ABS, offsetof(struct seccomp_data, nr)), // 载入系统调用号
 BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW), // 允许socket系统调用
 BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL), // 其他系统调用将导致程序终止
 };

 struct sock_fprog prog = {
 .len = sizeof(filter) / sizeof(filter[0]),
 .filter = filter,
 };

 // 设置 NO_NEW_PRIVS 标志
 prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);

 // 加载 Seccomp 规则
 prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog);

 printf("Creating socket\n");
 int sock = socket(AF_INET, SOCK_STREAM, 0);

 if (sock == -1) {
 perror("Socket creation failed");
 exit(EXIT_FAILURE);
 }

 printf("Socket created successfully\n");

 return 0;
}
EOF

$ gcc -o test3 test3.c
$ ./test3
Install seccomp
Creating socket
Socket created successfully
$

此时编译执行成功。

在 Kubernetes 上使用

配置 Pod securityContext 启用

其中可配置的参数参考 Pod SeccompProfile。

---
apiVersion: v1
kind: Pod
metadata:
 name: nginx
spec:
 containers:
 - image: registry.cn-hangzhou.aliyuncs.com/kube-image-repo/busybox:1.35.0
 name: nginx
 resources: {}
 args:
 - /bin/sh
 - -c
 - "sleep 3600"
 securityContext:
 allowPrivilegeEscalation: false
 securityContext:
 runAsNonRoot: false
 runAsUser: 99
 seccompProfile:
 type: Localhost
 localhostProfile: profiles/audit.json

这里使用了宿主 “profiles/audit.json” 上的 seccomp 配置，这里的路径是在 kubelet 工作目录下，如："/var/lib/kubelet"。

启用容器默认 seccomp 策略

在 kubelet 添加以下启动参数，同时 feature 未被禁用：

--seccomp-default=true

启用 RuntimeDefault 作为所有工作负载的默认 seccomp 配置文件。

检查当前 seccomp 启用的容器

crictl inspect 2b6a707db3c26 | jq .info.runtimeSpec.linux.seccomp

如果结果为 “null” 则说明该容器未使用到 seccomp 技术。

null

特别的当启用特权模式的 Pod 是无法使用 seccomp 的，既然：

 securityContext:
 privileged: true

Docs: Falco

Fri, 05 Jan 2024 10:35:12 +0800

简要概述

TODO;

规则

falco rules 使用 yaml 格式编写，有 “Rules”、“Lists”、“Macros” 三种类型：

Rules

在什么条件下会生成一个警报。一条规则通常伴随着一个描述性的输出字符串，该字符串会随着警报一起发送，示例规则如下：

- rule: shell_in_container
 desc: notice shell activity within a container
 condition: >
 evt.type = execve and
 evt.dir = < and
 container.id != host and
 (proc.name = bash or
 proc.name = ksh) 
 output: >
 shell in a container
 (user=%user.name container_id=%container.id container_name=%container.name
 shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline) 
 priority: WARNING

参数	必须	默认值	描述
rule	是	-	规则名称，全局唯一
condition	是	-	应用于事件的过滤表达式，用于检查它们是否与规则匹配
desc	是	-	这个规则用途描述
output	是	-	如果匹配到该规则，则对外输出内容
priority	是	-	告警级别取值：emergency, alert, critical, error, warning, notice, informational, debug
exceptions	否	-	TODO;
enabled	否	true	是否启用规则，默认启用
tags	否	-	关联到该规则的标签
warn_evttypes	否	true	如果设置为 false 将抑制与规则没有事件类型相关的警告
skip-if-unknown-filter	否	false	如果设置为true，如果规则条件包含一个过滤检查，例如fd.some_new_field，而该版本的Falco不知道这个字段，Falco会默默接受这条规则但不执行它；如果设置为false，Falco在发现未知的过滤检查时会报告错误并退出。
source	否	syscall	这个规则应该被评估的事件来源。典型的值包括syscall、k8s_audit，或者由源插件提供的来源。

Macros

宏提供了一种以可重用的方式定义规则常见子部分的方法，可以在规则内部甚至其他宏中重复使用。

参数	必须	默认值	描述
macro	是	-	规则名称，全局唯一
condition	是	-	应用于事件的过滤表达式，用于检查它们是否与规则匹配

如上 “Rules” 的 “condition” 示例中以下两个语句，被大量使用：

evt.type = execve and evt.dir = <

container.id != host

这两个条件将被许多其他规则频繁使用，因此为了简化工作，我们可以为它们分别定义宏：

- macro: container
 condition: container.id != host

- macro: spawned_process
 condition: evt.type = execve and evt.dir = <

此时更改后的规则如下：

- rule: shell_in_container
 desc: notice shell activity within a container
 condition: >
 spawned_process and
 container and
 proc.name = bash 
 output: >
 shell in a container
 (user=%user.name container_id=%container.id container_name=%container.name
 shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline) 
 priority: WARNING

Lists

列表是命名的项目集合，你可以在规则、宏，甚至其他列表中使用这些项目，与规则和宏不同，列表不能被解析为过滤表达式。

参数	必须	默认值	描述
list	是	-	规则名称，全局唯一
items	是	-	数组格式，列表的值

- list: shell_binaries
 items: [bash, csh, ksh, sh, tcsh, zsh, dash]

- list: userexec_binaries
 items: [sudo, su]

- list: known_binaries
 items: [shell_binaries, userexec_binaries]

- macro: safe_procs
 condition: proc.name in (known_binaries)