chore: remove unused historic image files

11_ops/security/README.md

@@ -398,14 +398,15 @@ $ cosign sign --key cosign.key $IMAGE
 $ cosign verify --key cosign.pub $IMAGE
 ```
 
-### 3. SLSA（Supply-chain Levels for Software Artifacts）
-
+### 3. SLSA (Supply-chain Levels for Software Artifacts)
 遵循 SLSA 框架，确保构建过程的完整性，例如使用 GitHub Actions 等受控环境进行构建，而非在开发者本地机器上构建发布。
 
 ---
 
 ## 本章小结
 
+相关信息如下表：
+
 | 安全措施 | 重要程度 | 实现方式 |
 |---------|---------|---------|
 | 非 root 运行 | ⭐⭐⭐ | `USER` 指令 |

11_ops/security/daemon_sec.md

@@ -13,6 +13,7 @@
 最近改进的 Linux 命名空间机制将可以实现使用非 root 用户来运行全功能的容器。这将从根本上解决了容器和主机之间共享文件系统而引起的安全问题。
 
 终极目标是改进 2 个重要的安全特性：
+
 * 将容器的 root 用户[映射到本地主机上的非 root 用户](https://docs.docker.com/engine/security/userns-remap/)，减轻容器和主机之间因权限提升而引起的安全问题；
 * 允许 Docker 服务端在[非 root 权限 (rootless 模式)](https://docs.docker.com/engine/security/rootless/) 下运行，利用安全可靠的子进程来代理执行需要特权权限的操作。这些子进程将只允许在限定范围内进行操作，例如仅仅负责虚拟网络设定或文件系统管理、配置操作等。
 

11_ops/security/kernel_capability.md

@@ -10,6 +10,7 @@ Linux 内核自 2.2 版本起就支持能力机制，它将权限划分为更加
 默认情况下，Docker 启动的容器被严格限制只允许使用内核的一部分能力。
 
 使用能力机制对加强 Docker 容器的安全有很多好处。通常，在服务器上会运行一堆需要特权权限的进程，包括有 ssh、cron、syslogd、硬件管理工具模块 (例如负载模块)、网络配置工具等等。容器跟这些进程是不同的，因为几乎所有的特权进程都由容器以外的支持系统来进行管理。
+
 * ssh 访问被主机上 ssh 服务来管理；
 * cron 通常应该作为用户进程执行，权限交给使用它服务的应用来处理；
 * 日志系统可由 Docker 或第三方服务管理；
@@ -17,6 +18,7 @@ Linux 内核自 2.2 版本起就支持能力机制，它将权限划分为更加
 * 网络管理也都在主机上设置，除非特殊需求，容器不需要对网络进行配置。
 
 从上面的例子可以看出，大部分情况下，容器并不需要 “真正的” root 权限，容器只需要少数的能力即可。为了加强安全，容器可以禁用一些没必要的权限。
+
 * 完全禁止任何 mount 操作；
 * 禁止直接访问本地主机的套接字；
 * 禁止访问一些文件系统的操作，比如创建新的设备、修改文件属性等；

11_ops/security/other_feature.md

@@ -5,6 +5,7 @@
 除了能力机制之外，还可以利用一些现有的安全机制来增强使用 Docker 的安全性，例如 TOMOYO，AppArmor，Seccomp，SELinux，GRSEC 等。
 
 Docker 当前默认只启用了能力机制。用户可以采用多种方案来加强 Docker 主机的安全，例如：
+
 * 在内核中启用 GRSEC 和 PAX，这将增加很多编译和运行时的安全检查；通过地址随机化避免恶意探测等。并且，启用该特性不需要 Docker 进行任何配置。
 * 使用一些有增强安全特性的容器模板，比如带 AppArmor 的模板和 Redhat 带 SELinux 策略的模板。这些模板提供了额外的安全特性。
 * 用户可以自定义访问控制机制来定制安全策略。