Permissões dependendo de como você se autentica: ssh / su / sudo

5

Como user eu tenho acesso a uma máquina Linux remota onde eu posso:

sudo su - other_user

Entre outras coisas, isso me permite adicionar minha própria chave pública a authorized_keys para other_user , o que efetivamente também me deixa ssh nesta máquina como other_user .

O que é interessante é que, como user , não tenho permissão para fazer o seguinte diretamente, já que não (nem eu devo saber)% senha doother_user:

su - other_user

Esta política de segurança faz sentido? Que diferença faz para não saber a senha de other_user se eu puder ssh ou sudo su - em other_user ?

Em geral, quais diferenças existem em termos do que você pode e não pode fazer dependendo de como você faz login como other_user ?

    
por Amelio Vazquez-Reina 12.11.2014 / 17:15

2 respostas

4

Does this security policy make sense?

Sim e não. Não, no sentido de que não protege os dados do other_user. Mas protege a senha do other_user. Isso pode parecer irrelevante, mas isso significa que há pelo menos uma coisa importante que você não pode fazer: alterar a senha para que a pessoa que normalmente usa a conta não possa acessá-la.

Outra consequência de usar su e manter as senhas em segredo é que /var/log/auth.log deve conter coisas como esta:

Nov  8 08:08:10 ...(su:session): session opened for user other_user by (uid=1066)
[...]
Nov  8 09:38:10 ...(su:session): session closed for user other_user
Presumindo que seu uid é 1066 e sua senha também é secreta, se alguma coisa desagradável aconteceu com as coisas de other_user durante esses 90 minutos, há um strong argumento a ser feito de que você fez isso. Fiz lugares de trabalho onde o log em detalhes como esse era usado para identificar pessoas fazendo coisas que sabiam que não deviam fazer.

    
por 12.11.2014 / 17:36
3

Como você só pode executar su - other_user para obter acesso a essa conta, há coisas que você não pode fazer. Você só pode executar o shell de login dessa conta ou programas que o shell de login permite que você execute. Isso não faz diferença se o shell de login for um shell geral como sh ou bash , mas isso acontece se o shell for um shell restrito ou algum tipo de programa de propósito especial.

Supondo que a conta não tenha um shell restrito, você pode adicionar uma chave pública a ~/.ssh/authorized_keys para permitir o login remotamente. O administrador pode desabilitar isso se quiser, seja tornando o diretório pessoal não gravável pelo usuário (o que não é comum em contas de propósito geral, porque é muito inconveniente para o usuário), ou tornando o diretório .ssh immutable, ou através de opções na configuração do servidor.

Como você não sabe a senha, não será possível alterá-la: o comando passwd solicitará a senha atual.

Não saber a senha também significa que o administrador pode revogar seu acesso sem precisar alterar a senha. Eles terão que procurar por backdoors (chave SSH, arquivo setuid), mas eles só precisam verificar os arquivos naquela máquina para isso, o que é possível, ao contrário de fazer você esquecer a senha.

    
por 13.11.2014 / 02:35