É seguro deixar um shell raiz em execução na sessão de tela desanexada?

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

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

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

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

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

Se você possui um shell raiz em uma sessão de tela (desanexada ou não, protegida por senha ou não) e seu screenexecutável não é setxid, um invasor que obtém seus privilégios pode executar comandos nesse shell. Se nada mais, eles podem fazer isso rastreando o processo da tela.

Se a tela for setuid ou setgid e a sessão for desanexada e protegida por senha, em princípio, será necessária a senha da tela para executar comandos nesse shell. Se esse princípio for válido, alguém que apenas comprometeu sua conta teria que colocar um cavalo de Troia no lugar e esperar que você digite a senha. No entanto, a superfície de ataque (ou seja, o número de lugares 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 em:

• para obter a senha correta.
• tela para impedir o acesso à sessão por outros meios.
• tela para usar os mecanismos de controle de acesso do SO corretamente (por exemplo, permissões nos tubos).
• o kernel para executar as verificações de segurança do ptrace corretamente (essa é uma fonte frequente de vulnerabilidades).
• o shell em execução para não fazer nada estúpido.
• algum outro recurso para não morder você.

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

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

printf '\ekfoo\017bar\e\\' >/dev/pts/33
printf '\e[21t' >/dev/pts/33

Isso insere ␛]lfoobar␛lno fluxo de entrada do shell. \eké a sequência de controle que permite que um aplicativo (ou qualquer coisa que possa gravar no dispositivo do terminal) defina o título da janela (consulte a seção “Nomeando janelas” no manual da tela ) e \e[21tfaz com que o terminal relate seu título na entrada padrão do aplicativo ( A tela não documenta essa sequência, mas a implementa; você pode encontrá-la CSI Ps ; Ps ; Ps ; tna lista de seqüências de controle xterm.De fato, pelo menos na tela 4.0.3, todos os caracteres de controle são removidos do título relatado, para que o shell leia lfoobar(supondo que ␛]não esteja vinculado a um comando de edição) e nenhuma nova linha.Portanto, o invasor não pode realmente executar um comando dessa maneira, mas pode preencher um comando comochmod u+s /bin/sh seguido por muitos espaços e um prompt de aparência provável.

Screen implementa várias outras seqüências de controle de risco semelhantes, não sei qual é a potencialidade delas para vulnerabilidades. Mas espero que agora você possa ver que a proteção oferecida pelas senhas das sessões de tela não é tão boa. Uma ferramenta de segurança dedicada, como o sudo, tem muito menos chances de ter vulnerabilidades.

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