在CentOS安全加固和容器化部署场景中，lsns命令是查看Linux命名空间（Namespace）隔离状态最直接、最高效的工具。它能列出当前系统所有进程所属的命名空间类型及编号，帮助运维人员快速判断进程隔离是否到位、容器逃逸风险是否存在、多租户环境是否安全。简单来说，lsns就是你检查"这个进程到底被隔离在哪个命名空间里"的第一步操作，没有它，你对系统隔离状态的判断基本靠猜。
什么是命名空间以及为什么CentOS安全离不开它
Linux命名空间是内核提供的一种资源隔离机制，它让不同进程看到不同的系统视图。主要包括PID命名空间（进程隔离）、NET命名空间（网络隔离）、MNT命名空间（挂载点隔离）、UTS命名空间（主机名隔离）、IPC命名空间（进程间通信隔离）、USER命名空间（用户权限隔离）、CGROUP命名空间（资源控制组隔离）等。CentOS 7及以上版本全面支持这些命名空间，而CentOS 8和Stream版本更是默认集成了容器运行时所需的全部命名空间能力。
在安全加固场景下，命名空间隔离的核心价值在于：限制进程的可见范围，防止恶意进程窥探其他进程的信息、访问不该访问的网络资源或文件系统。如果命名空间配置不当，攻击者可能通过共享命名空间实现横向移动甚至容器逃逸。因此，定期用lsns检查命名空间隔离状态，是CentOS安全运维的基本功。
lsns命令的基本用法和输出解读
lsns命令默认不带任何参数时，会以表格形式输出当前系统所有命名空间的信息。输出列包括：NS TYPE（命名空间类型）、NS（命名空间ID/inode编号）、NPROCS（该命名空间中的进程数）、PID（该命名空间中的一个示例进程PID）、COMM（该进程的命令名）、USER（该进程的属主）。
直接在终端输入：
lsns
你会看到类似如下的输出：
NS TYPE NPROCS PID USER COMMAND 4026531834 cgroup 132 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 22 4026531835 pid 132 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 22 4026531836 user 132 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 22 4026531837 uts 132 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 22 4026531838 ipc 132 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 22 4026531839 mnt 128 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 22 4026531956 net 128 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 22 4026532392 time 132 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 22 4026532393 timens 132 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 22
这段输出告诉你：系统init进程（PID 1）属于多个命名空间，包括cgroup、pid、user、uts、ipc、mnt、net、time等。NPROCS为132说明这些命名空间中各有132个进程。如果某个命名空间的NPROCS异常高或者出现了不该出现的进程，就需要警惕。
按命名空间类型过滤查看
实际运维中，你往往只关心某一种命名空间的隔离情况。lsns支持用-t参数按类型过滤：
lsns -t net
这会只显示网络命名空间的信息。对于容器环境，这非常关键，因为每个容器通常有独立的网络命名空间。如果你发现某个容器进程和宿主机进程共享了同一个NET命名空间（NS编号相同），说明网络隔离失效了。
其他常用过滤类型：
lsns -t pid # 查看进程ID命名空间 lsns -t mnt # 查看挂载命名空间 lsns -t user # 查看用户命名空间 lsns -t ipc # 查看IPC命名空间 lsns -t uts # 查看主机名命名空间 lsns -t cgroup # 查看cgroup命名空间
查看指定进程的命名空间归属
lsns还支持通过-p参数指定进程PID，查看该进程属于哪些命名空间：
lsns -p 1234
这会列出PID为1234的进程所关联的所有命名空间。在安全审计中，你可以针对可疑进程执行这个命令，判断它是否被正确隔离。比如一个Web服务进程如果出现在宿主机的NET命名空间中而非独立的容器网络命名空间，就存在安全隐患。
也可以反过来，通过--nowrap参数让输出更易读：
lsns -p 1234 --nowrap
结合/proc文件系统深入分析命名空间
lsns的数据来源本质上是/proc目录下的命名空间信息。每个进程的/proc/[PID]/ns/目录下存放着该进程所关联的命名空间符号链接。你可以手动查看：
ls -la /proc/1234/ns/
输出类似：
lrwxrwxrwx 1 root root 0 Jun 10 10:00 cgroup -> 'cgroup:[4026531834]' lrwxrwxrwx 1 root root 0 Jun 10 10:00 ipc -> 'ipc:[4026531838]' lrwxrwxrwx 1 root root 0 Jun 10 10:00 mnt -> 'mnt:[4026531839]' lrwxrwxrwx 1 root root 0 Jun 10 10:00 net -> 'net:[4026531956]' lrwxrwxrwx 1 root root 0 Jun 10 10:00 pid -> 'pid:[4026531835]' lrwxrwxrwx 1 root root 0 Jun 10 10:00 pid_for_children -> 'pid:[4026531835]' lrwxrwxrwx 1 root root 0 Jun 10 10:00 user -> 'user:[4026531836]' lrwxrwxrwx 1 root root 0 Jun 10 10:00 uts -> 'uts:[4026531837]'
方括号中的数字就是命名空间的inode编号，和lsns输出中的NS列对应。如果两个进程的某个命名空间inode编号相同，说明它们共享该命名空间，隔离未生效。
CentOS安全加固中命名空间检查的实战要点
在CentOS安全基线检查中，命名空间隔离的验证是重要一环。以下是几个关键检查点：
第一，检查容器进程是否拥有独立的PID命名空间。容器内进程不应该看到宿主机的进程列表。执行lsns -t pid，确认容器进程的PID命名空间inode与宿主机init进程不同。
第二，检查网络命名空间隔离。容器的网络栈应该完全独立，不能与宿主机共享NET命名空间。用lsns -t net逐一核对每个容器进程。
第三，检查USER命名空间。如果容器使用了非root用户运行，应该有独立的user命名空间，确保容器内的root用户映射到宿主机的非特权用户。lsns -t user可以快速验证这一点。
第四，检查MNT命名空间。容器的文件系统挂载点应该与宿主机隔离。lsns -t mnt能帮你确认容器进程是否拥有独立的挂载视图。
第五，关注NPROCS异常值。如果某个命名空间的进程数突然激增，可能意味着有进程逃逸或命名空间被错误共享。
使用lsns排查容器逃逸和安全事件
当CentOS系统上发生安全事件时，lsns是事件响应的重要工具。假设你发现某个容器进程异常访问了宿主机文件系统，第一步就是用lsns -p [容器进程PID]查看它的mnt命名空间。如果发现它的mnt inode和宿主机init进程相同，说明挂载隔离被突破，需要立即排查容器运行时配置和内核安全模块。
另一个常见场景：容器内进程能看到宿主机所有进程。用lsns -t pid检查，如果容器进程的PID命名空间inode与宿主机相同，说明PID隔离失效，攻击者可能利用此信息进行进一步攻击。
# 快速排查脚本示例：检查所有容器进程的命名空间隔离状态
for pid in $(pgrep -f containerd); do
echo "=== PID $pid 命名空间 ==="
lsns -p $pid --nowrap
done
lsns与其他安全工具的配合使用
lsns不是孤立工具，在CentOS安全体系中需要和其他命令配合：
配合ps命令：ps -eo pid,ns,cmd可以列出进程及其命名空间信息，但不如lsns直观全面。
配合ip netns：查看网络命名空间的具体配置，如IP地址、路由表等。
配合cat /proc/[PID]/status中的NSpid字段：可以看到进程在各个命名空间中的PID映射关系。
cat /proc/1234/status | grep NSpid
配合systemd-run：可以创建带有指定命名空间的临时进程进行隔离测试。
systemd-run --scope --slice=test.slice --property=PrivateTmp=true /bin/bash
CentOS不同版本中lsns的差异和注意事项
CentOS 7默认自带util-linux包中的lsns命令，但部分老版本可能需要手动安装：yum install util-linux。CentOS 8和Stream版本中lsns功能更完善，支持更多命名空间类型的显示，包括time和timens命名空间。
需要注意的是，lsns只能查看当前系统已加载的命名空间。如果某个命名空间没有任何进程关联，它不会出现在lsns输出中。但你仍然可以通过/proc/[PID]/ns/目录下的符号链接来间接确认其存在。
另外，在使用容器时，容器运行时（如Docker、Podman）会自动创建和管理命名空间。lsns看到的是运行时创建后的最终状态。如果你需要在容器创建前预设安全策略，需要结合seccomp、AppArmor或SELinux等机制，而不仅仅依赖命名空间。
命名空间隔离失效的常见原因和修复建议
在实际CentOS环境中，命名空间隔离失效通常有以下几个原因：
一是容器运行时配置错误，比如Docker启动时使用了--net=host或--pid=host参数，直接禁用了网络或PID隔离。修复方法是检查容器启动参数，移除这些共享宿主机命名空间的选项。
二是内核模块未加载或内核版本过低。某些命名空间特性需要特定内核版本支持。CentOS 7的3.10内核对命名空间支持有限，建议升级到CentOS 8的4.18内核或更高。
三是用户命名空间未正确配置。/etc/subuid和/etc/subgid文件需要正确设置用户ID映射范围，否则user命名空间无法正常工作。
四是特权容器运行。以--privileged模式启动的容器会获得几乎所有宿主机能力，命名空间隔离形同虚设。安全加固时应严格禁止特权容器。
修复后，务必用lsns重新验证所有关键进程的命名空间状态，确保隔离恢复正常。
总结：lsns是CentOS安全运维的必备命令
lsns命令虽然简单，但在CentOS安全加固和容器安全管理中扮演着不可替代的角色。它让你用一条命令就能看清系统命名空间的全貌，快速发现隔离漏洞。建议将lsns纳入日常安全巡检脚本，定期执行lsns -t net、lsns -t pid、lsns -t mnt等检查，配合自动化告警机制，第一时间发现命名空间隔离异常。对于使用容器的CentOS服务器，更应该把lsns作为容器安全审计的标准动作，做到每次部署后验证、每次事件后排查、每次加固后确认。
