一个没打补丁的统管sudo，能让普通用户直接拿到root shell。理的漏洞里CVE-2021-3156（Baron Samedit）就是表现活生生的例子——攻击者不需要知道root密码，一条命令就能提权。统管这类漏洞不是理的漏洞里偶发，而是表现Linux系统管理中最常见的破口：权限边界被击穿，往往源于一个配置疏忽或一个未修复的统管已知缺陷。

权限管理是理的漏洞里漏洞重灾区。很多管理员图省事，表现直接给用户配NOPASSWD: ALL，统管或者把服务账户加到sudo组。理的漏洞里更隐蔽的表现是SUID文件——一个被错误设置SUID位的脚本，或者一个老版本的统管pkexec，就能让本地用户翻盘。理的漏洞里PwnKit（CVE-2021-4034）在polkit的表现pkexec里藏了十几年，利用起来只需几秒，影响几乎所有主流发行版。问题出在哪？管理员很少定期审计SUID文件，也不追踪polkit这类“基础组件”的CVE。系统装完就默认跑着，直到被利用。

内核漏洞同样致命。Dirty Pipe（CVE-2022-0847）允许普通用户覆写只读文件，直接改/etc/passwd加个root账户。Dirty COW更早，影响范围从Android到服务器。内核漏洞的麻烦在于：不打补丁，提权门槛极低；打补丁，又可能影响业务连续性。于是很多生产环境选择“先扛着”，结果扛出了事故。我见过一台跑了三年没重启的CentOS 7，内核还是3.10.0-327，Dirty COW的补丁压根没进。管理员说“重启会影响交易”，可攻击者不需要你重启——他直接利用漏洞拿root。

配置错误比漏洞更普遍。SSH允许root直接登录、密码认证开着、端口22暴露公网——这三条凑一起，基本等于把门钥匙插在锁上。fail2ban能挡一阵，但挡不住分布式爆破。更糟的是，有些管理员把SSH密钥生成后私钥权限设成644，或者把authorized_keys放在可写目录。还有防火墙规则：iptables默认策略设成ACCEPT，然后只加了几条DROP规则。顺序一错，全盘放行。SELinux呢？很多人第一件事就是setenforce 0，然后改配置文件永久禁用。理由永远是“它挡了业务”。可SELinux挡住的恰恰是提权后的横向移动——你关掉它，等于拆了最后一道围栏。

日志和监控的缺失让漏洞利用变得无声无息。一个被提权的系统，/var/log/auth.log里可能只有一条“session opened for user root”，而真正的攻击命令被清除了。管理员不配auditd，不监控SUID文件变化，也不看cron里多了什么。我见过一个挖矿木马，通过Redis未授权访问写入cron，跑了两个月才被发现——因为管理员从没检查过/var/spool/cron。漏洞利用后的持久化，往往比漏洞本身更值得警惕。

补丁管理是另一个烂摊子。不是所有系统都能yum update -y。有些跑着定制内核，有些依赖老版本glibc，一升级就崩。于是管理员选择“只打安全补丁”，可怎么筛选？Red Hat的OVAL、Ubuntu的USN，真正跟的人不多。更现实的是：很多内网机器根本连不上外网仓库，补丁靠手动拷贝rpm包，版本还对不上。一个心脏出血（Heartbleed）出来时，我帮人查过一批服务器，OpenSSL版本五花八门，有的甚至还在用0.9.8。问就是“业务不能停”。

容器和云环境把问题放大了。Docker默认配置下，容器里的root和宿主机的root只隔了一层namespace。如果挂载了/var/run/docker.sock，或者用了--privileged，逃逸就是分分钟的事。Kubernetes的RBAC配错，一个ServiceAccount就能列出所有secret。这些不是Linux内核的漏洞，是管理漏洞——但后果一样：攻击者拿到集群控制权，然后横向到所有节点。

说到底，Linux系统管理的漏洞不在系统本身，而在人。默认配置不安全，但改配置的人不懂；补丁存在，但打补丁的人怕出事；日志在记，但看日志的人不看。技术债堆到一定程度，一个CVE就能引爆。别等被提权了才去查sudo -l，别等被挖矿了才去看cron。漏洞就在那里，不动它，它不会自己消失。