Resumo

  • O COPS transformou falhas conhecidas do Unix — senhas fracas, permissões abertas demais e arquivos de inicialização expostos — em verificações repetíveis no host local.
  • Seus programas configuráveis relatavam possíveis problemas, mas não os corrigiam. A maioria não precisava de root; a busca mais abrangente por arquivos SUID era separada e exigia privilégio.
  • Um relatório sem alertas descrevia as verificações configuradas e o que alcançaram naquele momento. Não certificava segurança completa nem garantia que o host permaneceria igual.

Repetir a busca por falhas comuns

O artigo de 1990 parte de uma observação prática: a literatura de segurança Unix voltava aos mesmos problemas. Programas SUID, permissões abertas demais e senhas fracas muitas vezes eram simples de corrigir depois de encontrados. O trabalho difícil era procurá-los de novo em instalações que mudavam. Farmer e Spafford queriam tornar essa inspeção repetível.

COPS significa “Computerized Oracle and Password System”, mas não era um scanner de rede. Um script principal reunia a saída de cerca de uma dúzia de subprogramas e a enviava por e-mail ao administrador local ou a gravava em arquivo. A maioria usava Bourne shell e comandos comuns do Unix; pequenos programas em C completavam o conjunto. Cada parte podia ser configurada ou substituída conforme a instalação.

As verificações miravam superfícies administrativas concretas: arquivos e diretórios configurados como graváveis por qualquer pessoa; senhas iguais ao nome de usuário ou formadas por palavras comuns; problemas nos registros de contas e grupos; arquivos graváveis chamados por cron ou scripts de inicialização; permissões de alguns dispositivos; diretórios pessoais e arquivos de configuração; umask do root e caminhos de busca que incluíssem o diretório atual. suidchk comparava o conjunto de arquivos SUID com uma execução anterior. Kuang aplicava regras para examinar se um usuário poderia chegar à condição de comprometer a conta-alvo.

Esse escopo explica melhor o valor do COPS do que chamá-lo de “scanner de segurança”. Ele reduzia o custo de repetir um conjunto conhecido de verificações locais; não cobria todo defeito possível nem decidia se cada permissão contrariava a política do site.

O relatório não virava correção automática

Os autores escolheram que o COPS informasse sem alterar o host. Duas instalações parecidas em hardware e versão do Unix podem atender trabalhos diferentes, guardar outros dados e exigir acessos distintos. Uma configuração aceitável em uma pode ser inaceitável em outra. Corrigir automaticamente converteria um achado técnico em decisão de política, sem que o programa tivesse contexto para isso.

A mesma cautela aparecia no uso de privilégios. O artigo diz que, fora a busca SUID, as ferramentas não deveriam ser executadas como root. A busca era normalmente separada porque podia demorar e precisava alcançar diretórios inacessíveis a usuários comuns. Isso reduzia os privilégios da inspeção rotineira, mas fazia a cobertura do relatório depender de como cada componente era executado.

O artigo recomenda execuções regulares por at ou cron, pois uma condição ausente hoje pode surgir depois. Agendar não garante cobertura completa. Um verificador ou uma lista de caminhos alterada pode produzir resultados enganosos; invasores podem ler relatórios ou modificar a ferramenta; resultados limpos repetidos podem gerar complacência. Mudanças no funcionamento do sistema também podem criar falhas que as verificações existentes não contemplam.

O que os dados sustentam

Farmer e Spafford receberam comentários de locais acadêmicos, governamentais e comerciais. Relataram problemas capazes de comprometer root em mais da metade dos sistemas testados ou descritos nesses comentários, mas disseram não saber se essa observação limitada podia ser generalizada para uma população maior. Não é uma estimativa de prevalência para Unix.

COPS e o SATAN posterior de Farmer observavam superfícies distintas: COPS examinava contas, arquivos, permissões e inicialização locais; SATAN verificava serviços de rede e a exposição visível a outros hosts. O autor em comum não torna os relatórios equivalentes.

A Nota 65 de Heng Lu serve apenas como lente editorial: afirmações sobre um sistema em execução devem ficar dentro do que os testes observaram. Para o COPS, isso exige perguntar quais verificações rodaram, com que acesso, em quais caminhos e quando. A automação ajuda a repetir uma lista; o operador continua responsável por definir o escopo, proteger os relatórios, interpretar os achados e escolher as correções.

Fontes