提升业务系统隔离性需依托LSM策略与服务上下文强绑定：SELinux适用于强管控场景，AppArmor适合容器环境，Landlock用于轻量动态隔离；须以最小权限明确禁止非必要路径、网络行为、危险系统调用及IPC资源；需配合内核防护机制（如禁用模块加载、ASLR、SUID core dump限制）及上层机制（命名空间、cgroups、seccomp）实现纵深防御。
要提升特定业务系统服务的隔离性，核心不是堆砌模块，而是让内核安全扩展（LSM）真正约束服务的运行边界——包括它能访问哪些资源、能调用哪些系统行为、能与谁通信。这需要策略与服务上下文强绑定，而非泛泛启用。
按服务特征选对LSM类型
不同模块解决隔离问题的路径不同，选错会事倍功半：
-
SELinux：适合金融、政务等强管控场景。它基于“域-类型”模型，能把Nginx、Redis、Java网关分别划入独立域（如
web_service_t、cache_service_t），并禁止跨域文件访问、进程派生和端口混用； -
AppArmor：更适合Web应用、微服务或容器环境。它以路径为中心写策略，例如限制某API服务二进制仅能读
/etc/myapp/conf.d/、写/var/log/myapp/、连接127.0.0.1:5432，其余一概拒绝； -
Landlock（Linux 5.13+）：轻量、无特权、可动态启用。适合临时提权组件（如认证代理、日志转发器），能为单个进程设置只读
/etc/passwd、禁止openat()打开/tmp下任意文件，且普通用户即可调用。
用最小权限定义服务边界
隔离失效往往源于策略太宽。关键不是“允许什么”，而是明确“禁止什么”：
- 禁止非必要路径访问：如Nginx策略中禁用
/tmp/** wk,、/bin/sh Px,，防止上传脚本被执行； - 限制网络行为：用
network inet stream,配合capability net_bind_service，只放行80/443端口监听，拒绝UDP或高危端口（如22、3306）； - 阻断危险系统调用：在SELinux中禁用
sys_admin能力，在AppArmor中拦截ptrace、memfd_create、prctl(PR_SET_MM)，防调试注入与内存篡改； - 隔离IPC资源：通过命名空间+LSM联合控制，确保Redis不能访问其他服务的共享内存段或信号量键值。
结合内核机制收紧底层执行环境
LSM策略需依赖内核基础防护才能落地，否则容易被绕过：
- 关闭模块加载：
kernel.modules_disabled = 1，防止攻击者用恶意ko绕过AppArmor限制； - 启用地址空间随机化与执行保护：
kernel.randomize_va_space = 2、kernel.kptr_restrict = 2、确认/sys/cpu/kernel/smap返回1，让ROP利用难度陡增； - 禁用SUID core dump：
fs.suid_dumpable = 0，避免服务崩溃时泄露密钥或令牌； - 强制只读内核代码段：
CONFIG_STRICT_KERNEL_RWX=y（编译时配置），防止PAM模块或内核驱动被运行时篡改。
与上层隔离机制协同验证
LSM不是孤岛，需与命名空间、cgroups、seccomp形成纵深：
- 在容器中，用
docker run --security-opt apparmor=myapp-profile将AppArmor策略绑定到单个容器实例； - 为关键服务进程设置独立user namespace + cgroup v2 memory.max，再叠加SELinux域，实现资源、权限、行为三重隔离；
- 用seccomp-bpf过滤系统调用（如禁用
mount、chroot），再由LSM检查剩余调用的上下文合法性，避免策略重叠或冲突。
