Como restringir o shell dos usuários permitindo executar programas shell

Question

É possível impedir que qualquer usuário não use comandos como ls, rm e outros comandos do sistema que possam prejudicar o sistema. Mas os usuários devem ser capazes de executar programas shell.

    

Answer 1

Sua pergunta deve ser:

Eu não confio em meus usuários. Os burros vêem algo na internet e experimentam sem entender o que ele faz. Os desonestos gostam de bisbilhotar e olhar para os arquivos de outras pessoas e roubar suas idéias. E o preguiçoso, não me faça começar com os preguiçosos.

Como protejo meu sistema e meus usuários de meus usuários?

Primeiro, o unix tem um sistema de permissões de sistema de arquivos muito abrangente. Este parece ser um tutorial decente sobre as permissões do sistema de arquivos unix . A essência disso é que os diretórios podem ser configurados de forma que um usuário possa entrar em um diretório e executar programas fora desse diretório, mas não possa visualizar o conteúdo desse diretório. Se você fizer isso, por exemplo, em / home, se o usuário executar ls em / home, receberá um erro de permissão negada.

Se você realmente tem medo de seus usuários e quer colocá-los em um ambiente supermax de ambiente restrito, use algo como as cadeias do freebsd ou as zonas do solaris - cada usuário obtém seu próprio ambiente feito sob medida. Para pontos adicionados, use o ZFS para que você possa tirar um instantâneo do ambiente quando eles fizerem o login. Assim, se eles excluírem seus arquivos, você poderá simplesmente extraí-los do instantâneo.

    

Answer 2

Existem três coisas que precisam ser feitas para que você faça o que está pedindo:

1. Um shell personalizado que não possui os comandos nos quais você está interessado . Isso é difícil, mas se você realmente não quer que os usuários tenham acesso a algumas primitivas de shell, esta é a única maneira de removê-las.
2. Defina corretamente as permissões de arquivo . Não quer que os usuários danifiquem o sistema? Defina as permissões para que não danifiquem o sistema, mesmo que tenham as ferramentas certas. Destes três passos, este é o passo mais fácil.
3. Use um technoloy de controle de acesso obrigatório como o AppArmor . MACs como o AppArmor e o SELinux incorporam permissões no kernel. Eles impedem que os usuários executem as ferramentas certas, mesmo que as encontrem em algum lugar (e, assim como as permissões de arquivos, impedem que elas sejam usadas fora da caixa restrita).

Cinto, suspensórios e uma pistola de grampo para uma boa medida. Difícil de dar errado lá.

O AppArmor é interessante, pois o MAC de um executável específico é herdado por todos os seus filhos. Defina o login de um usuário como /bin/bash-bob , defina o perfil do AppArmor para esse direito binário específico e a única maneira de sair dessa prisão de permissão é através de explorações do kernel. Se algum script de instalação lenta deixar /var/opt/vendor/tmp global-writeable por algum motivo estúpido, o usuário que usar /bin/bash-bob como seu shell não conseguirá escrever lá . Defina o perfil bash-bob para permitir apenas gravar em seu diretório inicial e /tmp , e esses erros de permissão não podem ser aproveitados. Mesmo que, de alguma forma, encontrem a senha de root, o perfil do AppArmor para /bin/bash-bob ainda se aplicará mesmo depois que eles su up, já que su e bash do processo, são filhos de /bin/bash-bob .

A parte difícil é construir esse perfil do AppArmor.

1. Crie um perfil do AppArmor para / bin / bash-bob e configure-o para o modo de auditoria
2. Defina o shell de login do Bob para / bin / bash-bob
3. Faça login como Bob. Faça tudo o que você quiser que o Bob possa fazer.
4. Use o log de auditoria para criar o perfil do AppArmor (o SUSE tem ferramentas para isso, não tenho certeza sobre outras distribuições do Linux). Isso é monstruosamente tedioso, mas precisa acontecer se você precisar desse nível de segurança.
   1. Você estará fazendo coisas como:
      • Aprovando acesso de leitura à maioria das bibliotecas do sistema
      • Aprovar direitos de leitura e execução para os poucos comandos do sistema permitidos
      • Aprovando acesso de gravação a espaços temporários
      • Aprovando a criação de soquete, se necessário
5. Defina a política para impor.
6. Faça login como Bob, faça as coisas.
7. Faça ajustes.

Na minha opinião, você só precisa dos passos 2 e 3, pois, em combinação, ambos impedem a capacidade de fazer algo prejudicial fora da caixa cuidadosamente construída que você configurou em ambas as etapas.

    

Answer 3

Bem, você pode definir o shell do usuário para um programa que você tenha escrito, que só permite que eles executem scripts de shell.

É claro que isso seria tão seguro quanto o programa e os scripts de shell; na prática, esse tipo de shell restrito normalmente não é seguro contra um invasor inteligente.

    

Answer 4

Não tente limitar comandos, limite as permissões de arquivo. Você não pode praticamente limitar o acesso das pessoas ao syscalls, então tudo que alguém precisa fazer é fornecer sua própria cópia de qualquer comando "perigoso" que você não quer que eles executem, e você está recheado.

    

Answer 5

Se você quiser que o usuário só possa executar determinados scripts / binários, poderá usar um shell restrito . Isso (como o artigo da Wikipedia menciona) não é completamente seguro, mas se você pode garantir que nenhum aplicativo com permissão para executar é capaz de executar um novo shell, então é uma boa alternativa.

Para configurar um shell restrito aos usuários, defina /bin/rbash (ou similar, a maioria dos shells entram no modo restrito quando o binário é denominado r *** name *) como o shell do usuário. Em seguida, edite **. Bashrc (ou equivalente) e defina $PATH para um diretório no qual todos os binários / scripts permitidos sejam armazenados.

    

Answer 6

Sim, é possível, mas na prática isso exigiria muito trabalho e planejamento. Você pode criar scripts e executá-los como um uso privilegiado, depois remover todos os privilégios do usuário em questão. Ou, você pode definir o shell do usuário para algo que você mesmo possa fazer, permitindo que façam apenas o que você permitir explicitamente.

No entanto, as permissões padrão no Linux tornam quase impossível para um usuário normal "danificar o sistema". Que tipo de dano você está tentando evitar? É trivial evitar que os usuários consigam instalar software ou executar programas fora de seu diretório pessoal, e você pode usar o chroot para bloquear ainda mais o sistema.

    

Answer 7

Você pode querer tentar [lshell] [1] (shell limitado).

lshell is a shell coded in Python, that lets you restrict a user's environment to limited sets of commands, choose to enable/disable any command over SSH (e.g. SCP, SFTP, rsync, etc.), log user's commands, implement timing restriction, and more.

[1]: link lshell

    

Answer 8

A maneira que eu geralmente implemento esse tipo de restrição requer que várias condições sejam atendidas, caso contrário a restrição pode ser facilmente contornada:

• O usuário não pertence ao grupo wheel , o único autorizado a usar su (imposto pelo PAM).

• O usuário recebe um propriamente protegido rbash com um PATH de somente leitura apontando para um ~/bin privado, esse diretório ~/bin/ contém links para utilitários simples:

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

• o usuário recebe um ambiente restrito e somente leitura (pense em coisas como LESSSECURE , TMOUT , HISTFILE variables).

• o usuário é mapeado para o usuário do SELinux staff_u e recebe direitos para executar comandos como outro usuário, conforme necessário, por meio de sudo .

• o usuário /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
  

  Além disso, /etc/security/namespace.init faz todos os arquivos esqueletais somente para o usuário e pertencem a root .

Dessa forma, você pode escolher se $USER pode 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.

    

Answer 9

Sim, basta alterar as permissões desses comandos.

Você pode ter uma chance melhor de lutar escrevendo um comando shell que se comporta de acordo com seus requisitos.

O que não é apropriado das permissões padrão para usuários normais no Linux?