我正在强化服务器并尝试构建一个限制层，以阻止潜在的黑客甚至以服务器的 root 权限造成危害。
如果用户通过 ssh 等方式获得 root 或用户对 shell 的访问权限，那么除了通过可用的 shell 命令之外，用户还有其他方式可以访问系统命令吗？虽然cd是内置命令，但无法轻易删除，因为 bash shell 本身会执行该命令，请参见:(https://unix.stackexchange.com/questions/11454/what-is-the-difference-between-a-builtin-command-and-one-that-is-not） 看：（https://unix.stackexchange.com/questions/38808/why-is-cd-not-a-program),如果ls和ps在服务器上被禁用，入侵者是否有其他方式来发出系统命令？
假设系统上的安全复制（scp）已被卸载，他们无法通过 scp 直接将有效负载上传到服务器，并且他们只有 shell 访问权限（而非物理访问权限）。
编辑：这个问题的另一个要素是任意代码执行漏洞是否通常使用 bash 命令。那么，这个系统强化程序是否会对阻止获得完全 root 访问权限的 Apache 漏洞有任何作用呢？
答案1
您可以随心所欲地强化您的系统，但如果您授予 shell 访问权限，总有办法。禁用后ls，echo *仍会显示其中的文件和目录。您永远不应该授予您不信任的人（当然，在一定级别内）访问您系统的 shell 权限。
假设的潜在黑客可能会尝试获取 root 权限，而不是您创建的用户 ID。限制 root 权限甚至更具挑战性，尤其是当您想以某种方式管理盒子时。
设置chroot环境可能是最好的选择，但即使这样也可能相当困难。您需要 chroot 环境中所有二进制文件、库等的副本。
Selinux 在这里帮不上什么忙。至少在你需要长期管理该设备时帮不上什么忙。
最终，该系统仍然必须可供普通用户使用。至少：这将是允许登录的原因。在我工作的地方，我们也有这样一个“强化”的系统；它完全没用。如果我需要在这个系统上/通过这个系统做任何事情，我需要绕过“强化”，这并不难。
如果确实必须，请将该chroot选项作为唯一可行的选择。否则，请重新考虑流程和安全性。对于普通用户来说，拥有一个无法使用的系统永远不是答案。
您可以考虑创建一次性虚拟系统。