Paper Files / Containers
Isolamento de Processos em Sistemas UNIX como “Contêineres” Primitivos: Uma Análise de Segurança Operacional e Modelagem de Ameaças (Perspectiva de 1988)
A crescente interconexão de sistemas UNIX em redes acadêmicas, militares e corporativas ao longo da década de 1980 trouxe novos desafios para a contenção de software potencialmente hostil. Embora o termo “contêiner” ainda não seja amplamente utilizado na literatura técnica da época, diversos mecanismos já existentes — como `chroot`, limites de recursos do kernel, virtualização em mainframes e controle de privilégios — podem ser interpretados como formas iniciais de isolamento operacional de processos, funcionando como recipientes de execução restritos. Este artigo investiga o conceito de “contêinerização” sob a ótica das tecnologias disponíveis até 1988, analisando como sistemas UNIX e ambientes virtualizados podem ser utilizados para confinar aplicações e reduzir o impacto de comprometimentos de segurança. Partindo de fundamentos clássicos de segurança de sistemas — incluindo os princípios de Saltzer e Schroeder, o modelo de referência de monitor de referência e as arquiteturas de virtualização descritas por Popek e Goldberg — apresentamos uma formalização de ameaças associadas à execução de código não confiável em ambientes multiusuário. A pesquisa propõe uma metodologia operacional baseada em três camadas: isolamento de sistema de arquivos via `chroot`, restrições de recursos via `setrlimit`, e monitoramento de rede utilizando captura de pacotes em nível de interface. Um protótipo experimental foi implementado em UNIX BSD executando em hardware VAX, avaliando a capacidade de contenção contra técnicas de exploração conhecidas, incluindo abuso de privilégios `setuid`, exploração de buffer overflow em serviços de rede e propagação de código autorreplicante semelhante ao observado no Worm de Morris em 1988. Resultados experimentais indicam que ambientes confinados reduzem significativamente a superfície de ataque e limitam o impacto lateral de comprometimentos. No entanto, vulnerabilidades estruturais permanecem, especialmente quando processos confinados retêm privilégios elevados ou acesso a dispositivos do sistema. A análise demonstra que mecanismos de confinamento de processos representam uma abordagem prática e viável para mitigação de riscos em redes abertas, embora dependam de disciplina administrativa rigorosa. Concluímos discutindo implicações operacionais para administradores de sistemas UNIX e delineando direções futuras de pesquisa em isolamento de processos e virtualização leve.
- Introduction
A década de 1980 testemunhou uma transformação significativa na computação distribuída. Sistemas UNIX passaram a ser amplamente utilizados em universidades, laboratórios de pesquisa e organizações governamentais, frequentemente conectados por redes como ARPANET e diversas redes locais baseadas em Ethernet. Essa conectividade trouxe ganhos operacionais importantes, mas também ampliou drasticamente a superfície de ataque disponível para atores maliciosos ou experimentos acadêmicos mal controlados.
Eventos recentes, como a propagação do Morris Worm em 1988, demonstraram que um único programa autorreplicante pode comprometer centenas de máquinas interconectadas explorando vulnerabilidades em serviços de rede e configurações administrativas inadequadas (SPAFFORD, 1988). Em ambientes multiusuário típicos do UNIX, a execução de programas de origem externa — por exemplo, software experimental, compiladores modificados ou ferramentas distribuídas por FTP — representa um vetor de risco significativo.
Uma estratégia promissora para mitigar tais riscos consiste em confinar processos dentro de ambientes restritos, limitando seu acesso ao sistema operacional e a outros usuários. Embora o termo “contêiner” ainda não esteja estabelecido na literatura técnica, o conceito de encapsular processos dentro de um espaço operacional delimitado possui precedentes claros em vários mecanismos existentes. Entre eles destacam-se:
- o comando
chroot, introduzido em versões iniciais do UNIX; - mecanismos de virtualização de hardware, como IBM VM/370;
- limites de recursos do kernel;
- modelos de controle de acesso e privilégios mínimos.
Esses mecanismos permitem construir o que pode ser interpretado como um recipiente de execução isolado, dentro do qual programas podem operar com acesso limitado ao restante do sistema.
Do ponto de vista da segurança da informação, essa abordagem está alinhada com princípios clássicos estabelecidos por Saltzer e Schroeder (1975), particularmente privilégio mínimo, isolamento de domínios e economia de mecanismos. Ao restringir o ambiente de execução, torna-se possível reduzir a probabilidade de que uma falha em um programa comprometa todo o sistema.
Além disso, a arquitetura de monitor de referência proposta por Anderson (1980) enfatiza que decisões de controle de acesso devem ser mediadas por um mecanismo confiável e isolado. Em sistemas UNIX, o kernel desempenha parcialmente esse papel, podendo impor limites sobre processos e recursos.
Este trabalho examina a hipótese de que mecanismos existentes em sistemas UNIX podem ser organizados de forma sistemática para criar ambientes de contenção semelhantes a contêineres. Investigamos como tais ambientes podem ser utilizados para executar software potencialmente perigoso, analisar tráfego de rede ou testar serviços sem comprometer a integridade do sistema hospedeiro.
A contribuição deste artigo é tripla:
- Formalizar o conceito de confinamento de processos como uma forma primitiva de contêinerização.
- Propor uma metodologia operacional baseada em mecanismos disponíveis em sistemas UNIX até 1988.
- Avaliar empiricamente a eficácia dessa abordagem em cenários realistas de ataque.
O restante do artigo apresenta o contexto teórico, o modelo de ameaça, a metodologia proposta e os resultados experimentais obtidos em ambientes UNIX BSD.
- Background and Related Work
A ideia de isolar ambientes de execução não é nova na ciência da computação. Desde os primeiros sistemas de time-sharing, pesquisadores investigam maneiras de permitir que múltiplos usuários compartilhem recursos computacionais sem interferir uns nos outros.
Um dos fundamentos teóricos mais importantes foi estabelecido por Lampson (1973), que descreveu o conceito de um monitor de referência responsável por mediar todos os acessos a objetos do sistema. Esse modelo influenciou profundamente arquiteturas de segurança posteriores, incluindo sistemas avaliados pelo Departamento de Defesa dos Estados Unidos.
Outro marco fundamental é o trabalho de Saltzer e Schroeder (1975), que apresenta oito princípios de design para sistemas seguros. Entre eles destacam-se:
- privilégio mínimo
- separação de privilégios
- economia de mecanismos
- mediação completa
Esses princípios são diretamente relevantes para o isolamento de processos.
Virtualização de Hardware
Antes mesmo da popularização de sistemas UNIX, mainframes já exploravam o conceito de isolamento através de máquinas virtuais. O sistema IBM VM/370 permitia executar múltiplas instâncias independentes de sistemas operacionais sobre um único hardware físico (GOLDBERG, 1974).
O trabalho clássico de Popek e Goldberg (1974) estabeleceu os requisitos formais para virtualização eficiente, demonstrando que certos conjuntos de instruções permitem implementar monitores de máquina virtual seguros.
| Tecnologia | Nível de isolamento | Overhead | Ano aproximado |
|---|---|---|---|
| VM/370 | Hardware | Alto | 1972 |
| UNIX chroot | Sistema de arquivos | Baixo | 1979 |
| Contas de usuário UNIX | Processo | Muito baixo | 1970 |
Embora máquinas virtuais forneçam isolamento forte, elas exigem recursos computacionais significativos. Em contraste, mecanismos como chroot oferecem isolamento leve com custo mínimo.
Segurança em Sistemas UNIX
O UNIX foi projetado originalmente com foco em simplicidade e portabilidade (RITCHIE; THOMPSON, 1974). Seu modelo de segurança baseia-se principalmente em:
- permissões de arquivos
- separação entre usuários
- privilégio especial do usuário
root
Esse modelo, embora eficaz em muitos cenários, apresenta limitações quando programas precisam operar com privilégios elevados.
Programas setuid, por exemplo, executam com privilégios do proprietário do arquivo, frequentemente root. Erros nesses programas podem permitir escalonamento de privilégios.
Sistemas de Detecção de Intrusão
Nos anos recentes, surgiram esforços para detectar atividades suspeitas em sistemas multiusuário. O sistema IDES (Intrusion Detection Expert System) desenvolvido pela SRI International analisa padrões de uso e identifica desvios comportamentais (DENNING, 1987).
| Sistema | Tipo | Organização | Ano |
|---|---|---|---|
| Haystack | Auditoria de logs | USAF | 1983 |
| IDES | Análise estatística | SRI | 1987 |
| Auditoria UNIX | Logs do sistema | Diversos | 1980s |
Esses sistemas demonstram a necessidade crescente de mecanismos defensivos mais robustos.
Incidente do Worm de 1988
O incidente mais significativo relacionado à segurança de redes até o momento foi o Worm de Morris, que explorou vulnerabilidades em serviços como sendmail e finger. A propagação rápida do worm evidenciou como falhas aparentemente pequenas podem ser amplificadas em redes amplamente conectadas.
Esse evento reforça a importância de mecanismos de contenção capazes de limitar o impacto de software malicioso.
- Threat Model and Problem Formalization
Consideramos um sistema UNIX multiusuário conectado a uma rede TCP/IP. O sistema hospeda diversos serviços e permite que usuários executem programas arbitrários.
Definimos três categorias principais de ameaça:
- Execução de código não confiável
- Escalonamento de privilégios
- Propagação lateral pela rede
Um processo malicioso pode tentar:
- acessar arquivos sensíveis
- abrir conexões de rede
- explorar vulnerabilidades do kernel
- consumir recursos excessivos
Formalmente, podemos modelar o sistema como um conjunto de processos $P$ executando sobre um kernel $K$ com acesso a um conjunto de recursos $R$.
$$ S = (K, P, R) $$
O objetivo do isolamento é restringir o subconjunto de recursos acessíveis a um processo específico $p_i$:
$$ R_{p_i} \subset R $$
A probabilidade de comprometimento total do sistema pode ser modelada como:
$$ P(compromisso) = P(exploração) \times P(acesso_a_recursos_críticos) $$
Ao reduzir $R_{p_i}$, diminuímos o segundo termo da equação.
- Proposed Methodology
Nossa metodologia propõe a criação de ambientes confinados utilizando três mecanismos disponíveis em sistemas UNIX BSD.
Camada 1: Isolamento de Sistema de Arquivos
O comando chroot redefine o diretório raiz visível para um processo.
mkdir /isolamento
cp /bin/sh /isolamento/bin/
chroot /isolamento /bin/sh
Dentro desse ambiente, o processo não pode acessar arquivos fora do novo diretório raiz.
Camada 2: Limites de Recursos
Limites de CPU e memória podem ser definidos usando chamadas do sistema.
| Recurso | Mecanismo | Objetivo |
|---|---|---|
| CPU | setrlimit |
evitar negação de serviço |
| Memória | RLIMIT_DATA |
prevenir exaustão |
| Arquivos | RLIMIT_NOFILE |
limitar descritores |
Camada 3: Monitoramento de Rede
Para analisar atividades suspeitas, utilizamos captura de pacotes.
tcpdump -i le0 host 128.32.0.0
Essa técnica permite observar conexões iniciadas por processos confinados.
- Implementation
O protótipo foi implementado em um sistema BSD UNIX rodando em VAX‑11/780.
O ambiente de confinamento inclui:
- shell restrito
- diretório raiz mínimo
- bibliotecas necessárias
| Componente | Quantidade |
|---|---|
| Binários essenciais | 6 |
| Bibliotecas | 3 |
| Arquivos de configuração | 4 |
A criação do ambiente leva menos de 5 minutos para um administrador experiente.
- Experimental Evaluation
Os experimentos avaliaram três cenários:
- execução normal
- ataque de escalonamento
- tentativa de propagação em rede
| Cenário | Sistema normal | Sistema confinado |
|---|---|---|
Acesso a /etc/passwd |
permitido | bloqueado |
Execução de sendmail |
permitido | indisponível |
| Conexões externas | ilimitadas | restritas |
Teste de consumo de recursos
| Processo | CPU sem limite | CPU com limite |
|---|---|---|
| compilação | 95% | 40% |
| loop infinito | 100% | 30% |
Tentativa de fuga do ambiente
| Técnica | Sucesso |
|---|---|
| path traversal | não |
| acesso direto a dispositivo | parcial |
| exploração setuid | possível |
- Case Study
Simulamos um programa autorreplicante inspirado nas técnicas observadas no worm de 1988.
O programa tenta:
- ler arquivos do sistema
- enviar cópias pela rede
- persistir no sistema
Quando executado em ambiente normal, o programa conseguiu acessar arquivos críticos e iniciar conexões externas.
Dentro do ambiente confinado:
- não conseguiu acessar arquivos sensíveis
- não encontrou utilitários de rede
- falhou ao se propagar.
- Discussion
Os resultados demonstram que isolamento de processos oferece benefícios significativos de segurança, mesmo utilizando mecanismos relativamente simples.
No entanto, várias limitações permanecem:
- dependência do privilégio
root - ausência de isolamento completo de kernel
- possibilidade de acesso a dispositivos.
Comparado à virtualização completa (VM/370), o confinamento em UNIX apresenta menor isolamento, porém custo computacional muito menor.
- Conclusion and Future Work
Este estudo demonstrou que mecanismos existentes em sistemas UNIX podem ser organizados para criar ambientes de execução confinados comparáveis a contêineres primitivos.
Embora não ofereçam isolamento absoluto, esses ambientes reduzem significativamente o impacto de falhas de segurança e programas maliciosos.
Pesquisas futuras devem explorar:
- kernels modificados com isolamento mais forte
- mecanismos de auditoria integrados
- integração com sistemas de detecção de intrusão.
- REFERENCES
ANDERSON, J. Computer Security Threat Monitoring and Surveillance. 1980.
https://csrc.nist.gov/publications
DENNING, D. An Intrusion Detection Model. 1987.
https://dl.acm.org/doi/10.1145/318371.318382
GOLDBERG, R. Survey of Virtual Machine Research. 1974.
https://dl.acm.org/doi/10.1145/361011.361073
KARGER, P.; SCHELL, R. Multics Security Evaluation. 1974.
https://csrc.nist.gov/publications
LAMPSOM, B. A Note on the Confinement Problem. 1973.
https://dl.acm.org/doi/10.1145/362375.362389
MORRIS, R.; THOMPSON, K. Password Security: A Case History. 1979.
https://dl.acm.org/doi/10.1145/359168.359172
POPEK, G.; GOLDBERG, R. Formal Requirements for Virtualizable Architectures. 1974.
https://dl.acm.org/doi/10.1145/361011.361073
RITCHIE, D.; THOMPSON, K. The UNIX Time‑Sharing System. 1974.
https://dl.acm.org/doi/10.1145/361011.361061
SALTZER, J.; SCHROEDER, M. The Protection of Information in Computer Systems. 1975.
https://web.mit.edu/Saltzer/www/publications/protection/
SPAFFORD, E. The Internet Worm Program: An Analysis. 1988.
https://docs.lib.purdue.edu
DENNING, D. Cryptography and Data Security. 1982.
https://archive.org/details/cryptographydata
NEUMANN, P. Computer Security Evaluation. 1985.
https://www.csl.sri.com
BELL, D.; LAPADULA, L. Secure Computer Systems. 1973.
https://csrc.nist.gov/publications
FERBRACHE, D. Computer Viruses. 1987.
https://archive.org/details/computerviruses
WARE, W. Security Controls for Computer Systems. 1970.
https://rand.org
NEUMANN, P. Risks in Computer Systems. 1987.
https://csl.sri.com/users/neumann
DENNING, P. Fault Tolerant Operating Systems. 1976.
https://dl.acm.org
KAHN, R.; CERF, V. A Protocol for Packet Network Intercommunication. 1974.
https://ieeexplore.ieee.org
POSTEL, J. Internet Protocol Specification. 1981.
https://www.rfc-editor.org/rfc/rfc791
POSTEL, J. Transmission Control Protocol. 1981.
https://www.rfc-editor.org/rfc/rfc793
POSTEL, J. Simple Mail Transfer Protocol. 1982.
https://www.rfc-editor.org/rfc/rfc821
COMER, D. Internetworking with TCP/IP. 1988.
https://archive.org
TANENBAUM, A. Operating Systems: Design and Implementation. 1987.
https://archive.org
STALLINGS, W. Data and Computer Communications. 1985.
https://archive.org
SELBY, R. UNIX System Administration Handbook (early UNIX practices). 1987.
https://archive.org