Shell restrito para gerenciar arquivos e repositórios git

Question

Pense em uma empresa de hospedagem que deseja permitir que os usuários gerenciem arquivos e git repositórios via ssh. Isso inclui:

• cópia segura (scp)
• criando, copiando, movendo / renomeando e excluindo arquivos
• executando um subconjunto restrito de comandos para controle de origem e edição de texto (git, vim, nano)

Gostaríamos de implementar isso e analisamos as seguintes opções:

• rssh
• scponly

Isso permitiria a parte scp, mas o uso do git não parece ser possível. Há um patch no Launchpad , mas não tenho certeza do que fazer com ele . Também há o git-shell , mas não parece permitir editores. Talvez o vim seja até demais, porque ele poderia ser usado para executar mais código, então poderíamos eliminar isso (vim, ou editores de texto completamente, se necessário) se for demais.

Basicamente, queremos bloquear o shell, para que o usuário possa gerenciar (e editar) arquivos e repositórios, mas o usuário não deve poder executar nenhum outro programa no sistema. O maior problema seria o abuso de recursos de rede e computação, mas também usar o sistema como proxy. Você nomeia isto. Existe uma maneira de fazer isso ou talvez tenhamos uma abordagem errada sobre esse problema?

    

Answer 1

Você tem duas maneiras complementares de implementar isso:

Conceder permissões aos usuários para usar git repositórios remotamente

Use gitolite3 para fornecer um esquema de repositórios do hub-live (isso é descrito em detalhes aqui ), que basicamente requer que você tenha um repositório bare (um repositório hub ) para permitir que seus usuários façam push / pull e uma versão com check-out do mesmo repositório (a < repo strong> live localizado no caminho apropriado, por exemplo, /srv/www/html , por exemplo.

Eu gosto de usar gitolite3 para lidar com o repositório hub , mas isso não é um requisito, embora seja bastante conveniente ter fine -grained controle de acesso vinculado ao seu LDAP de escolha se for necessário. gitolite3 pode fornecer controle refinado até o nível da filial.

Também é uma boa prática limitar as capacidades do usuário gitolite3 via sudo e manipular os ganchos por meio de sudo chamadas. Este é um exemplo de trabalho usando gitolite3 hooks (sinta-se livre para adaptá-los - ou aprimore / corrija - para atender às suas necessidades):

• O conteúdo relevante do /etc/sudoers ou /etc/sudoers.d/gitolite3 seria algo como:

  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
  

• hub repo post-update hook:

  #!/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 script:

  #!/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
  

Limitando a capacidade de executar comandos não autorizados em um shell de login

O que você precisa implementar é um método reproduzível e auditável de limitar a capacidade do usuário de executar ações diferentes das estritamente permitidas.

Não é necessário, mas ajuda se você tiver seus usuários registrados no LDAP e já tiver implantado os mecanismos para executar a autenticação LDAP, seja por meio de um módulo PAM ou usando freeIPA e sssd .

Para implementar esse cenário, o que eu faço atualmente é o seguinte (esteja ciente de que esse tipo de restrição requer que várias condições sejam atendidas, caso contrário, a restrição pode ser facilmente contornada):

• Os usuários não pertencem ao grupo wheel , o único autorizado a usar su (imposto pelo PAM). Geralmente, existe um usuário não LDAP ( sysadm ) para permitir que administradores confiáveis executem ações em casos de recuperação de desastre ou indisponibilidade do LDAP.

• Os usuários recebem um rbash devidamente protegido com um PATH somente leitura apontando para um diretório privado ~/bin , esse diretório ~/bin/ contém links para todos os comandos permitidos, por exemplo:

  $ 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*
  

• os usuários recebem um ambiente restrito e somente leitura (pense em coisas como LESSSECURE , TMOUT , HISTFILE variables). Isso evita que shell escape de comandos como less e garanta a capacidade de auditoria.

• o único editor permitido é rvim , pelo mesmo motivo. Os usuários podem executar apenas sudoedit , que está configurado para executar rvim na configuração sudo :

  Defaults editor=/usr/bin/rvim
  

• se restrições de MAC estiverem em vigor (a distribuição específica do GNU / Linux que você está usando tem o SELinux habilitado), os usuários são mapeados para o usuário do SELinux staff_u e recebem direitos para executar comandos como outro usuário %código%. O sudo específico permitido precisa ser cuidadosamente revisado para impedir que o usuário contorne essas limitações e também pode ser implantado em sua infra-estrutura LDAP existente (esse é um dos recursos do freeIPA).

• os usuários ' sudorules , /home e possivelmente /tmp são polyinstantiated via /var/tmp :

  /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
  

  Polyinstantiation de diretórios não é um novo recurso, já está disponível há um bom tempo. Como referência, consulte este artigo de 2006 . De fato, muitos módulos já usam /etc/security/namespace.conf por padrão, mas a configuração padrão em pam_namespace não habilita o polyinstantiation. Além disso, /etc/security/namespace.conf deve tornar todos os arquivos esqueletais somente leitura para os usuários e pertencentes a /etc/security/namespace.init .

Dessa forma, você pode escolher se os usuários podem executar qualquer comando em seu próprio nome (por meio de um link no diretório root privado, provisionado via ~/bin , conforme explicado acima), em nome de outro usuário (via /etc/skel ) ou nenhum.