NIS: qual mecanismo oculta shadow.byname para usuários não privilegiados?

Question

Em alguma caixa do Linux (SLES 11.1) que é um cliente NIS, eu posso fazer como root:

ypcat shadow.byname

e obter saída, ou seja, algumas linhas com as senhas criptografadas, entre outras informações.

Na mesma caixa do Linux, se eu executar o mesmo comando que o usuário não privilegiado, obtenho

No such map shadow.byname. Reason: No such map in server's domain

Agora estou surpreso. Meu bom e velho conhecimento diz que as senhas shadow no NIS são absurdas porque não há controle de acesso ou autenticação no protocolo e, portanto, todo usuário (sem privilégios) pode acessar o mapa de sombra e, assim, obter as senhas criptografadas.

Obviamente, temos uma imagem diferente aqui. Infelizmente não tenho acesso ao servidor NIS para descobrir o que está acontecendo. Meu único palpite é que o mestre do NIS fornece o mapa apenas para a conexão de clientes de uma porta privilegiada (> 1024), mas isso é apenas uma suposição ignorante.

Quais mecanismos existem nas implementações atuais do NIS para levar a um comportamento como o descrito acima? Quão "seguros" são eles? O que pode ser contornado facilmente? Ou as senhas shadow no NIS são tão seguras quanto os arquivos shadow antigos?

    

Answer 1

O acesso a mapas não legíveis sob /var/yp/{domainname}/ no mestre NIS é restrito a clientes que fazem solicitações de porta privilegiada (< 1024). Não é tão seguro quanto o local /etc/shadow , mas ainda é um pouco melhor que nada.

Para uma melhor segurança, o Sun projetou o NIS +, mas ele nunca foi amplamente adotado.

O LDAP é muito melhor, onde o hash da senha não precisa ser buscado do servidor para o cliente, mas, em vez disso, o cliente envia a senha proposta para o servidor para verificação (LDAP auth-bind).