【免费下载链接】Cybersecurity-ProjectsBuilding 70 Projects ranging from beginner to advanced so anyone can — learn from, build upon, use as a reference, or even copy directly. Gamified Cybersecurity learning 项目地址https://gitcode.com/gh_mirrors/cy/Cybersecurity-Projects点击查看免费下载本文以 Cybersecurity-Projects 仓库中docker-security-audit项目的核心学习文档 01-CONCEPTS.md 为主线系统讲解构建 Docker 安全审计工具所需掌握的六大安全主题Linux Capabilities 权限模型、命名空间隔离、Seccomp/AppArmor/SELinux 安全配置、敏感路径挂载、秘密检测与 CIS Docker Benchmark。通过结合该项目docksec一个对标 CIS Docker Benchmark v1.6.0 的 Go 安全审计 CLI的真实源码你将理解每个概念「是什么、为什么重要、底层如何工作、攻击者如何利用、如何防御」并掌握每个检测项在源码中的具体实现位置与判定逻辑为阅读后续架构与实现章节打下坚实基础。Linux Capabilities什么是Linux capabilities 将传统意义上「要么全有、要么全无」的 root 权限拆分为41 个离散的权限位。内核不再简单检查「进程是否以 root 运行」而是检查「该进程是否拥有CAP_NET_ADMIN」之后才允许其修改网络配置。该模型于 1999 年随内核 2.2 引入目的是实现权限分离。一个需要绑定 80 端口的 Web 服务器只需CAP_NET_BIND_SERVICE这一项权限即可无需完整 root 权限一个备份程序也只需CAP_DAC_READ_SEARCH来读取受保护的文件。这是现代容器技术得以安全运行的基石——容器内进程虽然看起来是 root但实际上只被授予了被裁剪后的能力集合。为什么重要容器默认拥有一组能力来支持常见操作。Docker 默认丢弃 13 个危险能力但仍保留 14 个能力源码中在 internal/proc/capabilities.go 以defaultDockerCaps集合明确定义var defaultDockerCaps map[string]struct{}{ CAP_CHOWN: {}, CAP_DAC_OVERRIDE: {}, CAP_FSETID: {}, CAP_FOWNER: {}, CAP_MKNOD: {}, CAP_NET_RAW: {}, CAP_SETGID: {}, CAP_SETUID: {}, CAP_SETFCAP: {}, CAP_SETPCAP: {}, CAP_NET_BIND_SERVICE: {}, CAP_SYS_CHROOT: {}, CAP_KILL: {}, CAP_AUDIT_WRITE: {}, }如果运维人员通过--cap-add把已丢弃的能力加回来或额外授予新能力就可能让容器获得完全逃逸宿主机的机会。而当执行docker run --privileged时Docker 会授予全部 41 个能力这等同于以 root 身份运行在宿主机上绕过全部容器隔离机制——这是审计工具必须首先检测的最严重配置。底层工作原理能力以64 位 bitmask的形式存储在进程凭证结构中内核在执行特权操作前检查对应比特位。进程实际拥有五组能力集合集合作用Effective内核当前实际检查的集合决定进程现在能做什么Permitted进程可以动用的能力上限是 Effective 的超集Inheritable可被 exec 继承给子进程的能力Bounding进程及其子进程的能力边界硬上限Ambient非特权程序 exec 后也能保留的能力该项目在 internal/proc/capabilities.go 中封装了CapabilitySet结构用uint64字段同时承载这五组集合并从/proc/PID/status中解析出十六进制掩码ParseCapabilityMask。核心判定方法HasCapability的逻辑即文档示例所示——通过位运算检查Effective集合中目标能力的比特位func (c *CapabilitySet) HasCapability(name string) bool { bit, ok : capabilityNames[name] if !ok { return false } return (c.Effective (1 bit)) ! 0 }该文件还提供了HasDangerousCapabilities、HasCriticalCapabilities、GetAddedCapabilities相对 Docker 默认 14 项能力算出新增项等方法用于对宿主机进程与容器进程分别做能力画像。41 个能力的严重性分级docksec将所有 41 个能力逐一映射到严重性等级定义在 internal/rules/capabilities.go。每条目包含严重性与描述例如CAP_SYS_ADMIN: { Severity: finding.SeverityCritical, Description: Perform a range of system administration operations. Effectively root - mount filesystems, quotas, namespaces, etc., },从源码中可以完整还原这份分级表的关键部分严重性取自 internal/finding/finding.go 的枚举INFO LOW MEDIUM HIGH CRITICAL能力严重性风险说明CAP_SYS_MODULECRITICAL加载/卸载内核模块可装 rootkit完全控制系统CAP_SYS_RAWIOCRITICAL访问/dev/mem、/dev/kmem直通硬件与内核内存CAP_SYS_PTRACECRITICAL追踪任意进程、读写其内存、注入代码、窃取秘密CAP_SYS_ADMINCRITICAL挂载文件系统、管理命名空间等等同于 rootCAP_MAC_OVERRIDECRITICAL绕过 SELinux/AppArmor 强制访问控制CAP_MAC_ADMINCRITICAL修改 MAC 策略直接禁用强制访问控制CAP_BPFCRITICAL加载 BPF 程序追踪系统调用、篡改网络流量CAP_DAC_OVERRIDEHIGH绕过文件读写执行权限检查完全访问文件系统CAP_DAC_READ_SEARCHHIGH绕过读权限检查可读任何文件CAP_SETUID/CAP_SETGIDHIGH任意篡改 UID/GID可直接提权到 rootCAP_NET_ADMINHIGH修改路由、防火墙规则嗅探流量、中间人攻击CAP_SYS_BOOTHIGH重启系统、调用 kexec_loadDoS 攻击CAP_MKNODHIGH创建设备节点可访问/dev/mem、/dev/sdaCAP_AUDIT_CONTROLHIGH禁用内核审计、修改审计规则彻底掩盖痕迹CAP_SETFCAPHIGH给可执行文件设置文件能力提权任意二进制CAP_CHECKPOINT_RESTOREHIGH用 CRIU 检查点/恢复进程访问进程内存与文件描述符CAP_NET_BIND_SERVICELOW绑定 1024 以下特权端口多数服务必需CAP_CHOWNMEDIUM修改文件属主绕过常规权限检查源码在init时预先计算了dangerousCapabilities严重性 ≥ HIGH与criticalCapabilities严重性 CRITICAL两个哈希集合配合normalizeCapability对输入做「大写 自动补CAP_前缀」的归一化保证扫描期间的查询复杂度为 O(1)。对运行中容器internal/analyzer/container.go 中的checkCapabilities遍历 Docker Inspect 返回的HostConfig.CapAdd把每个新加能力对照严重性数据库生成 finding对应 CIS 5.3 控制项for _, cap : range info.HostConfig.CapAdd { capName : strings.ToUpper(string(cap)) capInfo, exists : rules.GetCapabilityInfo(capName) if !exists { continue } if capInfo.Severity finding.SeverityHigh { // 创建 severity 来自能力数据库的 finding } }值得注意的设计判定严重性来自能力数据库而非硬编码逻辑新增一个危险能力只需在 internal/rules/capabilities.go 中增加一条映射即可自动生效。同一数据库也被 internal/analyzer/compose.go 用于扫描 compose 服务的cap_add声明以及被proc包用于宿主机进程分析。常见攻击通过 CAP_SYS_ADMIN 逃逸容器该能力允许挂载文件系统。攻击者可以在容器内把宿主机的根文件系统挂载进来从而脱离容器边界# Inside container with CAP_SYS_ADMIN mkdir /host mount /dev/sda1 /host chroot /host # Now running on the host历史上著名的 Shocker 利用CVE-2014-6407原理类似借助CAP_DAC_READ_SEARCH通过路径打开任意文件描述符绕过了命名空间隔离。通过 CAP_SYS_PTRACE 注入进程拥有该能力即可用ptrace()附着到任意进程读取其内存并注入代码ptrace(PTRACE_ATTACH, target_pid, NULL, NULL); ptrace(PTRACE_POKETEXT, target_pid, address, shellcode); ptrace(PTRACE_SETREGS, target_pid, NULL, regs); ptrace(PTRACE_CONT, target_pid, NULL, NULL);一个同时具备CAP_SYS_PTRACE且以--pidhost运行的容器可以直接向宿主机 PID 1 注入代码。通过 CAP_NET_ADMIN 操控网络该能力允许修改路由表、防火墙规则与网络命名空间。攻击者可以重定向发往其他容器的流量、建立隧道外传数据、篡改 iptables 规则绕过网络策略、逃逸到宿主机的网络命名空间。防御策略遵循最小权限原则先丢弃全部能力再按需加回。docker run --cap-dropALL --cap-addNET_BIND_SERVICE nginx这也是 tests/testdata/compose/good-production.yml 中安全示例的推荐做法——该文件展示了cap_drop: [ALL]后仅加回NET_BIND_SERVICE、CHOWN、SETGID、SETUID的合规配置可作为生产 compose 的对照范本。Namespace Isolation什么是Linux namespaces 为系统资源提供相互隔离的独立视图。处于不同命名空间的进程看到的是各自不同的 PID 集合、网络接口、挂载点、IPC 对象、主机名、用户与 cgroup。Docker 默认为每个容器创建 6 种命名空间PID namespace隔离进程 ID容器内看不到宿主机进程Network namespace隔离网络接口、路由与防火墙规则Mount namespace隔离文件系统挂载点IPC namespace隔离 System V IPC 与 POSIX 消息队列UTS namespace隔离主机名与域名User namespace隔离用户与组 ID可选默认不启用为什么重要与宿主机共享命名空间就等于打破这一层隔离边界。--pidhost让容器能看到宿主机全部进程若叠加CAP_SYS_PTRACE便可向其注入代码而最危险的是--nethost它把容器直接放到宿主机网络栈上容器可以绑定宿主机任意端口、嗅探全部流量并重新配置宿主机的网络。底层工作原理内核为每种命名空间维护一个命名空间 inode进程通过 inode 归属到对应命名空间。/proc/PID/ns/目录以符号链接方式暴露这些 inode$ ls -l /proc/self/ns/ lrwxrwxrwx 1 user user 0 Jan 31 12:00 pid - pid:[4026531836] lrwxrwxrwx 1 user user 0 Jan 31 12:00 net - net:[4026531840]不同命名空间中的容器其 inode 编号不同这正是审计工具可以判断「容器是否与宿主机共享命名空间」的基础。在 internal/analyzer/container.go 的checkNamespaces中docksec逐一检查NetworkMode、PidMode、IpcMode、UTSMode是否为host并分别映射到 CIS 5.9HIGH、5.15HIGH、5.16HIGH、5.20MEDIUMif info.HostConfig.NetworkMode host { control, _ : benchmark.Get(5.9) f : finding.New(CIS-5.9, control.Title, finding.SeverityHigh, target) findings append(findings, f) }Kubernetes 清单也经常犯同样的错误spec: hostNetwork: true # Shares host network namespace hostPID: true # Shares host PID namespace containers: - name: monitor image: debug-tools常见攻击通过 --pidhost 发现宿主机进程共享宿主 PID 命名空间后攻击者可以枚举宿主机全部进程、寻找敏感服务并确定攻击目标还能读取/proc/*/environ窃取环境变量中的秘密# Inside container with --pidhost ps aux | grep -i password ls -la /proc/*/environ | xargs grep -a SECRET这会暴露进程的命令行、环境变量与打开的文件描述符。通过 --nethost 嗅探网络在宿主机网络命名空间内容器可以运行抓包工具截获发往其他容器或宿主机的流量tcpdump -i eth0 -w capture.pcap # Exfiltrate capture.pcap later这完全绕过了 Docker 的网络隔离。防御策略生产环境绝不共享宿主命名空间。项目在 internal/analyzer/container.go 中把所有共享命名空间配置都标记为对应严重性if info.HostConfig.PidMode host { // Creates HIGH severity finding for CIS 5.15 } if info.HostConfig.IpcMode host { // Creates HIGH severity finding for CIS 5.16 }调试时应使用docker exec在容器自身命名空间内运行工具而不是共享宿主机的命名空间。Security ProfilesSeccomp、AppArmor、SELinux什么是安全配置文件在传统 Unix 权限之上实施强制访问控制SeccompSecure Computing Mode使用 BPFBerkeley Packet Filter程序过滤系统调用可拦截ptrace()、mount()、reboot()等危险 syscall。AppArmor基于路径规则限制文件访问例如允许读取/etc/nginx/但只允许向/var/log/nginx/写入。SELinuxSecurity-Enhanced Linux基于类型type实施强制访问控制使用类似system_u:object_r:httpd_sys_content_t:s0的安全上下文控制访问。为什么重要缺少这些配置文件时被攻陷的容器拥有完整的系统调用访问权可以尝试各种容器逃逸手法。Docker 默认 seccomp 配置文件能拦截约 44 个危险系统调用但容器仍可能以--security-opt seccompunconfined运行彻底放弃这一层防护。底层工作原理Docker 默认应用一个 seccomp 配置文件除非显式覆盖。配置文件是定义允许 syscall 的 JSON 文件{ defaultAction: SCMP_ACT_ERRNO, architectures: [SCMP_ARCH_X86_64], syscalls: [ { names: [read, write, open], action: SCMP_ACT_ALLOW } ] }docksec在 internal/analyzer/container.go 的checkSecurityOptions中解析SecurityOpt列表分别跟踪 AppArmor、seccomp 与 no-new-privileges 的状态for _, opt : range info.HostConfig.SecurityOpt { if strings.HasPrefix(opt, apparmor) { hasAppArmor true } if strings.HasPrefix(opt, seccomp) { hasSeccomp true if opt seccompunconfined { seccompDisabled true } } if opt no-new-privileges || opt no-new-privileges:true { hasNoNewPrivileges true } }AppArmor 配置文件是/etc/apparmor.d/下的文本文件例如profile docker-default flags(attach_disconnected,mediate_deleted) { deny {PROC}/* w, deny /sys/[^f]*/** wklx, capability setuid, }常见陷阱为图方便禁用 seccomp开发者在排障时经常关闭 seccomp 而不理解其风险# Bad: Complete syscall access docker run --security-opt seccompunconfined app # Good: Custom profile with needed syscalls docker run --security-opt seccomp./custom-profile.json app配置文件完全缺失较老版本的 Docker 或某些配置默认不应用配置文件。项目对「显式禁用」和「完全缺失」给出不同严重性——显式禁用对应 CIS 5.21 为 HIGH缺失则创建 MEDIUM 级别 findinginternal/analyzer/container.goif !hasSeccomp !info.HostConfig.Privileged { // Creates MEDIUM severity finding }防御策略生产环境始终启用安全配置文件从 Docker 默认配置出发、仅在确有必要时定制。项目同时检测缺失与禁用两种情况并给予不同严重性显式禁用 HIGH、缺失 MEDIUM同时检查no-new-privilegesCIS 5.25HIGH与 AppArmor 配置CIS 5.1HIGH。Sensitive Path Mounts什么是Bind mount 把宿主机目录或文件暴露进容器。某些路径一旦被挂载就相当于把整个宿主机交了出去/var/run/docker.sockDocker 控制接口、/proc进程信息、/整个文件系统。为什么重要Docker socket 是一个接受 Docker API 命令的 UNIX socket。挂载它的容器可以创建新的特权容器从而实现宿主机逃逸# Inside container with /var/run/docker.sock mounted docker run --privileged -v /:/host -it ubuntu chroot /host /bin/bash # Now on the host这正是著名的 Tesla Kubernetes 入侵事件2018 年黑客通过 Kubernetes 控制平面中挂载了 docker.sock 的容器逃逸至 AWS 云的成因。底层工作原理Bind mount 通过-v或--mount指定Docker API 在容器 Inspect 响应中携带挂载信息{ Mounts: [ { Type: bind, Source: /var/run/docker.sock, Destination: /var/run/docker.sock } ] }docksec在 internal/analyzer/container.go 的checkMounts中把每个挂载源路径与 internal/rules/paths.go共 1181 行维护的危险路径数据库比对for _, mount : range info.Mounts { source : mount.Source if rules.IsDockerSocket(source) { // Creates CRITICAL severity finding (CIS 5.31) } if rules.IsSensitivePath(source) { severity : rules.GetPathSeverity(source) // Creates finding with path-specific severity (CIS 5.5) } }该数据库覆盖的类别包括容器运行时 socketDocker、containerd、CRI-O、Podman、CRI-dockerd、rkt全部标记为 CRITICAL系统目录/proc、/sys、/dev配置目录/etc、/rootKubernetes 敏感目录/var/lib/kubelet、/etc/kubernetes云厂商凭据/root/.aws、/root/.kubeCI/CD 代理数据/var/lib/jenkins、/home/runner每条路径都带有独立的严重性与描述internal/rules/paths.go例如/var/run/docker.sock的严重性为 CRITICAL描述为「Docker daemon socket. Full control over Docker, container escape possible.」查询使用预计算的哈希集合与前缀匹配保证 O(1) 判定。常见攻击Docker socket 逃逸这是最常见的容器逃逸手法只需在容器内运行 Python 脚本即可获得宿主机 root# Python script inside container import docker client docker.from_env() # Uses /var/run/docker.sock # Create privileged container with host filesystem mounted container client.containers.run( ubuntu, chroot /host /bin/bash, privilegedTrue, volumes{/: {bind: /host}}, detachTrue, stdin_openTrue, ttyTrue )通过 /proc 访问进程内存挂载/proc会暴露宿主进程内存。读取/proc/PID/mem可从运行中的进程里提取凭据、SSH 私钥等秘密。通过 /sys 操控内核/sys文件系统暴露内核参数。向/sys/kernel/写入可禁用安全特性、修改 CPU 设置并触发内核漏洞。防御策略除非容器专门提供 Docker-as-a-Service如 CI/CD runner否则绝不挂载 Docker socket即便是这类场景也应优先采用 Docker rootless 模式或 Kaniko 等无需 socket 的构建方案。项目的路径数据库相当全面新增一个危险路径只需在 internal/rules/paths.go 增加一条映射。Secret Detection什么是秘密Secrets是嵌入在 Dockerfile、环境变量或 docker-compose 文件中的凭据包括 API 密钥、密码、私钥、数据库连接串与 token。为什么重要容器镜像中的秘密极易被发现——任何能拉取该镜像的人都能提取出这些秘密docker history image:tag docker inspect image:tag docker run image:tag env2019 年研究人员在 Docker Hub 上发现超过 100,000 个泄露秘密的镜像其中许多是仍在生效的 AWS、GitHub 等服务的 API 密钥。秘密一旦随镜像分发就无法通过撤销单一凭据挽回因为镜像历史与缓存副本会永久留存。底层工作原理docksec采用两种互补的技术进行秘密检测正则模式匹配内置 80 条正则规则定义在 internal/rules/secrets.go完整列表延伸至该文件 1395 行覆盖 AWS、GCP、Azure、GitHub、GitLab、Slack、Stripe、Twilio、SendGrid、Mailgun、npm、PyPI、Docker Hub、Redis、Cloudflare、Sentry、Plaid、Algolia、Cloudinary、Mapbox、Bitbucket、Atlassian、Confluent 等平台{ Type: SecretTypeAWSKey, Pattern: regexp.MustCompile((?i)(AKIA|ABIA|ACCA|ASIA)[0-9A-Z]{16}), Description: AWS Access Key ID, }香农熵分析对不匹配任何已知模式的字符串计算信息熵。随机生成的秘密通常熵很高每字符超过 4.5 bit而普通英文文本熵较低。核心实现位于 internal/rules/secrets.gofunc CalculateEntropy(s string) float64 { freq : make(map[rune]float64) for _, c : range s { freq[c] } length : float64(len(s)) var entropy float64 for _, count : range freq { p : count / length entropy - p * math.Log2(p) } return entropy } func IsHighEntropyString(s string, minLength int, minEntropy float64) bool { if len(s) minLength { return false } return CalculateEntropy(s) minEntropy }两个阈值来自 internal/config/constants.goMinSecretLength 16、MinEntropyForSecret 4.5。IsSensitiveEnvName除了查精确命名的集合外还会对PASSWORD、TOKEN、SECRET、API_KEY、CREDENTIAL等子串做兜底匹配internal/rules/secrets.go。Dockerfile 分析器在 internal/analyzer/dockerfile.go 的checkSecrets中用 BuildKit 前端解析器解析ENV、ARG、RUN、LABEL四条指令对每一行执行三层检测敏感变量名、高熵字符串、正则模式匹配并为每个命中生成带准确行号的 findingif rules.IsSensitiveEnvName(varName) { // Check if variable name looks sensitive } if rules.IsHighEntropyString(varValue, 16, 4.5) { // Check if value has high entropy } secrets : rules.DetectSecrets(line) for _, secret : range secrets { // Create finding for each detected secret type }常见检测模式项目可检测的秘密类型包括AWS 密钥AKIA...、aws_secret_access_key...GitHub tokenghp_...、gho_...Google API 密钥AIza...私钥-----BEGIN PRIVATE KEY-----JWTeyJ...base64 编码的 JSON数据库 URLpostgres://user:passhost/db、redis://:pass...通用模式API_KEY...、PASSWORD...完整的类型清单可查看 internal/rules/secrets.go 中定义的SecretType常量。对 compose 文件internal/analyzer/compose.go 同样会扫描服务环境变量的值。防御策略使用 Docker secrets 或运行时环境变量注入秘密避免在 Dockerfile 与镜像层中固化# Bad: Secret in Dockerfile ENV API_KEYsk-abc123 # Good: Secret from environment docker run -e API_KEYsk-abc123 app # Better: Docker secrets (Swarm) echo sk-abc123 | docker secret create api_key - docker service create --secret api_key app项目同时标记ENV、ARG、RUN指令中的硬编码秘密与高熵字符串对应 CIS 4.10HIGH。tests/testdata/compose/good-production.yml 中的安全示例展示了正确做法环境变量只放NODE_ENV、LOG_LEVEL这类非敏感项db_password与api_key则通过secrets:声明为external: true从外部注入。CIS Docker Benchmark什么是CIS Docker Benchmark 是由互联网安全中心Center for Internet Security发布的共识驱动的 Docker 安全配置指南提供横跨 7 大章节的 100 条控制项Host Configuration主机配置Docker Daemon ConfigurationDocker 守护进程配置Docker Daemon Files and DirectoriesDocker 守护进程文件与目录Container Images and Build Files容器镜像与构建文件Container Runtime容器运行时Docker Security OperationsDocker 安全运维Docker Swarm ConfigurationDocker Swarm 配置每条控制项都有 ID如5.4、标题、描述与修复步骤Remediation并被标记为 scored合规必需或 not scored建议项。为什么重要该基准代表了安全从业者沉淀的行业最佳实践遵循它能预防大量导致入侵的常见错误配置。同时PCI DSS、HIPAA、SOC 2 等合规框架都要求遵循 CIS 基准或同等标准——这正是docksec这类自动化合规检查工具的核心价值所在把人工检查基准的繁琐过程转化为一条 CLI 命令。底层工作原理项目把所有 CIS 控制项注册在 internal/benchmark/controls.go共 1710 行中由init()依次调用 7 个注册函数registerHostControls至registerSwarmControls填充全局注册表。每条控制项包含完整元数据Register(Control{ ID: 5.4, Section: Container Runtime, Title: Ensure that privileged containers are not used, Description: Using --privileged gives all capabilities to the container..., Remediation: Do not run containers with --privileged flag..., Severity: finding.SeverityCritical, Scored: true, Level: 1, References: []string{https://docs.docker.com/engine/reference/run/}, })Control结构体通过ToCISControl()转换为finding.CISControl携带 ID、章节、标题、描述、scored 标记与 level嵌入到每个 finding 中internal/benchmark/controls.go。各分析器通过benchmark.Get(id)获取控制项元数据再创建引用该控制项的 finding。例如 internal/analyzer/container.go 对特权容器的检测control, _ : benchmark.Get(5.4) f : finding.New(CIS-5.4, control.Title, finding.SeverityCritical, target). WithDescription(control.Description). WithCategory(string(CategoryContainerRuntime)). WithRemediation(control.Remediation). WithReferences(control.References...). WithCISControl(control.ToCISControl())结合 README.md 的 CLI 用法扫描时可通过--severity critical,high过滤严重性用--fail-on critical在 CI 中实现「发现 CRITICAL 即非零退出」并通过--format sarif导出 SARIF 报告以便与合规工具对接——SARIF 输出会把 CIS 控制项 ID 作为标签嵌入便于 SIEM、代码扫描平台自动消费。自查练习在进入架构章节前请确认你能回答以下问题为什么CAP_SYS_ADMIN比CAP_NET_RAW更危险两者各自具体能发动什么攻击如果一个容器共享宿主 PID 命名空间但没有特殊能力它是否仍然危险是如何危险的秘密检测为什么需要同时使用模式匹配与熵分析请各举一个只有其中一种方法能捕获的例子。如果这些问题还比较模糊请重读对应小节。先夯实这些基础概念后续实现章节的阅读会顺畅得多。深入阅读必读资料CIS Docker Benchmark v1.6.0PDF——本项目完整实现的标准规范Linux 程序员手册 capabilities(7)——权威的能力文档Docker 官方安全文档——Docker 官方安全最佳实践深入主题NCC Group 白皮书《Understanding and Hardening Linux Containers》——容器内部机制与逃逸技术研究论文《A Measurement Study of Docker Container Configurations on GitHub》——真实世界错误配置的数据支撑内核源码security/capability.c——内核中能力检查的真实实现历史背景ThoughtWorks2014最初的 Docker 安全审计——基准中许多问题的来源Dirty COWCVE-2016-5195——可从容器的内核漏洞runc 漏洞 CVE-2019-5736——通过恶意镜像实现的容器逃逸如果你希望把这些概念落到真实代码上可进一步阅读同项目下的 00-OVERVIEW.md前置条件与快速开始、02-ARCHITECTURE.md系统设计与数据流、03-IMPLEMENTATION.md代码走读与 04-CHALLENGES.md扩展思路与练习通过go run ./cmd/docksec scan或just run-scan即可在本地环境实际体验上述所有检测逻辑的运行效果。赞分享【免费下载链接】Cybersecurity-ProjectsBuilding 70 Projects ranging from beginner to advanced so anyone can — learn from, build upon, use as a reference, or even copy directly. Gamified Cybersecurity learning 项目地址https://gitcode.com/gh_mirrors/cy/Cybersecurity-Projects点击查看免费下载相关推荐6大Linux命名空间深度揭秘runc容器隔离背后的核心原理6大Linux命名空间深度揭秘runc容器隔离背后的核心原理 一句话读懂 Linux 命名空间与 runc runc 是遵循 OCI 规范、负责创建和运云原生容器运行时CLIFirejail命名空间隔离技术深入理解Linux内核安全隔离机制Firejail命名空间隔离技术深入理解Linux内核安全隔离机制 在当今数字化时代 Linux内核安全隔离 机制对于保护系统安全至关重要。Firejail应用安全操作系统深入Apollo核心概念应用、集群与命名空间深入Apollo核心概念应用、集群与命名空间 本文深入解析了Apollo配置中心的核心概念体系包括应用 App 管理的多环境配置隔离机制、集群 Cluste配置中心后端微服务上一篇Pearcleaner基于Swift的macOS应用深度清理与系统优化技术实现方案下一篇Windows 11终极优化指南Win11Debloat一键清理系统垃圾和隐私追踪创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考