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

É 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.

Sua pergunta deve ser:

Eu não confio nos meus usuários. Os idiotas vêem algo na internet e experimentam sem entender o que fazem. Os desonestos gostam de bisbilhotar e olhar os arquivos de outras pessoas e roubar suas idéias. E os preguiçosos, não me iniciem nos preguiçosos.

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

Primeiro, o unix possui 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 a partir desse diretório, mas não pode visualizar o conteúdo desse diretório. Se você fizer isso, por exemplo, em / home, se o usuário executar ls em / home, ele receberá um erro de permissão negada.

Se você está realmente com medo de seus usuários e deseja colocá-los em um ambiente restrito do tipo supermax , use algo como cadeias do freebsd ou zonas do solaris - cada usuário obtém seu próprio ambiente personalizado. Para adicionar pontos, use o ZFS, para que você possa tirar um instantâneo do ambiente ao efetuar login. Se eles excluirem seus arquivos, basta retirá-los do instantâneo.

Há três coisas que precisam estar em vigor para fazer totalmente o que você está pedindo:

1. Um shell personalizado que não possui os comandos de seu interesse . É algo difícil de obter, mas se você realmente não deseja que os usuários tenham acesso a algumas primitivas do shell, essa é 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 possam danificar o sistema, mesmo que tenham as ferramentas certas. Dessas três etapas, este é o passo mais fácil.
3. Use uma tecnologia obrigatória de controle de acesso como o AppArmor . MACs como AppArmor e SELinux incorporam permissões no kernel. Isso evita que os usuários executem as ferramentas certas, mesmo que as encontrem em algum lugar (e, como as permissões de arquivo, evitam que 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 para um executável específico é herdado por todos os seus filhos. Defina o login de um usuário /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 preguiçoso deixar /var/opt/vendor/tmpgravável globalmente por algum motivo estúpido, o usuário que usar /bin/bash-bobcomo shell não poderá escrever lá . Defina o perfil bash-bob para permitir apenas a gravação no diretório inicial e /tmp, e esses erros de permissão não podem ser aproveitados. Mesmo que, de alguma maneira, eles encontrem a senha root, o perfil do AppArmor /bin/bash-bobainda será aplicado mesmo depois que eles suaparecerem desde então sue o bashprocesso em que são gerados são filhos /bin/bash-bob.

A parte difícil é criar 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 de Bob como / bin / bash-bob
3. Faça o login como Bob. Faça tudo o que você deseja que Bob possa fazer.
4. Use o log de auditoria para criar o perfil do AppArmor (o SUSE possui ferramentas para isso, não tenho certeza sobre outras distribuições do Linux). Isso é monstruosamente entediante, mas precisa acontecer se você precisar desse nível de segurança.
   1. Você estará fazendo coisas como:
      • Aprovando o acesso de leitura à maioria das bibliotecas do sistema
      • Aprovar direitos de leitura e execução para os poucos comandos de sistema permitidos selecionados
      • Aprovando o acesso de gravação a espaços temporários
      • Aprovar a criação de soquete, se necessário
5. Defina a política a ser aplicada.
6. Faça o login como Bob, faça as coisas.
7. Faça ajustes.

Na minha opinião, você só precisa das etapas 2 e 3, pois, em combinação, elas impedem a capacidade de fazer algo prejudicial fora da caixa cuidadosamente construída que você configurou nas duas etapas.

Bem, você pode definir o shell do usuário para um programa que você escreveu que apenas permite executar determinados 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.

Não tente limitar comandos, limite as permissões de arquivo. Você não pode praticamente limitar o acesso das pessoas aos syscalls; portanto, tudo o que alguém precisa fazer é fornecer sua própria cópia de quaisquer comandos "perigosos" que você não queira que eles executem, e você estará cheio.

Se você deseja que o usuário possa executar apenas determinados scripts / binários, use 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 seja capaz de executar um novo shell, é uma boa alternativa.

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

Sim, é possível, mas na prática seria preciso muito trabalho e planejamento. Você pode criar scripts e executá-los como um uso privilegiado e 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 criou, permitindo que eles 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 "prejudicar o sistema". Que tipo de dano você está tentando evitar? É trivial impedir que os usuários possam instalar software ou executar programas fora do diretório inicial, e você pode usar o chroot para bloquear ainda mais o sistema.

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

lshell é um shell codificado em Python, que permite restringir o ambiente de um usuário a conjuntos limitados de comandos, optar por ativar / desativar qualquer comando sobre SSH (por exemplo, SCP, SFTP, rsync etc.), registrar comandos do usuário, implementar restrições de tempo, e mais.

[1]: http://lshell.ghantoos.org/Overview lshell

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

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

• O usuário recebe uma proteção adequada rbash com um PATHapontamento somente leitura para um privado ~/bin, esse ~/bin/diretório 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 é dado um, somente leitura ambiente restrito (pense em coisas como LESSSECURE, TMOUT, HISTFILEvariáveis).

• o usuário é mapeado para o usuário do SELinux staff_ue recebe direitos para executar comandos como outro usuário, conforme necessário sudo.

• do usuário e /home, /tmppossivelmente, /var/tmpsão instituídos por meio de /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.inittorna todos os arquivos esqueléticos somente leitura para o usuário e de propriedade de root.

Dessa forma, você pode escolher se $USERpode executar qualquer comando em seu próprio nome (por meio de um link no ~/bindiretório privado , provisionado por /etc/skel, como explicado acima), em nome de outro usuário (por sudo) ou nenhum.

Sim, basta alterar as permissões nesses comandos.

Você pode ter uma melhor chance de lutar escrevendo um comando shell que se comporte aos seus requisitos.

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