linux安全性

Linux 的全性安全性不是靠一个“安全开关”实现的，它更像是全性把权限、隔离、全性审计和补丁流程一层层叠起来。全性最核心的全性一条：默认情况下，普通用户不能随便动系统文件和别人的全性进程。这套东西从 1970 年代延续到现在，全性中间修修补补，全性但骨架没换。全性

先说权限。全性每个文件有属主、全性属组和其他人三组权限，全性读、全性写、全性执行分开控制。全性你登录后拿到一个 uid，内核靠这个 uid 判断你能干什么。root 是 uid 0，它绕过大部分检查，所以拿到 root 就等于拿到整台机器。这也是为什么 sudo 比直接 su 更常见——它按命令授权，还能记日志。但 sudo 配错了照样出事，比如给某个用户 NOPASSWD: ALL，那跟直接给 root 没区别。

权限之外还有能力机制。传统上要么是普通用户，要么是 root，太粗。Linux 把 root 的特权拆成几十种 capability，比如 CAP_NET_BIND_SERVICE 允许绑定 1024 以下端口，CAP_SYS_ADMIN 管挂载和很多系统操作。一个只跑 Web 服务的进程，可以只保留绑定端口的权限，其他全部丢掉。这样即使被攻破，能做的事也有限。

隔离这块，namespaces 和 cgroups 是容器安全的地基。namespaces 让进程看不到别的进程、网络、挂载点；cgroups 限制 CPU、内存、IO。Docker 默认给容器一套独立的 namespace，但默认配置并不“安全”——容器里的 root 和宿主机的 root 映射关系没处理好，就可能逃逸。后来有了 user namespace，可以把容器内的 root 映射成宿主机上的普通用户，这才算把口子收窄了一些。还有 seccomp，限制进程能调用的系统调用，比如禁止 ptrace 或 mount，能挡住不少漏洞利用链。

强制访问控制是另一层。SELinux 和 AppArmor 不走“用户-文件权限”那套，而是给每个进程打标签，规定它能读哪些文件、能连哪些端口。SELinux 在 RHEL 系默认开启，策略很细但也很容易把人逼疯。我见过有人直接 setenforce 0 关掉，然后被入侵时连日志都看不出异常。AppArmor 在 Ubuntu 上更常见，配置简单些，但覆盖范围不如 SELinux 广。

补丁和更新是绕不开的。Linux 内核每年爆几十个 CVE，本地提权、远程代码执行都有。关键不是“有没有漏洞”，而是“多久能修好”。发行版分两种节奏：滚动更新像 Arch，内核版本新但稳定性靠用户自己扛；稳定版像 Debian，补丁回移慢但经过测试。企业环境通常选后者，配合 livepatch 或 kpatch 做内核热修复，避免重启。但热修复只覆盖一部分 CVE，不是万能药。

审计和日志经常被忽略。auditd 能记录文件访问、系统调用、用户登录。配置得当的话，你能看到谁在什么时候改了 /etc/passwd，或者哪个进程试图加载内核模块。但默认规则很少，得自己写。日志本身也要保护，否则攻击者进来第一件事就是删 /var/log。远程 syslog 或者 append-only 文件属性（chattr +a）能挡一下。

最后说个实际观察：很多 Linux 服务器被入侵，不是因为内核漏洞，而是 SSH 配了弱密码、Web 应用有命令注入、或者某个服务以 root 跑着。安全基线工具像 lynis 或 openscap 能扫出这些问题，但扫完不改等于没扫。Linux 给了你足够多的控制点，代价是你得知道每个控制点在哪、怎么用。默认配置能挡住脚本小子，挡不住有针对性的攻击。