3、操作系统安全：内核加固、最小权限原则、SELinux/AppArmor配置

各位好，咱们接着聊小基站的安全防护。前面几章我们把物理安全和网络层面的东西理了一遍，今天要深入到底层——操作系统。说白了，小基站跑的就是一个精简版的Linux系统，如果这个地基不牢，上面盖的楼再漂亮也没用。

我入行那会儿，有个项目让我印象特别深。小基站部署在户外，被人物理接触到了，对方直接插了个U盘进去，通过一个内核漏洞拿到了root权限。嗯，从那以后，我对操作系统安全的重视程度直接拉满。今天咱们就重点聊聊三个核心点：内核加固、最小权限原则、还有SELinux和AppArmor的配置。

3.1 内核加固：把攻击面缩到最小

内核是操作系统的核心，也是攻击者的首要目标。你想想看，一旦内核被攻破，整个系统就裸奔了。我个人习惯，拿到一个新系统，第一件事就是做内核加固。

具体怎么做？ 我列几个关键动作：

• 关闭不必要的内核模块：小基站功能相对固定，不需要像通用服务器那样加载一堆驱动。比如蓝牙、红外、USB存储这些，能关就关。我在项目中遇到过，有人通过加载一个恶意的内核模块直接提权，教训深刻。
• 启用内核安全特性：比如 KASLR（内核地址空间布局随机化）、NX（非执行位）、SMEP/SMAP（内核态禁止执行用户态代码）。这些特性在编译内核时就要打开。
• 限制内核参数：通过 sysctl 调整关键参数。比如禁止IP转发、限制核心转储、禁用Magic SysRq键等。

举个例子，关闭USB存储支持，可以在内核配置里这样操作：

# 在 .config 文件中
CONFIG_USB_STORAGE=n
CONFIG_USB_UAS=n

# 或者通过黑名单模块
echo "blacklist usb_storage" >> /etc/modprobe.d/blacklist.conf

嗯，这里要注意，改完配置后一定要重启验证。我曾经吃过亏，以为配好了，结果系统一跑，模块还是被自动加载了。后来发现是没更新initramfs。

3.2 最小权限原则：不给多余的权利

这个原则说起来简单，做起来难。说白了，就是每个进程、每个用户，只给完成本职工作所需的最小权限。多一点都不给。

为什么这么重要？ 你想想看，如果小基站上的一个网络服务被攻破，但它是以普通用户身份运行的，攻击者能做的事情就非常有限。反过来，如果这个服务跑在root下，那整个系统就完了。

我在实际项目中，见过太多因为权限过大导致的安全事故。比如有个同事，为了方便，把所有服务都跑在root下。结果一个Web服务被注入，攻击者直接拿到了系统控制权。

具体实施建议：

• 创建专用用户：每个服务一个用户，比如 sctp_service、management_service。不要共用同一个用户。
• 文件权限控制：配置文件、日志文件、可执行文件，严格按照 chmod 和 chown 设置。比如配置文件只对所属用户可读。
• 使用Capabilities：Linux的Capabilities机制允许你给一个进程赋予特定的特权，而不需要给它root权限。比如只需要绑定低端端口，就给 CAP_NET_BIND_SERVICE，而不是直接给root。

还有一个容易忽略的点：临时文件。很多服务会在 /tmp 下创建临时文件，如果权限设置不当，可能被其他进程读取或篡改。我建议使用 O_TMPFILE 标志或者将临时文件放在专用目录下。

3.3 SELinux/AppArmor：强制访问控制的利器

传统的Linux权限模型是「自主访问控制」（DAC），说白了就是文件所有者说了算。但这种方式有个问题：如果root用户被攻破，那所有保护都失效了。这时候就需要「强制访问控制」（MAC）出场了。

SELinux和AppArmor就是两种主流的MAC实现。它们的作用是：即使进程以root身份运行，也只能访问被明确允许的资源。

两者有什么区别？ 我简单总结一下：

特性	SELinux	AppArmor
配置复杂度	较高，基于标签（Label）	较低，基于路径（Path）
灵活性	极高，支持细粒度控制	较高，但不如SELinux
学习曲线	陡峭	平缓
适用场景	高安全环境、多策略场景	通用场景、快速部署

我个人建议，如果团队对Linux安全比较熟悉，选SELinux；如果追求快速落地和易维护，AppArmor更合适。小基站项目里，我两种都用过，各有千秋。

3.3.1 SELinux配置要点

SELinux的核心是「策略」。每个进程、每个文件都有一个安全上下文（Context）。策略定义了哪些Context可以访问哪些资源。

举个例子，假设我们有一个小基站的管理服务 bsmgr，我们希望它只能读写 /var/bsmgr/ 目录下的文件，不能碰其他任何地方。

# 1. 创建自定义策略模块
# 使用 audit2allow 工具分析日志，生成策略
ausearch -m avc -ts recent | audit2allow -M bsmgr_policy

# 2. 加载策略
semodule -i bsmgr_policy.pp

# 3. 设置文件上下文
semanage fcontext -a -t bsmgr_data_t "/var/bsmgr(/.*)?"
restorecon -Rv /var/bsmgr/

# 4. 设置进程上下文
semanage permissive -a bsmgr_t  # 先设为宽容模式测试

3.3.2 AppArmor配置要点

AppArmor的配置相对直观，它基于路径。你只需要告诉系统：某个程序可以访问哪些文件、可以执行哪些操作。

还是以 bsmgr 为例，一个简单的AppArmor配置文件长这样：

# /etc/apparmor.d/usr.sbin.bsmgr
#include <tunables/global>

/usr/sbin/bsmgr {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  /var/bsmgr/** rw,
  /var/log/bsmgr.log w,
  /etc/bsmgr/config r,

  # 禁止访问其他目录
  deny /etc/shadow r,
  deny /root/** rw,
  deny /tmp/** rw,
}

配置好之后，加载并启用：

apparmor_parser -r /etc/apparmor.d/usr.sbin.bsmgr
aa-enforce /usr/sbin/bsmgr

嗯，这里有个坑要注意：AppArmor的规则是「白名单」机制，没写的就是禁止。所以一定要把程序正常运行所需的所有路径都列全了。我刚开始用的时候，漏了一个日志目录，结果程序一直报错，排查了半天才发现是AppArmor在默默拦截。

3.4 实战建议：从小处着手

说了这么多，可能有人会觉得：这么多配置，从哪开始？我的建议是：

1. 先做内核加固：关闭不必要的模块，启用安全特性。这一步收益最高，改动也相对安全。
2. 再搞最小权限：把服务从root用户迁出来，用Capabilities替代。这一步可能会影响服务运行，建议在测试环境充分验证。
3. 最后上MAC：SELinux或AppArmor二选一。先在宽容模式跑一周，收集日志，再逐步收紧策略。

好了，这一章的内容就到这里。下一章我们会聊聊通信协议层面的加密实现，包括IPsec和TLS在小基站中的具体配置。到时候见。