文件系统权限、强制访问控制与 systemd 沙箱：把好第二道门

0. 元信息

• 主题路径：docs/topics/linux-hardening/subtopics/permissions-and-mac/
• 父主题：linux-hardening
• 主分类：安全与可靠性
• 辅助分类：工程技术
• 适合对象：理解 chmod 755、跑过基本 systemd service、知道”root 啥都能干”的运维 / 后端 / 安全工程师
• 建议周期：1.5～2 周（每周 8～10 小时，含 SELinux / AppArmor 实验）
• 前置知识：linux-dev-env；identity-and-ssh
• 最终目标：能清理 SUID/SGID 残留并维护白名单，能用 Linux capabilities 让非 root 进程绑 80，能用 SELinux/AppArmor 限制一个服务只读指定目录并验证违规访问被拦截，能用 systemd sandboxing 指令给一个自写服务加 10+ 条沙箱并保持功能正常

1. 学习路线

UNIX 权限（rwx 八进制、属主、umask）
  → ACL（getfacl / setfacl）
  → 不可变位（chattr +i / +a）
  → SUID / SGID / sticky bit（4 位八进制）
  → Linux capabilities（cap_net_bind_service 等）
  → systemd 沙箱指令（PrivateTmp / PrivateDevices / ProtectHome / ProtectSystem / NoNewPrivileges / DynamicUser / SystemCallFilter）
  → SELinux 概念（user/role/type、policy、enforcing/permissive）
  → SELinux 操作（semanage、setsebool、restorecon、audit2allow）
  → SELinux CIL 写自定义 policy
  → AppArmor 概念（profile、mode、include、hat）
  → AppArmor 写 profile（aa-genprof / aa-logprof）

按”先说是什么，再说怎么挡”的顺序：先 UNIX 权限基线；再 capabilities 拆 root；再 MAC（SELinux/AppArmor）做标签级隔离；最后 systemd 沙箱做进程级隔离。

2. 阶段周数分配（1.5～2 周，建议 2 周）

每天 1.5 小时；1.5 周速通每天 2 小时能跑完，但 SELinux CIL 与 AppArmor profile 容易踩拼写错。建议 2 周：SELinux CIL 与 AppArmor 各留 1.5 天写 profile。

3. 九阶段表

关键陷阱：SUID 清理过度清掉 passwd / ping / sudo；setcap 给解释器（python/node）等于无限制；systemd 沙箱加 ProtectSystem=strict 后服务写 /etc 失败但日志不说为什么；SELinux 改 permissive 后忘改回；AppArmor profile 拼写错 profile 名被忽略。

4. 第一周任务（每天 1.5～2 小时）

Day 1 约定：用一台 Ubuntu 22.04 + AppArmor 或 RHEL 9.x + SELinux 虚机/容器；先建快照。统一记录 lsb_release -a、getenforce 或 aa-status、capsh --print。

Day 7 拆解

步骤 A —— 最小可用（90 分钟）

1. 在目标服务路径（如 /srv/myapp）建个测试目录，写入 index.html；
2. 启动一个 python3 简单 HTTP server：python3 -m http.server 8080 --directory /srv/myapp；
3. curl http://localhost:8080/ 看到 200；但 SELinux/AppArmor 状态查拒绝：
   • SELinux：sudo ausearch -m AVC -ts recent 看 type=AVC msg=audit(...): avc: denied { read } ...；
   • AppArmor：sudo dmesg | grep -i 'apparmor.*DENIED' 看 audit: type=1400 ... apparmor="DENIED"；
4. SELinux：sudo chcon -t httpd_sys_content_t /srv/myapp 后再 curl，应允许；
5. AppArmor：aa-genprof /usr/bin/python3 跑 wizard，确认允许访问 /srv/myapp；写入 /etc/apparmor.d/usr.bin.python3，sudo apparmor_parser -r /etc/apparmor.d/usr.bin.python3。

步骤 B —— 持久化 + 边界（30～45 分钟）

1. SELinux：用 semanage fcontext -a -t httpd_sys_content_t '/srv/myapp(/.*)?' + restorecon -Rv /srv/myapp 持久化（chcon 不持久）；
2. AppArmor：aa-enforce /usr/bin/python3 改强制模式；aa-status 看到 enforce；
3. 重启服务，第二次跑应仍允许；
4. SELinux 切 permissive（sudo setenforce 0）验证 AVC 不再拒；切回 enforcing（sudo setenforce 1）验证策略生效；
5. 故意访问 /etc/shadow：服务应被拒；ausearch 应记录新 AVC。

5. 阶段通用验收（每一阶段都通过）

1. 能用 1 张表说出 CIS Benchmark 1.x 文件权限 / 5.x SSH / 6.x 服务配置 的核心控制项；
2. 改完配置用 stat -c '%a %U %G'、getcap、systemd-analyze security、getenforce、aa-status、ausearch -m AVC 看证据，存进 notes/；
3. 制造 1 个对照实验：留 /usr/bin/python3 SUID → 用 python3 -c 'import os; os.setuid(0); os.system("/bin/bash")' 提权成功；移除 SUID → 失败；
4. 至少 3 组自定义数据：故意跑 SUID shell wrapper、故意给解释器加 cap、故意开 ProtectSystem=strict 后服务写 /etc 失败；贴 journalctl 与 ausearch 输出；
5. 记录变更：每改一个文件 / unit / SELinux 布尔 写一条（who/when/what/why/CIS 控制项号）；
6. 能修改已有 profile 或 service（删/加一条沙箱指令；删/加一条 SELinux 规则），而不是只照搬。

6. 最终验收（学完 9 阶段后）

• 独立完成：清理 SUID/SGID 残留并维护白名单；用 Linux capabilities 让非 root 绑 80；用 SELinux/AppArmor 限制一个服务只读指定目录并验证违规访问被拦；用 systemd sandboxing 给一个自写服务加 10+ 条沙箱并保持功能正常；
• 完成至少 30 条权限层加固项：SUID 白名单 ≤ 20 项；systemd 服务 systemd-analyze security 总分 ≤ 30（单项 ≤ 4）；SELinux getenforce = Enforcing；ausearch -m AVC --start today 在服务正常路径下无新 AVC；
• 完成 1 个综合项目：在一台 RHEL/Ubuntu 上为”自写 myapp + redis + nginx”三个服务分别加 systemd 沙箱 + SELinux/AppArmor profile；跑 systemd-analyze security + ausearch 验证；能在 30 分钟内回滚到默认；
• 用 15 分钟讲清”DAC → ACL → attr → SUID → caps → MAC → namespace / seccomp”七层防御各堵哪类威胁，SUID 与 capabilities 的本质区别，ProtectSystem=strict 与 ReadWritePaths 怎么配合。

7. 综合项目

首选：写一份 harden-mac.md —— 准备一台干净的 RHEL 9 或 Ubuntu 22.04 虚机，先基线（find / -perm -4000 | wc -l、getenforce、aa-status、systemd-analyze security 全 unit 默认分），按 9 阶段顺序加固（UNIX → ACL → attr → SUID → caps → 沙箱 → MAC），用同一组命令对比前后。

要求：

• 准备 notes/baseline-before.md 与 notes/baseline-after.md；
• 逐项改：SUID 清理、capabilities 加、myapp.service 加沙箱、SELinux/AppArmor profile；
• 持久化：/etc/systemd/system/myapp.service、/etc/apparmor.d/usr.bin.python3 或 SELinux CIL /var/lib/selinux/myapp.pp；
• 验证：systemd-analyze security myapp 总分 ≤ 30；ausearch -m AVC --start today 无新拒绝；SUID 数量从基线降至少 30%；
• 输出 notes/retrospective.md：哪些被坑过（解释器 cap、沙箱过严、profile 拼写错、restorecon 漏跑）。

备选：在 Ubuntu 22.04 上为 nginx + 自写 myapp 各写一个 AppArmor profile，验证违反被拦；用 aa-logprof 从日志生成。

任何综合项目都必须包含：

1. 需求与成功标准（含权限/MAC 目标和验证命令）；
2. 基线 vs 目标差距表；
3. 配置按层（UNIX / ACL / attr / SUID / caps / 沙箱 / SELinux / AppArmor）；
4. 脚本化（scripts/harden-mac.sh + scripts/verify-mac.sh），幂等可重跑；
5. 正常 + 异常验证（解释器 cap → 任意命令；沙箱开 → 写 /etc 被拦；MAC 开 → 违反被拦）；
6. 报告：基线、目标、结果、剩余项、复盘；
7. README；
8. 复盘记录。

本主题贡献（Loop 6-D · linux-hardening / permissions-and-mac）

本主题交付”UNIX 权限 + ACL + attr + SUID 收敛 + capability 收紧 + 沙箱 + MAC”七层加固脚本化包，故意给 Python 解释器加 cap_net_bind_service 看任意命令可执行，再收紧 + 沙箱开启验证拦截。

3 项核心职责

• UNIX / ACL / attr / SUID：用 chmod / chown / setfacl 收紧权限；用 chattr +i 给关键配置（/etc/passwd / /etc/shadow / /etc/sudoers）加不可改；用 find / -perm -4000 收敛 SUID / SGID（白名单之外清零）。
• capability + 沙箱：用 getcap -r / 审计文件 capability，给解释器（python / perl / node）收紧（禁 cap_net_bind_service 等任意 cap）；配 systemd ProtectSystem=strict / PrivateTmp=true / NoNewPrivileges=true 给服务套沙箱。
• MAC（SELinux / AppArmor）：RHEL / CentOS 走 SELinux enforcing（/etc/selinux/config + restorecon），Ubuntu / Debian 走 AppArmor enforce（aa-enforce + 自写 profile），故意违反看被拦。

4 项交付物

1. 基线 vs 目标差距表：含 UNIX 权限收紧目标、ACL 应用清单、attr 加锁清单、SUID 白名单、capability 收紧清单、沙箱策略、MAC 模式七项 + 验证命令（getfacl / lsattr / getcap -r / / aa-status / sestatus）。
2. UNIX / ACL / attr / SUID 收敛脚本：scripts/harden-mac.sh（幂等），含 SUID 白名单文件、attr 加锁清单、ACL 应用清单，故意解释器 cap 验证任意命令可执行后收紧。
3. 沙箱配置（systemd unit override）：每个服务一个 override.conf，含 ProtectSystem=strict / PrivateTmp=true / NoNewPrivileges=true / RestrictAddressFamilies= 等，故意开沙箱看写 /etc 被拦。
4. MAC 策略落档（SELinux 或 AppArmor 二选一）：SELinux enforcing + restorecon 跑全站，或 AppArmor 自写 nginx + myapp profile（用 aa-logprof 从日志生成），故意违反被拦验证。

3 个验收指标

• find / -perm -4000 输出收敛到白名单（≤ 5 条且全在白名单文件）；getcap -r / 无解释器类 cap。
• 沙箱：服务运行时 cat /proc/<pid>/status | grep -E 'Seccomp|NoNewPrivs' 显示开启；写 /etc 被 Read-only file system 拦截。
• MAC：SELinux sestatus 显示 Current mode: enforcing 且 restorecon 跑通；AppArmor aa-status 显示 enforce profile ≥ 3 个，故意违反被 audit: type=1400 命中。

8. 推荐开源资料（按角色分工，避免堆链接）

许可证提示：CIS Benchmarks 注册免费账号下载；systemd man pages LGPL-2.1；Linux-PAM/auditd 都是 BSD/GPL 双许可；SELinux/AppArmor GPL-2.0；ComplianceAsCode SSG 是 GPL-3.0+ / BSD。复制 CIS 控制点脚本到生产前先在 staging 验证 —— 默认读思路后自己写。

默认使用顺序：man page → Arch Wiki / Red Hat Security Guide → CIS / ComplianceAsCode profile → 实操（audit2allow / aa-logprof / systemd-analyze security）→ 复盘到 notes/retrospective.md。

9. 学习资料汇聚（v0.3 自包含）

本节由本计划生成。

9.1 背景与动机

账号层决定了”谁能进”，但进到系统后能做什么由权限模型决定。传统 UNIX DAC（自主访问控制）由属主决定，灵活但粗：要么全开要么全关。Linux 进一步提供：

• ACL：在 owner/group/other 之外加更细的 ACL 项；
• 不可变位：连 root 都不能改（适合配置 / 二进制）；
• SUID/SGID：让普通用户跑特定特权操作（设计粗糙，常被滥用）；
• Linux capabilities：把 root 拆成 40+ 细粒度能力；
• MAC（SELinux / AppArmor）：在内核层强制访问控制，进程能读什么标签由策略决定，与属主无关；
• systemd 沙箱：在内核层为单个 service 隔离命名空间、文件系统、网络。

这层失守，攻击者拿到一个普通账号就够提权拿到 root（SUID / cap / 通配符写入）。

9.2 概念地图

flowchart TB
  DAC[UNIX 权限 rwx]
  ACL[POSIX ACL]
  Attr[chattr +i / +a]
  SUID[SUID / SGID / sticky]
  Caps[Linux capabilities]
  Seccomp[seccomp / SystemCallFilter]
  Namespaces[Mount / PID / Network NS]
  MAC[MAC]
  SELinux[SELinux]
  AppArmor[AppArmor]
  Sysd[systemd 沙箱]
  Files[文件系统] --> DAC
  DAC --> ACL
  DAC --> Attr
  DAC --> SUID
  DAC --> Caps
  Caps --> Sysd
  SUID --> MAC
  Sysd --> Seccomp
  Sysd --> Namespaces
  MAC --> SELinux
  MAC --> AppArmor
  Sysd --> MAC

9.3 基础知识讲解

9.3.1 主推

9.3.2 备查

9.3.3 必查 man pages

• chmod(1) chown(1) chgrp(1) umask(2)
• getfacl(1) setfacl(1) acl(5)
• chattr(1) lsattr(1)
• find(1) -perm -user -group
• getcap(8) setcap(8) capsh(1) capabilities(7)
• systemctl(1) systemd-analyze(1) systemd.exec(5) systemd.service(5) systemd.unit(5)
• getenforce(8) setenforce(8) semanage(8) setsebool(8) restorecon(8) audit2allow(1) audit2why(1) seinfo(8) sesearch(8)
• aa-status(8) aa-genprof(8) aa-logprof(8) apparmor.d(5)

9.4 经典问题与经典案例

9.5 学习难点

概念难点

思维难点

工程难点

9.6 技术标准与接口

9.6.1 Entity

9.6.2 Scope

• capabilities：把 root 拆分为细粒度能力；与 SUID 并存。
• SELinux：type-based MAC；RHEL/CentOS/Fedora 默认。
• AppArmor：path-based MAC；Ubuntu/SUSE 默认。
• systemd 沙箱：per-service 命名空间/seccomp/cgroup。
• CIS 1.x / 6.x：文件系统权限、SUID、Service 配置。
• 这些层不替代上层账号 / 网络 / 审计。

9.6.3 Structure

• capabilities 关键：CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SYS_ADMIN CAP_DAC_OVERRIDE CAP_CHOWN CAP_SYS_PTRACE CAP_SYS_RESOURCE。
• SELinux 关键：getenforce semanage fcontext semanage boolean setsebool -P restorecon audit2allow -M <name> semodule -i。
• AppArmor 关键：/etc/apparmor.d/<profile> aa-complain aa-enforce aa-logprof aa-genprof。
• systemd 沙箱关键指令（10+）：
  • PrivateTmp=yes / PrivateDevices=yes / PrivateNetwork=yes / PrivateUsers=yes
  • ProtectHome=yes / ProtectSystem=strict / ProtectKernelTunables=yes / ProtectKernelModules=yes / ProtectControlGroups=yes
  • ReadWritePaths= / ReadOnlyPaths= / InaccessiblePaths=
  • NoNewPrivileges=yes
  • RestrictSUIDSGID=yes / RestrictNamespaces=yes / RestrictRealtime=yes
  • LockPersonality=yes / MemoryDenyWriteExecute=yes / RestrictAddressFamilies=
  • SystemCallFilter=@system-service / SystemCallArchitectures=native
  • DynamicUser=yes / StateDirectory= / LogsDirectory= / CacheDirectory=
  • UMask=0077

9.6.4 Ecosystem

• 工具：systemd-analyze security <unit>、audit2why、aa-notify、sealert。
• 策略仓库：ComplianceAsCode（SSG）、Ubuntu AppArmor profile 集合、SUSE AppArmor。
• 集成：podman/docker 使用 SELinux/AppArmor 标签（--security-opt label=type:container_t）。
• 事实标准：targeted policy（SELinux 默认）、complain→enforce 流程（AppArmor）。

9.6.5 Depth Tiers

本计划目标：L3。

9.6.6 Source

• kernel.org capabilities(7)：https://www.kernel.org/doc/man-pages/
• SELinux：https://selinuxproject.org/
• AppArmor：https://gitlab.com/apparmor/apparmor/-/wikis/Documentation
• systemd：https://www.freedesktop.org/software/systemd/man/systemd.html
• Red Hat Security Guide：https://docs.redhat.com/en/documentation/en-us/red_hat_enterprise_linux/9/html/security_hardening
• 引用版本快照日期：2026-07-30。

10. 常见误区

• 误把 /usr/bin/python3 SUID 当合理配置；解释器 caps/suid = 任意代码；
• chmod 777 修”权限不足”问题；
• setenforce 0 后不写复盘，长期 permissive；
• AppArmor complain 模式上线；
• restorecon 不跑，标签错乱；
• audit2allow -M mypol 跑完不 semodule -i，规则没加载；
• ProtectSystem=strict 后业务挂，没查 journalctl；
• DynamicUser=yes 与 stateful service 一起用；
• RestrictAddressFamilies=AF_UNIX 后 DNS 解析失败；
• SystemCallFilter=~@clock 误伤时间服务；
• 信任 owner 写权限 = 没设 ACL；
• nosuid 没用到 /home / /tmp / /dev/shm；
• chattr +i 加到需要写的文件上导致 cron 挂；
• SUID binary 已知 CVE 没打补丁；
• AppArmor profile 名错不生效，自以为加固了；
• setcap cap_net_bind_service=+eip（i 表示 inherit）误加给 wrapper script。

11. 所有知识点分类（统一规则）

1. 编程语言
2. 数据结构与算法
3. 计算机基础
4. 工程技术
5. Web 与后端
6. 前端与客户端
7. 数据与人工智能
8. 项目与职业能力
9. 安全与可靠性

本计划归属：安全与可靠性 主 + 工程技术 辅。