Resumo

  • No CTSS descrito por Jerry Saltzer, links nos diretórios dos usuários participavam das restrições de acesso; revogar exigia alcançar o diretório do tomador e auditar significava procurar links pelo sistema.
  • O Multics preservou o link como endereço indireto, mas fez a lista do segmento decidir a permissão. A mudança reduziu a dispersão da autoridade sem apagar cópias nem invalidar automaticamente decisões já guardadas.

Compartilhar é fácil quando basta criar uma entrada. O teste real vem depois: quem consegue retirar o direito? No CTSS, um usuário podia colocar em seu próprio diretório um link para o arquivo original de outra pessoa. O link identificava o arquivo e normalmente acrescentava restrições aos modos de uso. A conveniência deslocava parte da regra para o espaço do tomador.

Saltzer registrou o preço dessa escolha. Depois que o link existia, a revogação dependia de modificar o diretório do outro usuário. A mesma pessoa podia chegar ao mesmo arquivo por nomes diferentes e obter direitos diferentes. Para responder quem ainda tinha acesso, um auditor precisava pesquisar todos os diretórios, trabalho caro que também podia expor nomes e relações sem pertinência para a verificação.

O Multics não eliminou a referência alternativa. Ele retirou dela a faculdade de autorizar. Um link continuava sendo uma forma conveniente de nomear e alcançar um segmento, mas não carregava privilégio. Era somente um endereço indireto. A lista de controle ligada ao segmento respondia se aquele processo podia realizar a operação pedida.

O verbo pertence à decisão

No sistema descrito em 1974, segmentos nomeados organizavam o armazenamento do Multics. Um segmento era unidade de catálogo, de mapeamento na memória virtual e de proteção separada. Cada processo recebia um identificador de principal que não podia forjar. Ao tentar usar um recurso catalogado, o sistema comparava esse identificador com as entradas da lista daquele recurso.

A lista não dizia apenas sim ou não. Leitura, escrita e execução eram modos distintos para segmentos. Filas de mensagens separavam inserir e retirar; diretórios separavam listar, alterar e adicionar. O caminho resolvido respondia qual era o recurso. A política respondia quem queria executar qual verbo.

Essa divisão impedia que um nome alternativo produzisse, por si só, uma autorização alternativa. O responsável pelo recurso podia mudar a lista decisiva sem primeiro recolher todos os atalhos. Para auditar, era possível começar pelo segmento e por suas regras, em vez de tratar cada diretório como esconderijo potencial de um direito.

Ainda havia uma administração sofisticada. Identificadores podiam combinar pessoa, projeto e compartimento. Entradas específicas ganhavam precedência sobre regras amplas. O direito de alterar um diretório também estruturava a autoridade sobre listas nele contidas. O avanço não era ausência de hierarquia, mas um lugar identificável para examinar a hierarquia.

Quando a herança confunde

O artigo de Saltzer relata uma tentativa abandonada dentro do próprio Multics. Em uma versão anterior, a lista inicial do diretório funcionava como apêndice comum das listas de todos os recursos. Uma alteração no padrão superior podia parecer eficiente. Contudo, sua combinação com entradas particulares produzia resultados diferentes de recurso para recurso e tornava difícil prever o efeito de uma mudança.

A solução passou a copiar a lista inicial no momento da criação. Alterar o padrão depois não modificava recursos antigos. Havia menos dinamismo, porém o estado atual de cada recurso ficava mais autocontido. Saltzer descreve o desenho de uma lista como compromisso entre capacidade de expressão, facilidade de entendimento e custo de implementação.

O link sem privilégio segue a mesma disciplina. Permitir condições em todo caminho cria opções locais, mas também cria fontes de verdade concorrentes. Quanto mais lugares puderem conceder algo sem aparecer ao proprietário do recurso, mais difícil será encerrar uma relação ou provar o resultado de uma retirada.

A política nova precisa alcançar a memória antiga

No trabalho posterior com Michael D. Schroeder, a mediação completa aparece entre os princípios de proteção: o acesso precisa ser verificado contra a autoridade. O texto de 1974 introduz a dificuldade dos sistemas contínuos. Quando uma decisão é lembrada para uso futuro, o desenho deve explicar como mudanças de autoridade chegam a essas memórias locais.

Não se deve transformar isso numa afirmação de que a lista era relida a cada byte. Uma verificação ao abrir um arquivo ou mapear um segmento pode gerar um descritor, uma sessão, um mapeamento ou um resultado em cache. Se esse estado permanece válido depois da alteração central, a revogação administrativa ainda não se tornou revogação efetiva.

O comprovante útil liga o principal, o recurso finalmente resolvido, a operação, a versão da regra e o instante da decisão. Também define a duração do estado produzido. O comprovante da retirada é outro: alteração aceita, dependências invalidadas, credenciais ou sessões expiradas e nova tentativa recusada. Contar links removidos não fecha essa cadeia.

O que já saiu não volta

Centralizar a decisão no recurso facilita retirar acesso futuro, mas não recolhe informação divulgada. Saltzer observa que quem pode ler um segmento também pode copiá-lo. Retirar a leitura do original não apaga a cópia. Controlar usos depois de uma entrega autorizada permanecia um problema aberto.

O próprio Multics não aparece como conclusão perfeita. O estudo registra mecanismos incompletos e uma área de maior privilégio ainda grande demais para auditoria confortável. Uma fronteira clara mostra o que precisa ser confiável; não certifica que essa parte esteja livre de defeitos.

Serviços atuais ainda misturam URL compartilhada, alias, identificador persistente e permissão sob a palavra “acesso”. A comparação histórica recomenda quatro inventários: nomes, concessões, usos e propagações de revogação. O link pode continuar resolvendo o recurso. A possibilidade de usá-lo precisa continuar sujeita a uma resposta independente.

Fontes