Usuário não-root recebendo acesso root após rodar “sudo vi / etc / hosts”

Question

Em uma máquina linux, um usuário não-root abre um arquivo,

$ sudo vi /etc/hosts

e saia dizendo :sh

para obter acesso root.

1) Acima, Como um usuário não-root se torna um usuário root?

2) Por que o Linux permite que tal abordagem hacker viole a segurança?

    

Answer 1

O usuário não-root tornou-se root assim que executou com sucesso sudo (dado o suposto usuário root de destino); eles começaram a executar vi como root. Quando você pergunta vi para um shell, ele executa obedientemente um shell, como o usuário atual - root! Eu devo esclarecer que você não deve "sair" do vi com o comando :sh , como se estivesse pedindo por um shell. Saia com :q .

O Linux permite tal funcionalidade porque é especificamente o que sudo pretende fazer! Talvez você tenha visto a palestra que o sudo dá:

We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.

#2) Think before you type.

#3) With great power comes great responsibility.

O sudo oferece um "aumento de velocidade" limitado quando se trata de conceder acesso "ALL", na forma do operador de negação ! , geralmente demonstrado como:

jill        SERVERS = /usr/bin/, !SU, !SHELLS

onde jill tem permissão para executar programas de / usr / bin, mas não qualquer coisa listada nos aliases SU ou SHELLS.

A página man sudoers tem uma seção inteira "Notas de segurança" quando se trata para conceder acesso em larga escala via sudo e, em seguida, tentar restringi-lo.

Limitations of the ‘!’ operator

It is generally not effective to “subtract” commands from ALL using the ‘!’ operator. A user can trivially circumvent this by copying the desired command to a different name and then executing that.

e

In general, if a user has sudo ALL there is nothing to prevent them from creating their own program that gives them a root shell (or making their own copy of a shell) regardless of any ‘!’ elements in the user specification.

e mais pertinente:

Preventing shell escapes

Once sudo executes a program, that program is free to do whatever it pleases, including run other programs. This can be a security issue since it is not uncommon for a program to allow shell escapes, which lets a user bypass sudo's access control and logging. Common programs that permit shell escapes include shells (obviously), editors, paginators, mail and terminal programs

    

Answer 2

Se sudo vi /etc/hosts for bem-sucedido, significa que o administrador do sistema permitiu que o usuário executasse vi /etc/hosts como root. Esse é o ponto principal do sudo: ele permite que o administrador do sistema autorize certos usuários a executar certos comandos com privilégios extras.

Conceder a um usuário a permissão para executar vi concede a permissão para executar qualquer comando vi, incluindo :sh para executar um shell e :w para sobrescrever qualquer arquivo no sistema. Uma regra que permite executar apenas vi /etc/hosts não faz sentido, pois permite que o usuário execute comandos arbitrários.

Não há "hacking" envolvido. A quebra de segurança vem de uma configuração incorreta, não de um buraco no modelo de segurança. O Sudo não tenta particularmente impedir a configuração incorreta. Sua documentação é bem conhecida por ser difícil de entender; em caso de dúvida, pergunte e não tente fazer coisas que são muito complicadas.

Em geral, é um problema difícil dar a um usuário um privilégio específico sem dar a ele mais do que o pretendido. Uma abordagem de bulldozer como dar a eles o direito de executar um programa interativo como o vi está fadado ao fracasso. Um conselho geral é dar os privilégios mínimos necessários para realizar a tarefa. Se você quiser permitir que um usuário modifique um arquivo, não conceda a permissão para executar um editor. Em vez disso:

• Conceda a eles permissão para gravar no arquivo. Este é o método mais simples com o menor risco de fazer algo que você não pretendia.

  setfacl u:bob:rw /etc/hosts
  

• Dê permissão para editar o arquivo via sudo. Para fazer isso, não lhes dê permissão para executar um editor. Como explicado na documentação do sudo, conceda a eles a permissão para executar sudoedit , que invoca um editor como o usuário original e depois usa os privilégios extras apenas para modificar o arquivo.

  bob ALL = sudoedit /etc/hosts
  

  O método sudo é mais complicado de configurar e é menos transparente para o usuário porque ele precisa invocar sudoedit em vez de apenas abrir o arquivo em seu editor, mas tem a vantagem de todos os acessos serem registrados.

Observe que permitir que um usuário edite /etc/hosts pode ter um impacto em sua infraestrutura de segurança: se houver algum lugar em que você dependa de um nome de host correspondente a uma máquina específica, esse usuário poderá apontá-lo para um máquina diferente. Considere que é provavelmente desnecessário de qualquer maneira .