constrói o usuário chroot no primeiro login

Question

Estou usando o ldap para autenticação remota de usuários e basicamente preciso descobrir como:

a. chroot um usuário na máquina b da máquina a via nfs, (o que não parece possível sem montar mais diretórios do que me sinto confortável)

ou -------

b. Depois de adicionar um usuário ao banco de dados do ldap na máquina a, force um script a ser executado na máquina b durante o login dos usuários que fará o chroot automático do usuário antes de poder fazer qualquer coisa no primeiro login.

Estou pensando que minha segunda opção é provavelmente a melhor aposta, e estava pensando em usar pam_exec.so para chamar o script. No entanto, tenho algumas preocupações sobre essa abordagem. Primeiro, não tenho certeza se o script que será executado terá permissões de root que serão necessárias para executar o chroot. Segundo, não tenho certeza se o pam_exec acontece cedo o suficiente no processo de login para ser uma opção eficaz. Por fim, eu preciso ter certeza de que o código funciona em pam.d / ssh e pam.d / su para considerá-lo uma solução válida.

As minhas preocupações são válidas ou parece que esta seria uma boa solução? Ou há uma abordagem melhor para esse problema?

    

Answer 1

Em primeiro lugar, sem dúvida, chroot pode não ser considerado um recurso de segurança . Existem opiniões na outra direção, também .

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

Se você registrar seus usuários no LDAP, certamente já implementou os mecanismos para executar a autenticação LDAP em qualquer máquina conectada a este LDAP, seja por meio de sssd ou usando qualquer outro módulo PAM, não é relevante para o resto da solução, e é assumido como já está no lugar (no meu caso, estou usando o 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  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 rvim -> /usr/bin/rvim*
  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 ou vim .

• se houver restrições MAC (a distribuição GNU / Linux específica que você está usando tem o SELinux ativado), os usuários serão mapeados para o usuário do SELinux staff_u e receberão direitos para executar comandos como outro usuário, conforme necessário, por meio de sudo . O sudorules específico permitido precisa ser cuidadosamente revisado para evitar 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 ' /home , /tmp e possivelmente /var/tmp são polyinstantiated via /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
  

  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 pam_namespace por padrão, mas a configuração padrão em /etc/security/namespace.conf não habilita o polyinstantiation. Além disso, /etc/security/namespace.init deve tornar todos os arquivos esqueletais somente leitura para os usuários e pertencentes a root .

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 ~/bin privado, provisionado via /etc/skel , conforme explicado acima), em nome de outro usuário (via sudo ) ou nenhum.