util-linux项目中more命令的安全模式增强分析

在类Unix系统中，分页工具是日常运维和开发中不可或缺的组件。作为util-linux项目核心工具之一的more命令，近期因其缺乏安全模式支持而引发了安全社区的关注。本文将深入分析这一安全增强需求的背景、技术实现方案及其系统级影响。

安全背景与问题本质

传统分页工具如more和less在设计时都提供了交互式功能，其中more命令支持通过"!"操作符直接执行shell命令，这在特权环境下会形成显著的安全风险。当具有SUID权限或以root身份运行的应用程序调用more作为默认分页器时，低权限用户可能通过该特性实现权限提升。

这种攻击面在现实环境中确实存在：例如网络管理工具nmcli在less不可用时自动回退到more，而许多系统工具都未对分页器的使用做安全上下文检查。这与当年通过编辑器漏洞提权的历史安全问题具有相似性。

现有解决方案的启示

less命令通过LESSSECURE环境变量率先实现了安全模式，该模式下会禁用所有可能执行外部命令或访问文件系统的功能。systemd项目进一步制定了智能检测机制：当检测到有效用户ID与会话所有者不匹配时，强制启用安全模式且仅允许已知支持安全模式的分页器运行。

这种分层防御策略值得借鉴：

1. 工具自身实现安全模式
2. 调用方进行上下文感知的强制安全策略
3. 环境变量显式控制

more命令的安全增强方案

针对more的安全改造需要从三个层面进行：

核心功能修改

1. 新增MORESECURE环境变量开关
2. 安全模式下禁用"!"命令执行和"v"编辑器调用功能
3. 保留基础分页功能确保向后兼容

系统集成方案

1. 标准化PAGERSECURE通用变量名
2. 与systemd等框架集成实现自动安全模式切换
3. 文档化安全使用规范

防御纵深构建

1. 特权程序应显式指定安全分页器
2. 实现分页器白名单机制
3. 考虑SELinux等MAC系统的策略整合

实施影响评估

此项改进将带来多重积极影响：

• 消除通过more的潜在提权路径
• 推动分页器安全标准统一
• 增强系统整体安全基线

同时需要注意：

• 需要协调各发行版同步更新
• 可能影响依赖原始行为的遗留脚本
• 需要清晰的用户文档说明行为变化

未来演进方向

从长远来看，分页工具的安全设计应该：

1. 实现权限最小化原则
2. 支持细粒度的功能控制
3. 提供完整的审计日志
4. 与容器等新型隔离技术深度集成

此次more命令的安全增强不仅是单个工具的修补，更是推动命令行工具安全范式演进的重要一步。通过建立完善的安全模式和调用规范，可以系统性地降低类Unix系统的攻击面。