Resumo

  • O RFC 2307 propôs representar no LDAP contas e grupos Unix, além de recursos de rede. A classe posixAccount incluía uidNumber, o inteiro consultado pelas funções do sistema.
  • A seção de segurança do RFC identificou o resultado de uma permissão de escrita mal atribuída: quem pudesse alterar uidNumber poderia tornar sua conta equivalente à do superusuário.

A consulta começa com um número

Um processo Unix não pede ao diretório uma biografia. Ele entrega um inteiro à biblioteca C e espera receber a ficha de conta associada. O RFC 2307 usa getpwuid() como exemplo: a função converte um ID de usuário em nome de login. Na proposta LDAP, a consulta procura um posixAccount cujo uidNumber corresponde ao número recebido.

Parece um campo de cadastro. O sistema o trata como identidade.

Antes de o LDAP entrar nessa história, redes Unix podiam compartilhar contas e dados de máquinas pelo Network Information Service (NIS). O guia administrativo da Sun descreve mapas NIS como tabelas de duas colunas, com uma chave e um valor. Cada domínio tem um servidor mestre que mantém os mapas; servidores escravos guardam cópias; os clientes consultam um ou outro. passwd.byname encontra a conta pelo nome, enquanto passwd.byuid usa o ID como chave. O administrador gera os mapas a partir de arquivos locais no mestre e propaga os resultados aos escravos.

Uma alteração em arquivo local podia, assim, virar uma resposta de rede. Mude a entrada, reconstrua o mapa e a nova versão fica disponível aos clientes do domínio. O código de consulta não decide se o número faz sentido. Ele usa o que recebeu.

O manual SunOS de 1999 registra um desvio de marca: NIS se chamava antes Sun Yellow Pages, mas manteve a mesma funcionalidade depois da troca de nome. O rótulo mudou; os mapas de contas continuaram tendo efeito.

O LDAP mudou o diretório, não a regra de escrita

A especificação LDAPv3 de 1997 definiu um modo de acessar diretórios baseados em X.500 sem os recursos exigidos pelo protocolo DAP completo. Três meses depois, o RFC 2307, intitulado An Approach for Using LDAP as a Network Information Service, propôs classes e atributos LDAP para dados de Unix e TCP/IP.

A lista ia muito além de nomes de máquinas: incluía usuários e grupos, serviços e números de protocolo, identificadores RPC, parâmetros de inicialização, endereços de rede e grupos NIS. Um posixAccount podia conter nome de login, nome de exibição, uidNumber, gidNumber, diretório pessoal e shell. O RFC também mostra uma linha semelhante à de um arquivo de senhas representada por atributos de diretório.

A integração tinha uma razão prática. Aplicativos Unix já pediam contas à biblioteca C; o sistema poderia direcionar essa consulta a um diretório de rede em vez de a um arquivo local. A seção de implementação do RFC descreve um servidor NIS baseado em LDAP, uma implementação de referência da resolução na biblioteca C e scripts para converter arquivos como /etc/passwd e /etc/hosts em registros LDAP.

O texto não exigiu que todos os sistemas Unix migrassem. Foi publicado como Experimental e propôs uma abordagem para serviços de nomes organizacionais. O RFC afirma que o mecanismo já havia sido implementado com algum sucesso, sem contar instalações nem medir adoção.

O número era a fronteira de autoridade

A seção de segurança do RFC 2307 fala sem rodeios sobre o poder de um atributo de diretório. Ela diz que somente administradores devem modificar as entradas de esquema ligadas ao sistema operacional. Em seguida explica o motivo: se um usuário pudesse mudar seu uidNumber, poderia comprometer a segurança ao tornar sua conta equivalente à do superusuário.

O RFC descreve o risco sob uma condição e aponta o controle: o direito de escrita. O software Unix associa o número a uma conta; o diretório pode publicar essa associação para muitos clientes; quem controla as alterações pode mudar a identidade que eles veem. O esquema define a forma do campo. A regra de acesso decide quem pode alterar seu efeito.

A mesma seção identifica outro choque entre consulta e privilégio. Deixar hashes de senhas, como os produzidos por crypt(), disponíveis a usuários sem privilégios pode facilitar ataques de dicionário e força bruta. O RFC apresenta essa prática como compatibilidade com sistemas Unix existentes e recomenda um serviço forte de autenticação quando a segurança for importante. Um diretório compartilhado simplifica as consultas, mas pode ampliar o número de clientes com acesso a material sensível.

As fontes demonstram a proposta e os riscos que ela própria registrou; não medem a adoção do mapeamento LDAP. A nota de implementação do RFC prova que houve uma implementação, mas este conjunto de fontes não mostra quantos sistemas Unix usaram o esquema.

A mudança importante não foi a inclusão de um esquema no banco de dados. Foi o sistema operacional aceitar que uma resposta de rede resolvesse uma pergunta local. uidNumber podia ser uma coluna; era o processo que interpretava o valor que lhe dava força. Sair de /etc/passwd para NIS ou LDAP também deslocava o ponto de controle: o administrador precisava saber qual fonte valia, quais réplicas tinham o mapa mais recente e quem podia editar a identidade.

Fontes