É seguro deixar um shell de root em execução na sessão de tela separada?

Question

Estou curioso sobre a segurança de deixar um shell de root em execução dentro de uma sessão de tela desanexada. Eu normalmente nunca faço isso.

Além do potencial da minha conta de usuário não-root ser comprometida (senha exposta, chave ssh comprometida, etc), existem outros vetores de entrada em uma sessão de tela separada, protegida por senha, com a qual eu deveria me preocupar, ou uma sessão de tela separada é considerada inerte?

    

Answer 1

Acho que é um problema de segurança, porque "Além do potencial da minha conta de usuário não raiz ser comprometida" pode ser bastante grande.

Mas há outros riscos maiores além disso. Por exemplo, você agora se abriu para uma exploração teórica que permite alterar as permissões no diretório do soquete da tela ( /var/run/screen no meu sistema, mas às vezes /tmp é usado). Essa exploração agora tem um caminho para a obtenção do root, o que, de outra forma, não seria possível.

sudo tem outras vantagens, se você puder treinar para usá-lo para cada comando, em vez de usar sudo su - . Ele registra ações (que, a menos que você esteja registrando remotamente, não aumentam significativamente a segurança, mas fornecem uma pista do que você fez). E ajuda a evitar acidentes, exigindo escalada intencional para cada comando, em vez de mudar para uma sessão totalmente privilegiada.

    

Answer 2

Se você tiver um shell de raiz em uma sessão de tela (desconectado ou não, protegido por senha ou não) e seu executável screen não for setxid, um invasor que obtiver seus privilégios poderá executar comandos nesse shell. Se nada mais, eles podem fazê-lo rastreando o processo da tela.

Se a tela é setuid ou setgid, e a sessão é separada e protegida por senha, então, em princípio, é necessária a senha da tela para executar comandos nesse shell. Se esse princípio valer, alguém que tenha comprometido sua conta apenas teria que colocar um trojan no lugar e esperar que você digitasse a senha. No entanto, a superfície de ataque (ou seja, o número de locais onde as coisas podem dar errado devido a um bug ou configuração incorreta) é desconfortavelmente grande. Além dos recursos básicos de segurança do sistema, você confia:

• tela para verificar corretamente a senha.
• tela para impedir o acesso à sessão por outros meios.
• tela para usar os mecanismos de controle de acesso do sistema operacional corretamente (por exemplo, permissões nos canais).
• o kernel executa as verificações de segurança ptrace corretamente (essa é uma fonte freqüente de vulnerabilidades).
• o shell em execução não faz nada estúpido.
• algum outro recurso para não morder você.

"Alguma outra característica para não morder você": sim, isso é vago. Mas é sempre uma preocupação em segurança. Você pode ser tentado a descartar isso como apenas um simples pensamento positivo, mas você realmente pensou em tudo? Por exemplo…

Contanto que você possa escrever no dispositivo de terminal, você pode injetar dados na entrada desse shell. Sob a configuração padrão da tela na minha máquina:

printf '\ekfoo7bar\e\' >/dev/pts/33
printf '\e[21t' >/dev/pts/33

Isso insere ␛]lfoobar␛l no fluxo de entrada do shell. \ek é a sequência de controle que permite que um aplicativo (ou qualquer coisa que possa gravar no dispositivo terminal) defina o título da janela (consulte o seção" Nomeando janelas "no manual da tela , e \e[21t faz o terminal reportar seu título na entrada padrão do aplicativo (a tela não documenta essa sequência, mas não implementá-lo, você pode encontrá-lo em CSI Ps ; Ps ; Ps ; t na lista de sequências de controle xterm . Pelo menos na tela 4.0.3, todos os caracteres de controle são removidos do título relatado, portanto, o shell lê lfoobar (assumindo que ␛] não está vinculado a um comando de edição) e não há nova linha. comando dessa forma, mas pode encher um comando como chmod u+s /bin/sh seguido por um monte de espaços e um prompt de aparência provável.

A tela implementa várias outras sequências de controle de risco similares, não sei qual é a sua potencialidade para vulnerabilidades. Mas esperamos que agora você possa ver que a proteção oferecida pelas senhas da sessão de tela não é tão boa assim. Uma ferramenta de segurança dedicada, como o sudo, tem muito menos probabilidade de ter vulnerabilidades.

    

Answer 3

Os canais criados pela tela só são acessíveis pelo proprietário, portanto, isso não deve ser um problema de segurança.