Por que é arriscado dar acesso ao sudo vim a usuários comuns?

Question

Eu gostaria de criar um novo usuário e dar a ele acesso ao sudo. Para ser específico, quero que ele use sudo vim e edite o httpd.conf. Eu escrevi isso em sudoers:

user ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf

Eu, no entanto, ouvi que isso poderia ser arriscado. Por que isso é problemático? Quão sério é o problema?

    

Answer 1

Embora você restrinja os argumentos da linha de comando, não há nada que impeça o usuário de usar o vim para abrir, editar e sobrescrever qualquer arquivo aleatório quando estiver rodando como root.

O usuário pode executar sudo vim /etc/httpd/conf/httpd.conf e, em seguida,

• limpe todo o texto do buffer de edição
• então para a fonte de conveniência um arquivo existente (embora isso nem seja necessário): por exemplo a configuração sudo
  :r /etc/sudoers NOTA: A menos que seja restrito pelo SELinux, o usuário pode ler qualquer arquivo caminho!
• conceda-se mais privilégios sudo user ALL=(ALL) NOPASSWD: ALL
• sobrescrever a configuração antiga :w /etc/sudoers

Posso imaginar dezenas de maneiras semelhantes pelas quais seu usuário agora pode acessar, modificar ou destruir seu sistema.

Você nem mesmo terá uma trilha de auditoria cujos arquivos foram alterados dessa forma, pois você só verá ele editando sua configuração do Apache nas mensagens do log do sudo. Este é um risco de segurança ao conceder sudo privileges a qualquer editor.

Esse é mais ou menos o mesmo motivo pelo qual a concessão de direitos de nível raiz sudo a comandos como tar e unzip geralmente é insegura, nada impede que você inclua substituições para binários do sistema ou arquivos de configuração do sistema no archive. / p>

Um segundo risco, como muitos outros comentaristas apontaram, é que vim permite escapes de shell , onde você pode iniciar um sub-shell de dentro do vim que permite executar qualquer comando arbitrário . Dentro da sessão do sudo vim, eles serão executados como root, por exemplo, o shell escape:

• :!/bin/bash lhe dará um shell de raiz interativo
• :!/bin/rm -rf / fará boas histórias no pub.

O que fazer em vez disso?

Você ainda pode usar sudo para permitir que os usuários editem arquivos que não possuem de maneira segura.

Na sua configuração de sudoers, você pode definir um comando reservado especial sudoedit seguido do nome completo do caminho (curinga) para o (s) arquivo (s) que um usuário pode editar:

user ALL=(ALL) sudoedit /etc/httpd/conf/httpd.conf /etc/httpd/conf.d/*.conf

O usuário pode então usar a opção -e em sua linha de comando sudo ou usar o comando sudoedit :

sudo -e /etc/httpd/conf/httpd.conf
sudoedit /etc/httpd/conf/httpd.conf

Como explicado na página do manual :

The -e (edit) option indicates that, instead of running a command, the user wishes to edit one or more files. In lieu of a command, the string "sudoedit" is used when consulting the security policy.
If the user is authorized by the policy, the following steps are taken:

• Temporary copies are made of the files to be edited with the owner set to the invoking user.
• The editor specified by the policy is run to edit the temporary files. The sudoers policy uses the SUDO_EDITOR, VISUAL and EDITOR environment variables (in that order). If none of SUDO_EDITOR, VISUAL or EDITOR are set, the first program listed in the editor sudoers(5) option is used.
• If they have been modified, the temporary files are copied back to their original location and the temporary versions are removed.
  If the specified file does not exist, it will be created.
  Note that unlike most commands run by sudo, the editor is run with the invoking user's environment unmodified. If, for some reason, sudo is unable to update a file with its edited version, the user will receive a warning and the edited copy will remain in a temporary file.

O sudoers manual também tem uma seção inteira como ele pode oferecer proteção limitada contra shell escapes com as opções RESRICT e NOEXEC .

restrict Avoid giving users access to commands that allow the user to run arbitrary commands. Many editors have a restricted mode where shell escapes are disabled, though sudoedit is a better solution to running editors via sudo. Due to the large number of programs that offer shell escapes, restricting users to the set of programs that do not is often unworkable.

e

noexec
Many systems that support shared libraries have the ability to override default library functions by pointing an environment variable (usually LD_PRELOAD) to an alternate shared library. On such systems, sudo's noexec functionality can be used to prevent a program run by sudo from executing any other programs. Note, ... ...
To enable noexec for a command, use the NOEXEC tag as documented in the User Specification section above. Here is that example again:
aaron shanty = NOEXEC: /usr/bin/more, /usr/bin/vi
This allows user aaron to run /usr/bin/more and /usr/bin/vi with noexec enabled. This will prevent those two commands from executing other commands (such as a shell).

    

Answer 2

Essa configuração permite que o usuário edite esse arquivo. Para fazer isso, ele inicia um editor vim com direitos de root.

Quando o comando vim for iniciado, o usuário poderá fazer o que quiser com esse editor. - Ele pode abrir um arquivo diferente ou até mesmo iniciar um shell fora do vim.

Portanto, o usuário agora pode visualizar e editar arquivos arbitrários e executar comandos arbitrários em seu sistema.

    

Answer 3

Bloqueios de segurança

Alguns programas, como por exemplo less , vi , vim e more , permitem que outros programas sejam executados a partir de um comando shell - o que é conhecido como Shell Escape ou escape para o interpretador de comandos. Nesses casos, você pode usar NOEXEC para impedir que alguns programas permitam a execução de outros privilégios de programas. Exemplo:

fulano ALL = (ALL) ALL NOEXEC:  /bin/vi, /usr/bin/less, /usr/bin/vim, /bin/more

Isto permitiria ao usuário editar ou assim privilegiar qualquer arquivo no sistema rodando o vim e mais, mas desativa a possibilidade de executar outros programas com privilégios do interpretador de comandos de escape vim .

Importante sudo inclui vários bloqueios de segurança (padrão) que podem impedir tarefas perigosas, como redirecionar a saída padrão da execução de um programa ( STDOUT ) para arquivos fora do diretório pessoal do usuário.

Se definido no arquivo /etc/sudoers que um usuário pode executar com privilégios /usr/bin/vim , ou seja, algo como o seguinte:

fulano ALL = (ALL) /bin/echo, NOEXEC: /bin/vi, /usr/bin/vim, /bin/more, /usr/bin/less

sudo permite que o usuário regular definido possa executar /usr/bin/vim das seguintes maneiras:

sudo /usr/bin/vim
sudo vim

Mas seja impedido de executar o vim da seguinte forma:

cd /usr/bin
sudo ./vim

    

Answer 4

A resposta simples:

O seguinte é um comando do Vim:

:shell

Eles agora têm um shell de raiz.

    

Answer 5

Uma melhoria de segurança incremental possível seria substituir:

user ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf

com

user ALL=(ALL) /usr/bin/rvim /etc/httpd/confs/httpd.conf

e, em seguida, execute o usuário sudo rvim /etc/httpd/confs/httpd.conf .

O Vim suporta um modo restrito acionado com a opção de linha de comando -Z ou iniciando o programa como rvim. Quando o modo restrito é ativado, "todos os comandos que fazem uso de um shell externo estão desativados". Essa abordagem não impediria que o usuário usasse o comando :split file ex para abrir outros arquivos, mas pelo menos deveria evitar comandos do shell deliberadamente maliciosos como :!rm -rf / .

    

Answer 6

Concordo com a resposta de HBruijn de que executar o vim como root abre o sistema muito amplo e o sudoedit seria uma solução mais segura.

Mas, mesmo assim, o seu sistema provavelmente ainda estará bastante aberto. Pelo menos, assumindo que algum processo apache com privilégios de root será lançado com base nessa configuração. Há um milhão de maneiras de configurar o apache de forma que ele execute programas externos. Como um exemplo, considere o argumento pipe para a diretiva CustomLog . O manual afirma explicitamente:

Security:

If a program is used, then it will be run as the user who started httpd. This will be root if the server was started by root; be sure that the program is secure.

Obviamente, se seus usuários puderem escrever a configuração, eles poderão alterar esse programa para qualquer coisa que desejarem, por exemplo, algo que executa um script de shell para conceder mais permissões.

Por esse motivo, eu recentemente hackeei uma maneira de usar recursos de forma que o apache possa obter a capacidade especial de vincular-se a uma porta privilegiada, mesmo que ela seja executada como um usuário normal. Dessa forma, os usuários podem editar a configuração e até mesmo iniciar o servidor, e ainda são mais seguros. O único problema é que eles podem ligar qualquer processo em qualquer IP. Um certo grau de confiança permanece, uma vez que eles podem encontrar uma maneira de travar o sistema sshd, e então lançar sua própria versão na tentativa de obter a senha root.

    

Answer 7

Claro, não é mais seguro. Como dito antes do sudoedit, é a maneira mais fácil e adequada de fazê-lo.

O que eu quero adicionar é que o vim permita o lançamento de um shell, assim, ele não só pode editar qualquer arquivo do sistema, mas também permitir o lançamento de um shell e fazer onde ele quiser.

Apenas tente iniciar um vim e digite: sh

Espero que ajude!