Possível problema de segurança com o NIS, ou sou apenas mal-entendido?

Question

Estou trabalhando em uma máquina virtual que pode se comunicar com o servidor NIS da minha organização. Eu não tenho muita experiência com isso, mas notei que posso me tornar outro usuário do meu host sem a senha de root no servidor NIS . Na verdade, o prompt abaixo não me pede uma senha. O comportamento também é um pouco estranho; talvez alguém possa explicar por que não funciona sem sudo mesmo sendo root.

[root@unsecurehost ~]# su - myusername
su: user myusername does not exist

[root@unsecurehost ~]# sudo su - myusername
Last login: Mon Feb 12 19:24:17 UTC 2018 on pts/0
Last failed login: Mon Feb 12 19:28:13 UTC 2018 on pts/0
There were 2 failed login attempts since the last successful login.
su: warning: cannot change directory to /network/path/home/myusername: No such file or directory
-bash-4.2$ id
uid=012345(myusername) gid=0123(companyname) groups=0123(companyname),9999(othergroupname) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Meus uid , gid e groups estão corretos.

Normalmente, penso nisso como um não problema, mas ele tenta acessar /network/path/home/myusername , que é meu diretório pessoal (em rede). Eu não tenho esse armazenamento montado, mas é possível que eu faça isso nesse host.

Eu configurei apenas o arquivo yp.conf , que pode ser lido por qualquer um em nossas máquinas, e execute ypbind .

Seria possível explorar isso? Alguns usuários têm informações confidenciais aqui, e se eu puder me tornar outro usuário e acessar arquivos, isso é uma falha de segurança. Eu não tentei isso em uma situação real ainda porque eu gostaria de acreditar que não é possível (talvez o armazenamento em rede não permitiria isso, ou o campo "contexto" tem alguma importância?). Isso não seria um problema muito grande agora, mas estamos trabalhando em máquinas virtuais que permitem administradores de usuários, o que poderia permitir que qualquer um de nossos usuários se tornasse root.

Por favor, deixe-me saber o que está acontecendo aqui.

    

Answer 1

O que você demonstrou não é um problema.

Você não obteve "tokens de acesso" do NIS. A única informação que você obteve é os mesmos campos existentes em /etc/passwd - UID, GID, shell de login, diretório inicial - e a única coisa que você fez foi dizer ao sistema operacional para definir seu UID como 012345.

Você pode facilmente fazer o mesmo, mesmo sem NIS, apenas criando uma conta local com o mesmo UID.

No entanto, isso não concede necessariamente acesso a outras máquinas na rede. Apenas saber que seu UID não é suficiente para autenticar em outros sistemas e saber onde o diretório inicial não significa que você será capaz de acessá-lo.

Dito isso, há uma grande exceção: NFS.

O que você não demonstrou pode ser o verdadeiro problema.

perhaps the networked storage would not allow this

Essa é a pergunta mais importante aqui - depende do protocolo usado para acessar o armazenamento em rede e de como o servidor de armazenamento está configurado.

A maioria dos protocolos de rede (modernos) sempre exigem que o cliente seja autenticado. Por exemplo, o servidor de armazenamento pode exigir uma senha, um certificado ou um tíquete do Kerberos - essas informações não podem ser obtidas por meio do NIS.

No entanto, NFS em sua configuração padrão (auth = sys) é uma exceção - na verdade confia cegamente no UID enviado pelo cliente. Se o cliente disser que está enviando uma solicitação em nome do UID 12345, ele poderá acessar os arquivos de propriedade do UID 12345, sem problemas.

Portanto, observe com cuidado o método usado para montar o armazenamento em rede. Se é NFS sem qualquer especificação auth =, então o seu servidor de arquivos está aberto - e não é culpa do NIS.

Outra exceção semelhante é rsh & rcp, que também confia em nomes de usuários enviados pelo cliente, mas esperançosamente ninguém usa mais esses protocolos. Enquanto isso, o NFS com auth = sys ainda é muito popular.

    

Answer 2

O NIS existe sob a premissa de que todos os sistemas participantes são confiáveis - ou seja, o administrador do sistema, que permitiu que você sudo su soubesse o que estava fazendo.

Não há proteção (como em qualquer sistema) contra um usuário administrador invasor.