Configurar o shell de um usuário de email como / usr / bin / passwd no arquivo / etc / passwd é uma maneira segura de permitir que ele altere sua própria senha simplesmente ssh'ing?

Question

Eu tenho uma máquina que é usada principalmente como um servidor de e-mail:

$ uname -a Linux myhost.com 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

e gostaria que os usuários que realmente não fazem login na máquina (mas a usam para autenticar e obter seus e-mails) possam alterar suas próprias senhas. Se eu colocar / usr / bin / passwd em / etc / shells (então o comando passwd é um shell válido), e mude a entrada do shell para os usuários como em:

someuser:x:557:557:Some User:/home/someuser:/usr/bin/passwd

se forem ssh para o host, eles receberão algo assim:

$ ssh myhost.com
[email protected]'s password: <type their current password>
Last login: Wed Sep 25 16:07:35 2013 from some-ip
Changing password for user someuser.
Changing password for someuser.
(current) UNIX password: <type their current password again>
New password: <type their new password>
Retype new password: <type their new password again>
-passwd: all authentication tokens updated successfully.
Connection to myhost.com closed.

que funciona muito bem ... mas é seguro? A sua maneira de explorar isso e invadir uma verdadeira concha?

Obrigado.

P.S. No meu ambiente, é razoável supor que os usuários já tenham o ssh - mas se houver uma alternativa para a mudança de senha que seja simplesmente "melhor", eu gostaria de ouvi-la:)

    

Answer 1

Permitir que um programa conhecido (ssh) de acesso remoto a um programa suid seja, em princípio, inseguro. passwd define o ID do usuário, ou seja, eleva as permissões. O ssh deve ser usado com cuidado, pois ele também delega a administração do firewall ao usuário remoto (encaminhamento de porta, etc.). Se o sshd é sua única opção de acesso remoto, você tem apenas um servidor, e você insiste em usar este servidor como meio de alterar senhas e servir e-mails, limitar todas as opções apenas para sshd e mail e endurecer o resto da caixa removendo tudo, exceto os serviços que você precisa: troca de e-mails e senhas.

A fonte do passwd está sob escrutínio, mas você conhece o hack de login clássico feito por Ken Thompson (criador do unix) no compilador C? Leia as Reflexões sobre Confiança Confiável de Ken para decidir em quem confiar.

link

    

Answer 2

Eu gosto de resposta @ datasmid, faz alguns bons pontos.

Parece-me que o que você está fazendo é equivalente a permitir aos usuários um prompt de shell e acessar o comando passwd .

Se você estiver confortável fazendo isso, então não vejo razão para você não fazer o que está fazendo. Se alguma coisa, é um pouco mais seguro, pois você não está permitindo que o usuário execute qualquer outro comando com facilidade.

Não haveria uma maneira de sair do comando passwd para um shell, a menos que passwd faça alguma provisão para exec ing em um shell. Eu não vejo por que isso aconteceria. Provavelmente você pode pesquisar facilmente o código fonte de passwd para isso.

Uma coisa que um invasor pode tentar, se já tiver uma senha local, é sobrecarregar o buffer passwd digitando uma resposta insanamente longa aos prompts do passwd . Nesse caso, tudo pode ser possível (os riscos podem ser atenuados pela execução em uma CPU que tenha suporte a XD / NX e randomização de endereço de heap). Eu não sei o que o passwd faz se o buffer de entrada for excedido, mas essa é a primeira coisa que me vem à mente. passwd é um programa setuid mas eu espero (não verifiquei a origem) que ele descarta privilégios uma vez que ele descobre que seu euid não é 0 ANTES de verificar a entrada.