Quais são os riscos reais de fornecer acesso a www-data sudo nopasswd?

Question

Eu tenho um servidor que acabei de instalar o apache. Eu tenho um script php no servidor que eu gostaria de executar um comando sudo de. Eu tenho vasculhado a web sobre por que dar acesso ao www-data sudo nopasswd no arquivo sudoers é ruim, mas eu não entendo o porque? Se este é o único script php no servidor, e a única finalidade do servidor é processar este script php, ainda é perigoso? Se sim, de que outra forma eu deveria fazer isso? Eu não consigo descobrir. Eu estou executando um script python que vai usar os.system () para executar um comando sudo e é por isso que eu quero dar acesso. Outra coisa que notei é que quando eu direciono para apenas a pasta com o meu script python, não funciona. Quando eu dirijo para TODOS, isso acontece. Eu não tenho certeza do que fazer. Obrigado.

    

Answer 1

Em nenhuma circunstância permita que seu servidor da Web execute comandos com sudo . Nem mesmo comandos hiperespecíficos.

Este é um enorme risco de segurança. Um servidor da Web não deve receber permissões para acessar os comandos sudo , que permitem o acesso root aos comandos. Especialmente quando for dado nopasswd forma de sudo , caso seu servidor da Web seja violado, qualquer comando executado por um agente de ameaça mal-intencionado pode ser executado como root com permissões de deus, assim todo o seu sistema está ao alcance de dados roubo, exclusão de dados, corrupção e danos ao SO .

Muitos aplicativos da web não são gravados em um método seguro e, se sua instalação do Apache for violada, você não poderá se proteger de scripts e agentes de ameaças mal-intencionados de executar qualquer comando arbitrário.

Se você precisar conceder ao servidor web permissão para executar algo como root, você está fazendo algo errado e deve reavaliar o que está tentando fazer. Como sua pergunta não diz nada sobre o que exatamente você está tentando alcançar ou o que exatamente seu script está fazendo, o único conselho que posso dar como administrador de sistemas e pessoa de segurança é não tentar fornecer o servidor web sudo access .

    

Answer 2

O princípio por trás do usuário www-data é que ele é um usuário sem privilégios .

Quando você executa um daemon (programa em segundo plano como um servidor da web), por motivos de segurança, é bom para ele perder privilégios após o início, para que ele passe o resto do tempo com os privilégios mais baixos possíveis.

No passado, a conta nobody era frequentemente usada para essa finalidade. O benefício disso foi que o nome "nobody" deixou claro que esta deveria ser uma conta unprivileged , sem direitos.

No entanto, exceções à regra ocasionalmente surgirão, por meio das quais alguém precisará de um daemon para ter permissão de gravação aqui ou ali. Modificar a conta nobody afetaria todos os daemons.

Portanto, www-data nasceu como uma forma de ter um usuário não privilegiado apenas para servidores Web, mas isolado de outros daemons ou propósitos, portanto, se você tivesse que conceder a essa conta de usuário alguns privilégios adicionais, isso afetaria apenas servidor web e não reduzir a segurança de outros daemons do sistema .

A ideia de que www-data deva ser um usuário sem privilégios ainda é importante. Quanto mais privilégios você der, mais preocupação terá sobre o que pode acontecer se o daemon (ou qualquer um dos scripts ou comandos que ele executa) estiver comprometido ou expor uma falha de segurança de qualquer tipo.

Dar www-data some sudo access é a antítese desse princípio. Embora seja possível ser seletivo com o acesso sudo, ele ainda abre um risco de segurança bastante grande devido ao potencial de erro humano ou o potencial que o servidor da Web ou quaisquer scripts que ele executa podem ter falhas de segurança.

Como você pode evitar isso?

• Existe alguma maneira de projetar a tarefa para que não precise de privilégios de superusuário?
• Se não, a tarefa realmente precisa ser executada por um script disponibilizado no servidor da web? Seria mais seguro se fosse executado por algo que não fosse voltado para o público, como o Cron - ou que fosse executado manualmente, digamos, SSH.