☰

用于管理文件和 git 存储库的受限 shell

tag-icon • tag-icon linux security
用于管理文件和 git 存储库的受限 shell

想象一下，一家网络托管公司希望让用户通过 ssh 管理文件和 git 存储库。这包括：

  • 安全复制 (scp)
  • 创建、复制、移动/重命名和删除文件
  • 执行源代码控制和文本编辑的一小部分命令（git、vim、nano）

我们希望实现这一点，并研究了以下选项：

这些将允许 scp 部分，但使用 git 似乎是不可能的。有一个补丁发射台，但我不确定该怎么做。git shell 教程，但它似乎不允许使用编辑器。也许 vim 甚至太多了，因为它可以用来执行更多代码，所以如果它太多了，我们可以放弃它（vim，或者完全放弃文本编辑器，如果必须的话）。

我们基本上想锁定 shell，这样用户可以管理（和编辑）文件和 git 存储库，但用户不应该能够在系统上执行任何其他程序。最大的问题是滥用网络和计算资源，但也使用系统作为代理。随便你怎么说。有没有办法做到这一点，或者我们可能对这个问题采取了错误的方法？

答案1

有两种互补的方法来实现这一点：

git授予用户远程使用存储库的权限

用于gitolite3提供 hub-live 存储库架构（详细描述这里），这基本上要求你有一个bare存储库（中心repo）让您的用户可以推送/拉取同一个 repo 的签出版本（居住例如，位于适当路径下的 .repo /srv/www/html。

我喜欢用gitolite3处理中心repo，但这不是必需的，尽管有与您选择的 LDAP 绑定的细粒度访问控制如果需要的话，gitolite3可以提供直至分支级别的细粒度控制。

gitolite3通过 限制用户的能力sudo并通过sudo调用来处理钩子也是一种很好的做法。这是一个使用钩子的工作示例gitolite3（您可以随意调整它们 - 或增强/修复它们 - 以满足您的需求）：

  • /etc/sudoers或的相关内容/etc/sudoers.d/gitolite3大致如下：

    Cmnd_Alias        GITOLITE_CMDS = /usr/bin/git, /bin/chown, /bin/find, /usr/bin/xargs, /bin/chmod, /sbin/restorecon, /usr/local/sbin/publisher-hub2live
Cmnd_Alias GITOLITE_APACHE_CMDS = /usr/sbin/apachectl graceful
Defaults:gitolite3 !requiretty
Defaults:gitolite3 lecture=never
gitolite3                ALL = (root)NOPASSWD: GITOLITE_CMDS
gitolite3       APACHE_HOSTS = (root)NOPASSWD: GITOLITE_APACHE_CMDS

  • 中心回购post-update挂钩：

    #!/bin/sh

echo "****"
echo "**** Calling publisher-hub2live script [Hub's post-update hook]"
echo "****"

sudo /usr/local/sbin/publisher-hub2live "/srv/www/html" "root:apache" "2750" "640"

exit 0

  • publisher-hub2live脚本：

    #!/bin/sh

echo "****"
echo "**** Pulling changes into Live [publisher-hub2live]"
echo "****"

cd "$1" || exit
umask 0022
unset GIT_DIR
/usr/bin/git pull hub master

# custom actions here
# e.g call grunt tasks
/bin/chown -R "$2" "$1"
/bin/find "$1" -type d -exec chmod "$3" {} +
/bin/find "$1" -type f -exec chmod "$4" {} +
/bin/chmod u+x "$1"/.git/hooks/post-commit
/sbin/restorecon -R -v "$1"
exec /usr/bin/git update-server-info

exit 0

限制在登录 shell 中执行未经授权的命令的能力

您需要实施的是一种可重复、可审计的方法来限制用户执行除严格允许之外的操作的能力。

这不是必需的，但如果您的用户已在 LDAP 中注册，并且已经部署了执行 LDAP 身份验证的机制（无论是通过 PAM 模块还是使用 freeIPA 和），它会有所帮助sssd。

为了实现这种情况，我目前所做的工作如下（请注意，这种限制需要满足几个条件，否则很容易规避限制）：

  • 用户不属于该wheel组，该组是唯一被授权使用su（通过 PAM 强制执行）的用户。通常，存在非 LDAP 用户 ( sysadm)，以允许受信任的管理员在灾难恢复或 LDAP 不可用的情况下执行操作。

  • 为用户提供了一个适当保护的、rbash指向私有的只读 PATH 目录~/bin，该~/bin/目录包含所有允许的命令的链接，例如：

    $ ll ~/bin
total 0
lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
lrwxrwxrwx. 1 root dawud  7 Sep 17 08:58 df -> /bin/df*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
lrwxrwxrwx. 1 root dawud  8 Sep 17 08:58 env -> /bin/env*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 git -> /usr/bin/git*
lrwxrwxrwx. 1 root dawud  9 Sep 17 08:58 grep -> /bin/grep*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*

  • 为用户提供受限制的只读环境（想想诸如LESSSECURE、TMOUT、HISTFILE变量之类的东西）。这是为了避免shell命令逃逸less并确保可审计性。

  • 出于同样的原因，唯一允许的编辑器是rvim。用户只能执行配置sudoedit为在配置rvim中运行的sudo：

    Defaults editor=/usr/bin/rvim

  • 如果存在 MAC 限制（您使用的特定 GNU/Linux 发行版已启用 SELinux），则用户将映射到 SELinux 用户staff_u，并被赋予通过 以其他用户身份执行命令的权限sudo。需要仔细审查具体sudorules允许，以防止用户规避这些限制，也可以部署在您现有的 LDAP 基础架构中（这是 freeIPA 功能之一）。

  • 用户的/home，/tmp并且可能/var/tmp通过以下方式进行多实例化/etc/security/namespace.conf：

    /tmp       /tmp/.inst/tmp.inst-$USER-     tmpdir:create   root
/var/tmp   /tmp/.inst/var-tmp.inst-$USER- tmpdir:create   root
$HOME      $HOME/$USER.inst/              tmpdir:create   root

    目录的多实例化并不是一个新功能，它已经存在很长时间了。作为参考，请参阅这篇文章来自 2006 年。事实上，很多模块已经pam_namespace默认使用，但 的默认配置/etc/security/namespace.conf不启用多实例化。此外，/etc/security/namespace.init应将所有骨架文件设置为用户只读，并归 拥有root。

这样，您可以选择用户是否可以代表自己执行任何命令（通过私人~/bin目录中的链接，通过 提供/etc/skel，如上所述），代表其他用户执行任何命令（通过sudo）或者根本不执行任何命令。

相关内容