Eu tenho um programa chamado foo que precisa de privilégios de root quando é executado. O foo precisa ser capaz de ser executado por qualquer usuário e pode estar localizado em qualquer caminho. A razão pela qual este programa pode estar em qualquer caminho é porque nossa empresa está desenvolvendo o programa foo e cada usuário pode ter uma versão pessoal do programa em algum diretório pessoal enquanto trabalha nele.
Minha pergunta é: qual é a maneira mais segura de lidar com isso? Eu tenho pesquisado o arquivo sudoers e tenho basicamente 2 ideias.
1.) Liste todos os caminhos nos quais o programa pode estar no arquivo sudoers. Isso é problemático porque requer a edição freqüente da lista de sudoers e também representa um risco de segurança, já que os usuários não-root possuirão sua cópia individual do foo e poderão copiar algum programa do sistema pelo foo e usá-lo como root.
2.) Escreva um script chamado start_foo que execute alguma validação de entrada no programa passado, como tamanho e nome, e então inicie o passado em foo. start_foo poderia viver em / usr / bin e pertencer a root, mas executável por qualquer pessoa. Esta opção ainda inclui a falha de segurança de poder escrever sobre o programa foo dos usuários com outra raiz que requer programa, mas esperamos que a verificação de tamanho detecte alguns casos maliciosos.
Existe uma maneira "canônica" de resolver esse problema que não encontrei ou pensei? Se não qual das soluções acima ou possivelmente outra é a melhor maneira de lidar com o problema?
Obrigado!
A maneira mais segura de lidar com isso provavelmente seria dar a cada um de seus desenvolvedores seu próprio ambiente de desenvolvimento / teste, talvez uma máquina virtual. Dessa forma, eles só podem quebrar sua própria instância de desenvolvimento.
Uma solução óbvia e mais segura seria criar um novo aplicativo daemon privilegiado, food , que lida com as coisas que o seu foo app deveria fazer como root, e então o foo app se comunica com food usando, por exemplo. soquetes (Unix, TCP). Se o seu aplicativo foo for comprometido, o invasor poderá se comunicar apenas com o food , que teria um conjunto de comandos limitado.
Se você confia em seus colegas de trabalho, você pode adicionar cada um deles a um grupo unix foodevel , usar a solução 2) e permitir somente a execução dos programas foo se eles pertencerem a esse grupo. Uma pessoa pertencente a um grupo específico pode emitir um comando chgrp nos arquivos, e outras pessoas não poderão.
Além disso, você pode verificar uma solução de byte sUID, em vez de depender do sudo. Isso pode não ser bem suportado por toda e qualquer linguagem de programação e você precisa saber um pouco sobre as permissões efetivas (confira man seteuid ).
Talvez use um chroot jail de algum tipo. Possivelmente criando-os rapidamente, conforme necessário, com vários arquivos que o aplicativo precisa executar.
Isso representa um enorme problema porque o usuário pode editar o script a qualquer momento. Mesmo que o arquivo seja somente de leitura, eles terão privs de gravação no diretório em que ele está.
Por esse motivo, você precisa que o script root-priv esteja em algum lugar sob seu controle
Você pode fazer algo como
/ home / central / [scriptname] < ---- somente o diretório gravável da raiz, legível pelo mundo. Este você pode dar acesso ao sudo
Então / home / [anyuser] / scriptname < --- não sudo access
E o scriptname é um wrapper para / home / central / [scriptname]
Isso seria melhor e mais viável
E / home / [anyuser] / scriptname seria algo como
#!/bin/bash
/home/central/[scriptname] $@ # pass all arguments