保护受限 shell 环境

信息安全 linux
2021-08-20 12:06:57

我已经阅读了一些内容,表明如果没有正确实施(甚至是wikipedia,例如),受限的 shell 可以被打破

我正在寻找一些有关导致受限外壳中的安全漏洞以及如何解决这些问题的指导。

我认为主要问题是您允许用户使用的二进制文件;如果这些程序中的任何一个有助于执行具有更高权限的其他程序/脚本。
这是否意味着默认的 rbash shell 相对安全?
是否有任何特定程序(或多或少)绝对安全/不安全(到目前为止,我已经看到 vim 和 scp 用于爆发的特定示例)?
还有其他需要考虑的事情吗?

此外,当您想限制用户可以运行的命令时,是否有更好的选择来使用受限 shell?


更新 1
继 bstpierre 提到使用 ssh command= 之后,有没有人尝试使用 command= 强制用户运行一个脚本,该脚本使用 SSH_ORIGINAL_COMMAND 从用户那里获取输入,然后根据该输入运行有限的附加命令/程序?我想这将有一个非常有限的用例,但对我来说似乎可行,只要脚本小心它接受的输入。

更新 2
我在更新 1 中提出的建议结果正是 gitolite 所做的;使用 command= 和 SSH_ORIGINAL_COMMAND,使用一些钩子魔术来区分分支。来自他们文档的信息。
所以我知道这种方法是一种可行的选择,但我仍然在回答关于受限外壳的原始查询。

1个回答

我已经设置了将用户放入 chroot 监狱的受限 shell 环境。只有最小的可执行文件被复制到监狱中。shell 用户在监狱中几乎没有任何权限——一切都默认为拒绝,我只在必要时提供权限。您可以将 jail 与 rbash 结合起来以获得额外的保护。chroot 监狱的优势在于,如果用户从 rbash 中脱离出来,他仍然被困在 chroot 监狱中,无法访问系统的其余部分。(在某些情况下可以突破 chroot 监狱,但在打过补丁的操作系统上正确构建它是很难攻击的。)

要考虑的另一点是您是否真的需要提供外壳。您需要提供的服务是否可以设置为简单、安全的 Web 服务?

最后,如果 shell 是通过 ssh 提供的,您可以通过要求通过密钥登录并command=在您的 authorized_keys 文件中设置来限制用户可用的命令集。但是,您必须在这里小心,因为如果您允许的命令允许用户“突围”,那么您不会比对受限 shell 进行相同的攻击更好。