Linux怎么限制普通用户权限 Linux下Restricted Shell详解

Linux怎么限制普通用户权限 Linux下Restricted Shell详解

rbash 启动后为什么 cd 报错？

很多朋友第一次接触受限Shell（Restricted Shell）时，都会遇到一个直观的困惑：为什么一执行cd命令就报错？提示往往是bash: cd: restricted。

这其实不是目录权限的问题，而是Shell自身在“使绊子”。当rbash启动后，它会直接拦截cd这个内置命令的调用路径。换句话说，无论你想切换到上级目录（cd ..）还是绝对路径（cd /tmp），都会被一概拒绝。这是一种由内而外的限制机制。

那么，这个限制是怎么触发的呢？关键在启动方式。无论是通过bash -r参数启动，还是直接调用名为rbash的软链接（比如/bin/rbash），效果都一样。Shell会检查$0（当前程序名）的basename，如果名字是“rbash”，就自动进入受限模式。这也意味着，如果你自己创建一个叫mybash的软链接，它是不会触发限制的。

• 如何验证？ 运行shopt restricted_shell，如果看到输出restricted_shell on，就说明受限模式已经生效。
• 一个常见的误解是以为登录后可以用set -r手动开启限制。实际上，这个模式只能在Shell初始化时启用，运行时设置是无效的。
• 虽然cd被禁了，但像pwd、ls这样的命令依然可用。不过，前提是这些命令必须位于$PATH环境变量所包含的路径中，并且调用时不能包含斜杠（/）。

用户能运行哪些命令由什么决定？

受限Shell下，用户能执行什么命令，并不是靠某个神秘的白名单配置文件来决定的。真正的规则，藏在$PATH和命令的调用方式里。

核心限制就一条：禁止执行任何包含斜杠（/）的路径。这意味着，像/bin/ls、./my_script.sh或者~/bin/command这样的调用方式会全部失败。系统只允许你使用不带斜杠的命令名，例如直接输入ls。当然，这个ls命令本身必须能在$PATH所定义的搜索路径里找到对应的可执行文件。

基于这个机制，常见的部署策略是为受限用户创建一个专属的、高度可控的命令目录。比如，在用户家目录下建立一个.bin文件夹（/home/user/.bin），里面只放置允许执行的命令的软链接。然后，将用户的$PATH环境变量修改为只包含这个目录。

export PATH="/home/user/.bin"

这个方案听起来简单，但有几个细节必须卡死：

• 软链接必须由root创建：例如，sudo ln -s /bin/ls /home/user/.bin/ls。不能让用户有自己添加链接的权限。
• 配置文件权限必须收紧：用户用于初始化环境的文件（如.profile或.bash_profile）必须由root掌控所有权和权限：chown root:root .profile && chmod 755 .profile。否则，用户一旦能修改这些文件，就能随意篡改PATH，限制形同虚设。
• 注意.bashrc的读取规则：默认情况下，rbash不会自动读取~/.bashrc文件。除非你在.profile里显式地使用source命令去加载它，否则里面的设置不会生效。

为什么用户还能逃出 rbash？常见绕过点在哪？

必须清醒地认识到，rbash并非一个滴水不漏的沙箱，它只是一层轻量级的限制外壳。只要用户能够执行某个程序，而这个程序又恰好提供了调用外部Shell或执行系统命令的功能，就很可能成为逃逸的突破口。

最经典的“后门”就是那些支持交互式命令的工具，比如vim、less、man、ftp甚至gdb。它们通常内置了一个!命令，用于执行系统命令。例如，如果用户被允许运行vim，那么他只需要在vim中输入:!sh或:!/bin/bash，瞬间就能获得一个不受限制的完整Shell。

因此，在配置完成后，进行一次彻底的安全检查至关重要：

• 盘点可用命令：先echo $PATH查看路径，然后逐一检查这些路径下有哪些二进制文件（ls -l）。
• 测试重定向限制：执行echo test > file，看看是否能成功创建文件。如果成功，说明输出重定向的限制可能未生效或被绕过了。
• 警惕脚本解释器：检查用户是否能访问python、perl、awk等。一行像python -c “import os; os.system(‘/bin/sh’)”的代码就是极高风险的信号。
• 审查sudo权限：运行sudo -l查看用户是否有免密码执行某些命令的权限。如果输出显示用户可以无密码运行sudo /bin/bash，那所有的Shell限制都将在一瞬间被绕过。

rbash 适合什么场景？不适合什么？

那么，rbash到底该用在什么地方？它的定位其实很明确。

它适合那些短期、低信任度的访问场景。比如，给外包人员一个临时账号，只允许其查看特定的日志文件；为教学实验室的学生提供一个受控的实验环境；或者给持续集成（CI）系统使用的构建账号。在这些情况下，rbash的优势在于成本极低、无需部署额外服务、基本上开箱即用。

但它绝对不适合作为生产环境核心权限隔离的解决方案。它的限制机制相对表层，很容易被系统中已有的各种工具链（如上述的编辑器、解释器）绕过。更重要的是，它无法防范进程间通信、内存读取、ptrace调试注入等更深层次的系统行为。

当真正需要强隔离时，目光应该转向更专业的方案，例如systemd --scope、cgroups v2、firejail，或者直接使用容器技术。可以说，rbash更像是一个“礼貌性的围栏”，用于标识边界和阻止无心之失，但它绝不是一道坚固的“防火墙”。

最后，还有一个极其关键却常被忽略的点：rbash用户的家目录（$HOME）本身必须设置严格的权限。如果用户能够写入/home/user/.bash_profile，他就可以覆盖PATH或注入任意启动命令；如果用户能够修改/home/user/.ssh/authorized_keys文件，他甚至可能通过配置特定的SSH密钥，在登录时直接绕过受限Shell。这些文件系统的权限，是与Shell限制相辅相成的最后一道防线。