操作系统安全：从隔离机制到持续加固

操作系统位于应用与硬件之间：它分配内存、调度进程、解释文件权限、暴露系统调用并管理设备。应用自己的授权再严密，一旦内核、启动链或管理账户失守，攻击者仍能从更低层绕过它。系统安全因此不是一组开关，而是贯穿规划、安装、配置、测试、维护与恢复的生命周期。

信任边界与安全规划

系统由硬件、固件、启动加载器、内核、驱动、系统服务和用户应用叠成。下层可观察或控制上层，因此固件被篡改时，仅重装应用不够；内核被攻破时，进程级访问控制也不再可信。可信计算基 TCB 是执行某项安全策略所不可缺少的组件集合，应尽量小、不可绕过、受保护且可验证。

部署前先回答：系统提供什么服务、保存何种数据、有哪些用户与管理者、怎样认证、能访问哪些外部资源、可接受的停机与恢复目标是什么。由此得到软件清单、端口清单、账户模型、网络区、日志与备份要求。安全基线必须与用途对应，不能把桌面默认配置直接复制到数据库服务器。

构建过程本身也有风险。未修补的新系统一连公网就可能在加固前被利用，应在隔离网络中安装，验证镜像与驱动完整性，先修补再开放业务流量。启动介质顺序、固件配置、磁盘加密和恢复密钥同样属于规划范围。

进程、地址空间与内存保护

CPU 在用户态执行普通进程，在内核态执行特权代码。进程不能直接操作设备或任意物理内存，只能经系统调用进入内核；内核验证参数、权限和对象状态后代为执行。系统调用、驱动与文件格式解析器因此是高价值攻击面。

每个进程看到独立虚拟地址空间。页表把虚拟页映射到物理页，并附读、写、执行和用户/内核权限；内存管理单元在每次访问时执行检查。只读代码页阻止覆盖，不可执行数据页阻止直接执行注入字节，用户页不能触达内核映射。共享内存必须显式建立并配置权限，因为它有意跨越默认隔离。

缓冲区越界、释放后使用、整数溢出和竞态可能让进程在自己的地址空间内破坏控制数据，继而借系统调用或内核漏洞提权。ASLR 随机化代码与库位置，栈保护值检测返回地址附近破坏，W^X/DEP 避免同一页同时可写可执行，CFI 约束间接跳转。它们提高利用成本，却不能替代边界检查和内存安全语言；信息泄露可削弱随机化，代码复用可绕过单纯不可执行保护。

权限、身份与提权边界

最小权限要求用户、服务与任务只获得完成工作所需的对象权限和特权。日常账户不应长期持有管理员权；提升应短时、可审计并要求重新认证。服务使用独立身份，避免多个应用共享一个高权限账户，否则一项服务被攻破就继承全部能力。

Unix 风格权限以所有者、组和其他用户的读写执行位为基础，并可用 ACL 扩展。目录的读、写、执行含义与普通文件不同：写目录往往允许创建或删除条目，即使文件本身只读。setuid/setgid 使程序以文件所有者或组身份运行，功能强但风险高；输入、环境变量、文件描述符、搜索路径和竞态都必须严格处理。

Windows 风格访问控制把身份映射到安全标识，由对象 ACL 决定允许与拒绝，并另有系统级特权与完整性级约束。无论平台，授权检查都要覆盖真实访问对象，不能只检查用户界面。水平越权跨到同级其他身份，垂直提权则从普通身份获得管理员或内核能力。

系统加固：减少能被攻击的东西

加固从最小安装开始：只装业务必需包，删除或禁用无用服务、协议、示例账户与默认凭据；关闭不必要端口；限制远程管理入口；为守护进程配置资源上限。每减少一个解析器、监听端口或高权限后台服务，就少一条潜在利用路径。

补丁管理要同时覆盖操作系统、驱动、第三方运行库与应用。普通终端可快速自动更新；高可用系统应先在代表性环境验证，再分批部署并准备回滚，但“需测试”不能成为无限延期借口。资产清单与版本清单决定是否能知道哪里需要修补。

额外控制包括主机防火墙、恶意软件防护、应用允许列表、强制访问控制、磁盘加密、USB/设备限制和入侵检测。配置后必须测试：扫描开放端口、审查服务身份、验证禁止路径、重启后复核状态，并保存可比较的基线。

应用、密钥、日志与备份

操作系统加固完成后仍要逐项配置应用：更改默认账户与示例内容，收紧文件和数据库权限，启用 TLS，保护私钥，限制管理接口，确保临时文件不会泄露。密钥不应与密文放在同一无保护位置；证书更新、吊销与恢复都要进入运维流程。

日志是侦测与调查证据，不是预防本身。应记录认证、权限变化、策略修改、服务启动、异常退出和关键业务事件，统一时间，集中传输并限制修改。日志级别过低看不见攻击，过高会淹没信号或记录秘密；必须轮转、归档、监控容量并为重要模式告警。

备份要覆盖配置、数据、密钥材料和恢复文档，采用隔离或不可变副本，控制读取权限并定期实际恢复。能成功“生成备份”不等于能在目标时间内恢复。安全事件后还要确认备份未携带后门，恢复点早于入侵且凭据已轮换。

Linux、macOS 与 Windows 的落地要点

Unix/Linux 系统应维护包与内核更新，审查 /etc 下服务配置、账户与组，禁用不必要的 root 远程登录，以密钥和受限 sudo 执行管理任务。文件权限、扩展 ACL、服务单元沙箱、能力拆分、主机防火墙、集中日志与轮转共同构成基线。chroot 只改变进程看到的文件系统根，不隔离内核、网络或特权，不能当完整沙箱。

macOS 同样依赖用户/组、POSIX 权限与 ACL，并有代码签名、系统完整性保护、应用沙箱与隐私权限。关闭平台保护来解决兼容问题会显著扩大 TCB 与持久化能力，应先找最小授权方案。

Windows 使用安全标识、访问令牌、对象 ACL、用户账户控制与完整性级。系统级特权可能绕过普通对象权限，应只授予专用管理身份。更新服务、应用控制、磁盘加密、主机防火墙、事件日志和端点防护需要统一策略；注册表与组策略变更同样应审计和回滚。

容器、虚拟机与隔离选择

容器通过命名空间隔离进程、挂载、网络和身份视图，用控制组限制资源，但所有容器共享主机内核。虚拟机为每个客户系统提供虚拟硬件与独立内核，由虚拟机监控器仲裁物理资源，隔离通常更强但开销与管理复杂度更高。

容器风险包括特权容器、危险设备挂载、主机套接字暴露、过宽能力、共享内核漏洞和镜像污染。应使用最小镜像、非 root 用户、只读根文件系统、能力删除、系统调用过滤、资源限额和签名扫描。虚拟化风险包括客户机逃逸、监控器漏洞、虚拟网络盲区、快照泄密、休眠镜像未修补以及管理平面被接管。

隔离强度要匹配租户不信任程度。来自相互不信任客户的工作负载不宜只靠默认容器边界；无论选哪种技术，宿主、监控器、镜像、客户系统和管理接口都要修补，日志与备份也要覆盖虚拟基础设施。

权限与只读映射

我们在沙盒环境中创建了临时文件测试。真实输出如下：

uid_gid=501:20
umask=022
mode=-rw-r----- owner=zhengxiaohu group=staff
readonly_map= ABCD
write_to_readonly= TypeError
sandbox_exec=available

当前进程以普通用户 501 和组 20 运行，并非 root。默认 umask 为 022，实验随后显式把临时文件设为 0640，得到“所有者读写、组只读、其他用户无权限”。Python 将四字节文件建立只读内存映射，读取成功；尝试写入被运行时拒绝并抛出 TypeError，说明只读映射没有提供写路径。系统还存在沙箱执行工具，但可用不等于所有进程已自动进入沙箱，策略仍需显式配置与验证。

实践时不要用真实敏感文件测试，也不要为了“看是否能提权”执行不受信 exploit。安全实验应优先验证拒绝路径、权限位、资源限制和隔离可见性，并在临时目录或一次性环境中完成。

持续维护、可信执行

系统上线不是加固结束。维护闭环包括监控日志、修补新漏洞、复核配置漂移、轮换密钥、扫描基线、演练备份恢复和处理事件。变更必须有责任人、测试、批准和回滚；自动化能减少遗漏，但错误模板也会同时复制到所有主机，因此需要分批发布与独立验证。

参考监控器思想要求每次主体到客体访问都经过检查、检查机制自身受隔离并且足够小以便验证。可信启动与平台度量可证明启动组件处于某个已知状态，密封存储可把密钥绑定到平台状态；但“已知版本”不等于“无漏洞”，它们补充而不是替代补丁、最小权限和运行时检测。

最终可以用一条证据链验收：资产与用途明确；构建镜像可验证；服务和端口最少；账户与权限符合任务；内存和执行保护启用；容器/虚拟机边界匹配威胁；日志能发现异常；备份可恢复；更新与事件流程持续运行。任何一项只停留在文档上，都还不能算有效控制。