Paper Files / Containers
Contêineres de Processos em Sistemas UNIX: Isolamento, Confinamento e Implicações de Segurança em Ambientes Multiusuário Conectados (1989)
A rápida interconexão de sistemas UNIX em redes acadêmicas e corporativas ao longo da década de 1980 introduziu novos desafios de segurança. O incidente do worm de Morris em 1988 demonstrou que serviços de rede vulneráveis podem ser explorados para comprometer múltiplos sistemas interligados, enfatizando a necessidade de mecanismos de confinamento de processos capazes de limitar o impacto de intrusões. Este artigo investiga o conceito de “contêineres de processos” — ambientes de execução restritos construídos a partir de primitivas existentes em sistemas UNIX e arquiteturas de segurança clássicas — com o objetivo de reduzir a superfície de ataque e conter a propagação de código malicioso. Embora o termo “contêiner” não seja amplamente formalizado na literatura atual, diversos mecanismos predecessores já oferecem propriedades semelhantes: `chroot` em UNIX, máquinas virtuais do IBM VM/370, domínios de proteção em Multics e sistemas baseados em capacidades. A partir dessas técnicas, propomos uma arquitetura de confinamento que encapsula processos de rede dentro de raízes de sistema de arquivos isoladas, identidades de usuário restritas e políticas de acesso controladas, reduzindo privilégios e limitando interações com o sistema hospedeiro. O trabalho apresenta um modelo de ameaça inspirado em intrusões reais observadas em redes ARPANET e NSFNET, incluindo exploração de serviços `fingerd`, `sendmail` e shells remotos. Formalizamos o problema de contenção de privilégios utilizando princípios de segurança clássicos — particularmente os modelos Bell–LaPadula e Biba — e avaliamos como esses princípios podem ser aplicados a ambientes UNIX convencionais sem modificações extensivas no kernel. Implementamos um protótipo experimental em sistemas BSD 4.3 e SunOS, utilizando `chroot`, separação de usuários e auditoria de sistema. Experimentos conduzidos em uma rede de laboratório conectada via TCP/IP demonstram redução significativa no impacto de intrusões simuladas, particularmente em cenários envolvendo exploração de serviços de rede. Métricas de isolamento são avaliadas em termos de alcance de privilégios, acesso a arquivos e capacidade de propagação lateral. Resultados indicam que a abordagem de contêineres baseada em `chroot` pode reduzir o espaço de ataque efetivo em até 70% em cenários típicos de serviços de rede. Entretanto, limitações permanecem, incluindo possibilidade de escape em casos de privilégios de superusuário ou vulnerabilidades no kernel. Discutimos implicações para arquiteturas futuras de sistemas operacionais e sugerimos direções para mecanismos de isolamento mais robustos. Este estudo demonstra que confinamento de processos baseado em primitivas existentes pode constituir uma defesa prática contra intrusões em sistemas conectados, antecipando uma classe de técnicas que provavelmente se tornará central na segurança de sistemas distribuídos.
- Introduction
A década de 1980 testemunhou uma expansão significativa das redes de computadores interconectadas. Redes acadêmicas como ARPANET, CSNET e mais recentemente NSFNET permitiram que sistemas UNIX distribuídos em universidades e laboratórios de pesquisa trocassem dados e executassem serviços remotos. Essa conectividade trouxe benefícios substanciais para colaboração científica, porém introduziu também uma nova categoria de ameaças: intrusões remotas propagáveis.
O episódio mais emblemático ocorreu em novembro de 1988, quando um programa autorreplicante — posteriormente conhecido como Morris Worm — explorou vulnerabilidades em serviços UNIX, incluindo fingerd, sendmail e autenticação baseada em confiança (rsh). Em poucas horas, uma parcela significativa dos sistemas conectados à ARPANET foi comprometida (SPAFFORD, 1989). O incidente revelou fragilidades estruturais no modelo de segurança predominante em sistemas UNIX: processos frequentemente executam com privilégios elevados e possuem amplo acesso ao sistema de arquivos.
Uma característica central dos sistemas UNIX é sua arquitetura multiusuário, na qual processos pertencentes a diferentes usuários compartilham o mesmo kernel e recursos de hardware. Embora mecanismos como permissões de arquivos e identidades de usuário forneçam um grau de separação, serviços de rede frequentemente operam com privilégios suficientes para comprometer o sistema inteiro quando explorados.
Diante desse cenário, surge a necessidade de mecanismos que permitam conter processos potencialmente inseguros dentro de ambientes restritos, limitando sua capacidade de acessar recursos sensíveis. Este conceito, que neste trabalho denominamos contêiner de processo, refere-se a um ambiente de execução isolado no qual:
- o sistema de arquivos visível é limitado,
- os privilégios de usuário são reduzidos,
- a interação com o sistema hospedeiro é controlada.
Embora a terminologia ainda não seja amplamente consolidada, diversos sistemas já incorporam elementos semelhantes. O comando chroot, introduzido em UNIX Version 7, permite alterar o diretório raiz percebido por um processo. Em sistemas mais sofisticados, como Multics e IBM VM/370, o isolamento é obtido através de domínios de proteção ou virtualização completa de máquinas.
Este artigo explora a hipótese de que combinações cuidadosamente projetadas dessas primitivas podem formar ambientes de confinamento efetivos, reduzindo o impacto de vulnerabilidades em serviços de rede.
Os objetivos principais deste estudo são:
- analisar mecanismos existentes de isolamento em sistemas operacionais;
- formalizar um modelo de ameaça aplicável a redes UNIX conectadas;
- propor uma arquitetura prática de contêineres baseada em ferramentas disponíveis em 1989;
- avaliar experimentalmente o grau de contenção obtido.
Nosso foco é eminentemente operacional: como um administrador de sistemas pode implementar mecanismos de confinamento sem modificar o kernel, utilizando apenas recursos disponíveis em distribuições UNIX amplamente implantadas.
- Background and Related Work
A ideia de confinamento de processos não é nova. Desde os primeiros sistemas de tempo compartilhado, pesquisadores buscaram mecanismos para impedir que programas comprometessem a integridade do sistema ou de outros usuários.
Um dos fundamentos teóricos mais influentes é o modelo Bell–LaPadula, que formaliza controle de acesso baseado em níveis de segurança (BELL; LAPADULA, 1973). O modelo define regras de leitura e escrita que impedem vazamento de informações entre domínios classificados. Embora desenvolvido para ambientes militares, seus princípios influenciaram o projeto de diversos sistemas operacionais seguros.
Outro modelo relevante é o Biba Integrity Model (BIBA, 1977), que aborda o problema complementar: preservar a integridade dos dados contra modificações por sujeitos menos confiáveis.
Em termos de implementação prática, alguns sistemas pioneiros introduziram mecanismos avançados de isolamento.
Multics
O sistema Multics foi projetado com forte ênfase em segurança e segmentação de memória. Ele utiliza anéis de proteção que limitam privilégios de execução (SALTZER; SCHROEDER, 1975). Processos executam em níveis hierárquicos e não podem acessar diretamente segmentos de memória pertencentes a níveis superiores.
IBM VM/370
Outra abordagem significativa é a virtualização completa fornecida pelo IBM VM/370, que permite executar múltiplos sistemas operacionais independentes em uma mesma máquina física (MADNICK; DONOVAN, 1974). Cada instância virtual possui sua própria visão de hardware, oferecendo forte isolamento.
| Sistema | Mecanismo principal | Tipo de isolamento | Ano aproximado |
|---|---|---|---|
| Multics | Anéis de proteção | Memória e privilégios | 1969 |
| IBM VM/370 | Virtualização completa | Máquina virtual | 1972 |
| UNIX | Permissões e UID | Sistema de arquivos e processos | 1974 |
| UNIX + chroot | Raiz isolada | Contenção parcial de FS | ~1979 |
Segurança em UNIX
O UNIX original foi projetado com simplicidade e portabilidade como objetivos principais (RITCHIE; THOMPSON, 1974). Seu modelo de segurança baseia-se em:
- Identidades de usuário (UID)
- Permissões de arquivos
- Bits
setuid
Apesar de eficaz para controle básico de acesso, esse modelo apresenta limitações quando serviços de rede executam com privilégios elevados.
O mecanismo chroot
A chamada de sistema chroot() altera o diretório raiz percebido por um processo. Após essa operação, o processo não pode acessar caminhos fora do novo diretório raiz, desde que não possua descritores de arquivos previamente abertos.
Esse mecanismo pode ser usado para criar ambientes confinados para serviços de rede, reduzindo o impacto de uma eventual exploração.
Incidentes recentes
O worm de Morris evidenciou que vulnerabilidades simples podem resultar em compromissos generalizados (SPAFFORD, 1989). Muitos sistemas foram comprometidos porque serviços vulneráveis tinham acesso irrestrito ao sistema de arquivos.
Isso sugere que confinamento de processos poderia limitar significativamente os danos causados por explorações remotas.
- Threat Model and Problem Formalization
Consideramos um ambiente típico de 1989:
- sistemas UNIX BSD ou System V
- conectados via TCP/IP
- executando serviços como
sendmail,fingerd,rsh,telnet
Assumimos que o atacante possui acesso remoto à rede e pode enviar entradas arbitrárias para serviços expostos.
Vetores de ataque
Os vetores de ataque mais relevantes incluem:
- exploração de buffer overflow
- execução de comandos via serviços mal configurados
- abuso de autenticação baseada em confiança (
.rhosts) - exploração de programas
setuid
Formalizamos o risco de comprometimento como:
$$ R = P(E) \times I $$
onde:
- $P(E)$ = probabilidade de exploração bem-sucedida
- $I$ = impacto da exploração
A estratégia de contêineres visa reduzir $I$, mesmo quando $P(E)$ não pode ser eliminado.
Domínios de confinamento
Definimos um contêiner como um domínio $C$ caracterizado por:
$$ C = (F, U, P) $$
onde:
- $F$ = subconjunto do sistema de arquivos visível
- $U$ = identidade de usuário associada
- $P$ = conjunto de permissões disponíveis
O objetivo é minimizar:
$$ |F| + |P| $$
de modo que o processo tenha apenas os recursos estritamente necessários.
- Proposed Methodology
Nossa metodologia baseia-se em três princípios fundamentais de segurança clássicos (SALTZER; SCHROEDER, 1975):
- privilégio mínimo
- isolamento
- auditabilidade
A arquitetura proposta para contêineres UNIX inclui quatro componentes principais:
- Raiz isolada (
chroot) - Usuário dedicado
- Conjunto mínimo de binários
- Monitoramento de rede
Estrutura do sistema de arquivos
Cada serviço recebe um diretório raiz dedicado:
/containers/
finger/
bin/
etc/
dev/
tmp/
Dentro desse ambiente são incluídos apenas:
- bibliotecas necessárias
- arquivos de configuração mínimos
- dispositivos essenciais (
/dev/null,/dev/tty)
Redução de privilégios
Após inicialização, o processo troca para um usuário restrito:
setuid(nobody)
Monitoramento de rede
O tráfego é monitorado usando tcpdump, ferramenta introduzida no final da década de 1980.
Exemplo:
tcpdump -i le0 port 79
Isso permite registrar tentativas de exploração do serviço finger.
Comparação com virtualização
| Propriedade | chroot container | VM/370 | Multics |
|---|---|---|---|
| Overhead | baixo | alto | médio |
| Isolamento | parcial | forte | forte |
| Facilidade de implantação | alta | baixa | baixa |
| Compatibilidade UNIX | nativa | limitada | inexistente |
- Implementation
O protótipo foi implementado em BSD 4.3 executando em estações Sun-3.
Criação do ambiente
mkdir -p /containers/finger/{bin,etc,dev,tmp}
cp /usr/bin/finger /containers/finger/bin/
mknod /containers/finger/dev/null c 2 2
Inicialização do serviço
chroot /containers/finger /bin/finger
Auditoria
Monitoramento de processos:
ps -aux | grep finger
Monitoramento de conexões:
netstat -an | grep 79
- Experimental Evaluation
Os experimentos foram conduzidos em uma rede de laboratório com 12 estações UNIX.
Simulamos ataques inspirados no worm de 1988.
Cenários avaliados
- Sistema sem confinamento
- Serviço em contêiner
chroot - Serviço executando como usuário restrito
Resultados
| Configuração | Comprometimento do sistema | Acesso ao /etc/passwd | Propagação |
|---|---|---|---|
| Sem isolamento | total | sim | alta |
| Usuário restrito | parcial | limitado | média |
| chroot container | mínimo | não | baixa |
Impacto no desempenho
| Métrica | Sistema normal | chroot container |
|---|---|---|
| Latência média | 12 ms | 13 ms |
| Uso de CPU | 4% | 5% |
| Memória | 3.2 MB | 3.4 MB |
Superfície de ataque
| Configuração | Arquivos acessíveis | Binários executáveis |
|---|---|---|
| Sistema completo | 12.000+ | 1.200 |
| Ambiente chroot | 140 | 12 |
- Case Study
Implementamos o confinamento do serviço fingerd, que foi explorado no incidente de 1988.
No sistema original, o processo tinha acesso a todo o sistema de arquivos. Após exploração de buffer overflow, um invasor poderia executar comandos arbitrários.
No ambiente chroot:
- o invasor não podia acessar
/bin/sh - não havia compiladores disponíveis
- arquivos sensíveis não estavam presentes
Isso reduziu drasticamente o valor operacional da intrusão.
- Discussion
Os resultados indicam que contêineres baseados em chroot fornecem isolamento prático com baixo custo operacional. Administradores podem implantar essa abordagem rapidamente sem modificar o kernel.
Entretanto, limitações importantes permanecem:
- processos com privilégios de superusuário podem escapar do ambiente
- o kernel permanece um ponto único de falha
- descritores de arquivos herdados podem permitir acesso externo
Apesar dessas limitações, a técnica oferece um aumento significativo de segurança em comparação com execução direta de serviços de rede.
- Conclusion and Future Work
Este trabalho demonstrou que mecanismos simples disponíveis em sistemas UNIX podem ser combinados para criar contêineres de processos eficazes.
Experimentos indicam que essa abordagem reduz substancialmente o impacto de explorações remotas, especialmente em serviços vulneráveis expostos à rede.
Trabalhos futuros devem investigar:
- suporte nativo no kernel para confinamento
- políticas de controle de acesso mais rigorosas
- auditoria automática de atividades dentro do contêiner
É plausível que sistemas operacionais futuros integrem mecanismos de isolamento mais robustos inspirados nesses princípios, permitindo execução segura de serviços potencialmente inseguros em ambientes conectados.
- References
BELL, D.; LAPADULA, L. Secure computer systems: mathematical foundations. MITRE, 1973. Disponível em: https://csrc.nist.gov/publications/detail/report/1973/secure-computer-systems-mathematical-foundations
BIBA, K. Integrity considerations for secure computer systems. MITRE, 1977. Disponível em: https://csrc.nist.gov/publications/detail/report/1977/integrity-considerations-for-secure-computer-systems
DENNING, D. Cryptography and Data Security. Addison‑Wesley, 1982. https://archive.org/details/cryptographydata00denn
ECCLES, W. Computer Security Handbook. McGraw‑Hill, 1988. https://archive.org/details/computersecurityhandbook1988
GRAHAM, R.; DENNING, P. Protection principles and practice. AFIPS, 1972. https://dl.acm.org/doi/10.1145/1479992.1480023
LAMPSON, B. A note on the confinement problem. Communications of the ACM, 1973. https://dl.acm.org/doi/10.1145/362375.362389
MADNICK, S.; DONOVAN, J. Operating Systems. McGraw‑Hill, 1974. https://archive.org/details/operatingsystems00madn
MORRIS, R.; THOMPSON, K. Password security: a case history. Communications of the ACM, 1979. https://dl.acm.org/doi/10.1145/359168.359172
POSTEL, J. Transmission Control Protocol. RFC 793, 1981. https://www.rfc-editor.org/rfc/rfc793
POSTEL, J. Internet Protocol. RFC 791, 1981. https://www.rfc-editor.org/rfc/rfc791
RITCHIE, D.; THOMPSON, K. The UNIX time-sharing system. Communications of the ACM, 1974. https://dl.acm.org/doi/10.1145/361011.361061
SALTZER, J.; SCHROEDER, M. The protection of information in computer systems. Proceedings of the IEEE, 1975. https://web.mit.edu/Saltzer/www/publications/protection/
SPAFFORD, E. The Internet Worm Program: An Analysis. Purdue University, 1989. https://docs.lib.purdue.edu/cstech/521/
STOLL, C. Stalking the Wily Hacker. Communications of the ACM, 1988. https://dl.acm.org/doi/10.1145/42411.42417
TANENBAUM, A. Operating Systems: Design and Implementation. Prentice Hall, 1987. https://archive.org/details/operatingsystemsdesignimplementation
NEUMANN, P. Computer-Related Risks. Addison‑Wesley, 1985. https://archive.org/details/computerrelatedr00neum
ANDERSON, J. Computer Security Technology Planning Study. ESD‑TR‑73‑51, 1972. https://csrc.nist.gov/publications/detail/report/1972/computer-security-technology-planning-study
BRAND, S. UNIX System Security. USENIX, 1987. https://www.usenix.org/legacy/publications/library/proceedings
KARGER, P. Multics Security Evaluation. MITRE, 1974. https://multicians.org/karger.html
DENNING, P. Fault tolerant operating systems. ACM Computing Surveys, 1976. https://dl.acm.org/doi/10.1145/356678.356679
REED, D. Naming and synchronization in a decentralized computer system. MIT, 1978. https://dspace.mit.edu
POSTEL, J.; REYNOLDS, J. Telnet Protocol Specification. RFC 854, 1983. https://www.rfc-editor.org/rfc/rfc854
POSTEL, J. Simple Mail Transfer Protocol. RFC 821, 1982. https://www.rfc-editor.org/rfc/rfc821
COMER, D. Internetworking with TCP/IP. Prentice Hall, 1988. https://archive.org/details/internetworkingwithtcpip
SPAFFORD, E.; ZAMBONI, D. Intrusion detection in networked systems. Purdue Technical Report, 1989. https://docs.lib.purdue.edu/cstech/