Update versions and fix formatting issues

18_security/18.2_control_group.md

@@ -9,6 +9,7 @@
 默认情况下，Docker 容器对系统资源的使用是没有限制的：一个容器理论上可以使用宿主机所有的 CPU 计算能力、吃光所有的内存、耗尽所有的系统 PID。
 
 想象一下以下场景：
+
 - 一个恶意用户向你暴露在公网的应用发起海量并发请求。
 - 应用程序逻辑中存在内存泄漏漏洞。
 - 黑客在入侵容器后，在里面运行了挖矿木马程序。

18_security/18.3_daemon_sec.md

@@ -81,6 +81,7 @@ $ docker version
 在企业环境中，对 Docker 守护进程的访问控制往往不仅限于文件系统权限，还需要更细粒度的授权策略。**Authorization Plugin** 机制允许在 API 层级对请求进行拦截和审批。
 
 常见的授权插件包括：
+
 - **OPA/Conftest**：开放策略引擎，支持声明式策略定义。
 - **Prisma Cloud（Twistlock）**：商业容器安全平台。
 - 自定义脚本：根据请求内容（镜像、命令、用户等）做出允许/拒绝决定。

18_security/18.4_kernel_capability.md

@@ -9,12 +9,14 @@
 在默认情况下，即便一个容器是在以 `root` 用户运行，Docker 也只为其内核授予了所有可用能力中的 **一小部分“白名单”能力**。
 
 常见的 Linux Capabilities 包含：
+
 - `CAP_CHOWN`: 修改文件所有者。
 - `CAP_NET_BIND_SERVICE`: 绑定特权端口（即 1024 以下的端口）。
 - `CAP_NET_ADMIN`: 网络管理的最高权限（例如调整路由配置，设置防火墙规则等）。
 - `CAP_SYS_ADMIN`: 被誉为“Linux 内核的特权网管”，允许各种高危操作（挂载磁盘、访问敏感设备等）。
 
 为了在 **“最小特权原则”** 的指导下加强安全，Docker 默认 **移除了** 大量可能导致容器大范围破坏宿主机的能力，例如：
+
 * 完全禁止了任何通过 `CAP_SYS_ADMIN` 进行的核心挂载或设备操作。
 * 禁止修改内核模块。
 * 禁止直接访问硬件套接字。

18_security/18.5_other_feature.md

@@ -43,6 +43,7 @@ chmod: /etc/passwd: Operation not permitted
 传统的 Linux 模型遵循 DAC（自主访问控制），这意味着如果一个文件被赋予了全员读写权限（`777`），普通隔离下任何人便都能修改。但 **MAC（强制访问控制）** 技术，诸如 `AppArmor` (常用于 Ubuntu/Debian) 或 `SELinux` (常用于 CentOS/RHEL)，可以制定比“文件所有权”更宏观且优先的策略控制模块。
 
 在开启了上述机制的机器上：
+
 - **AppArmor**: Docker 为所有启动的应用加载了一个默认的 `docker-default` 模板文件，如果你的某些异常写行为（比如往特殊的内核心脏目录写入配置）不在 AppArmor 许可列表之上，即使拥有物理 Root，写入同样失败。
 - **SELinux**: 所有的 Docker 操作强制附加特殊上下文标识标签。就算把主机的 `/` 绑定给了黑客的某服务，黑客对不属于 Docker 可见的标签的文件进行读写尝试亦会被阻止。