> On 10/07/2015, at 09:46, Patrick Müller <[email protected]> wrote:
>
> Bom dia galera
>
> Estou precisando de uma ajuda para configurar uma permissão de sudo.
>
> Tenho um script A com as seguintes permissões ---s--x—x que recebe como
> parâmetro um outro script B com permissão rwsrwxrwx, até aí está
> funcionando bem.
>
> O script A tem o seguinte conteúdo
>
> #!/bin/sh
>
> chown -R root /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/$1
>
> chmod 4777 /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/$1
>
>
>
> O script B tem o seguinte conteúdo
>
> #!/bin/sh
>
> echo senha | pw mod user usuario -h 0
>
>
>
> Bem simples para a troca de senha.
>
>
>
> Na configuração do sudoers eu tenho
>
>
>
> Funciona, mas pelos meus critérios de segurança é péssimo.
>
> www ALL=(ALL) NOPASSWD: /bin/sh
>
>
>
> Acredito que para o que eu quero seria uma opção melhor, mesmo ainda sendo
> um grande risco para segurança.
>
> #www ALL=(ALL) NOPASSWD: /bin/sh /caminho/scriptA.sh
A simples mudança do PATH antes da execução fará com que chown e chmod seja
qualquer coisa que o “atacante” deseje. Então sempre que for fazer shell script
mais critico, se acostume a usar PATH completo pros comandos, /usr/sbin/chown,
/bin/chmod, etc. Declarar seu próprio PATH no corpo do script também não
resolve ja que o ambiente pertence ao escopo do usuário e ele faz o que bem
entender, redefine, destroi, ignora.
Faz o seguinte, no sudores coloque sempre o caminho completo pros comandos que
quer permitir e controle os argumentos pro comando. Ou seja aparentemente você
não quer liberar /usr/sbin/chown quer liberar apenas:
/usr/sbin/chown -R root /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/[A-z]*
Teste exatamente o que quer liberar e coloque uma regex esperta controlando os
argumentos variáveis :P Abuse da negação no sudo, se for o caso:
/usr/sbin/chown -R root /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/[A-z]*,
!/usr/sbin/chown -R root /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/nao_pode
Nunca libere o seu shell script como um todo, ao invés disso o shell script
deve usar o sudo, e por sua vez path completo, ignorando/dispensando o PATH
existente:
#!/bin/sh
unset PATH
/usr/local/bin/sudo /usr/sbin/chown -R root
/www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/algumacoisa
Se quiser ter ainda mais controle, faça o usuário www fazer ssh pra localhost e
libere no sudo a execução pra esse outro usuário:
#!/bin/sh
unset PATH
ssh -i /caminho/pra/chave sudouser@localhost "/usr/local/bin/sudo
/usr/sbin/chown -R root
/www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/algumacoisa”
Você tem mais controle, tem auditabilidade, pode impor limites no ssh, controle
de acesso, pode usar chave com passphrase e o ssh-agent pra permitir a
automação do processo, só sendo necessário digitar o passphrase quando subir o
serviço httpd por exemplo, vai juntar 2 fatores de autenticação (ter a chave e
saber o passphrase), enfim melhora o ambiente consideravelmente e seu controle.
Mas você pode achar demais “tudo isso” só pra permitir um chown e um chmod ;)
Se avaliar que a criticidade não é tanta, esqueça o ssh e faz o resto, da foco
na declaração explícita do que você quer e não quer liberar no sudoers.
O proprio man sudoers tem mais exemplos nessa linha de liberar regex
explicitamente e bloquear exceções à regex:
pete HPPA = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd root
%opers ALL = (: ADMINGRP) /usr/sbin/
Boa diversão :D
>
>
>
> Quem puder avaliar os riscos disso e me ajudar eu já agradeço.
--
Patrick Tracanelli
FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
[email protected]
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
