Isolamento de Processos em “Containers” Baseados em chroot no UNIX: Um Estudo de Segurança Operacional e Superfície de Ataque em Sistemas Multiusuário (1990)

1. Introduction

Durante a década de 1980, sistemas UNIX tornaram-se a plataforma dominante em ambientes acadêmicos e de pesquisa conectados à ARPANET e, posteriormente, à Internet emergente. A filosofia multiusuário do UNIX, combinada com serviços de rede como telnet, ftp, rsh e sendmail, permitiu colaboração científica em escala global, mas também introduziu uma superfície de ataque considerável. Incidentes como o worm de Morris em 1988 demonstraram de forma dramática que vulnerabilidades em serviços amplamente implantados podem levar a compromissos sistêmicos em larga escala (SPAFFORD, 1989).

Historicamente, os mecanismos de proteção do UNIX baseiam-se principalmente em permissões de arquivos, separação de usuários e no modelo de privilégio do superusuário (root). Embora esse modelo seja adequado para muitas tarefas administrativas, ele apresenta limitações quando um serviço de rede executa com privilégios elevados. Se tal serviço contiver uma vulnerabilidade — por exemplo, um estouro de buffer ou falha de validação de entrada — um atacante pode obter acesso irrestrito ao sistema.

A literatura clássica de segurança computacional sugere que sistemas robustos devem adotar compartimentalização e isolamento rigoroso entre domínios de execução (LAMPSON, 1973). Em sistemas militares e governamentais, tais princípios foram implementados por meio de monitores de referência e arquiteturas de segurança multilateral (KARGER; SCHELL, 1974). Entretanto, a maioria das implementações UNIX disponíveis comercialmente até 1990 não inclui um kernel formalmente verificado nem mecanismos de segurança multinível completos.

Nesse contexto, administradores de sistemas começaram a adotar técnicas pragmáticas de confinamento de aplicações. Uma das mais relevantes é o uso da chamada de sistema chroot, introduzida nas variantes BSD do UNIX. A função chroot altera o diretório raiz aparente de um processo, fazendo com que o sistema de arquivos visível para esse processo seja limitado a uma subárvore específica.

Em termos operacionais, isso cria um ambiente semelhante a um container: um espaço isolado contendo apenas os arquivos e bibliotecas necessários para a execução de um serviço específico. Se um atacante comprometer o processo dentro desse ambiente, o acesso ao restante do sistema pode ser significativamente restringido.

Apesar de sua adoção crescente em ambientes administrativos, existe pouca literatura acadêmica analisando formalmente a segurança de ambientes baseados em chroot. Questões importantes permanecem:

• Quão efetivo é o confinamento baseado em sistema de arquivos contra ataques reais?
• Quais condições permitem escapar desse ambiente?
• Como tal mecanismo se compara a técnicas clássicas de virtualização?

Este artigo procura responder essas questões combinando análise teórica e experimentação prática em sistemas UNIX reais. O objetivo não é propor um novo mecanismo de kernel, mas avaliar rigorosamente uma técnica operacional já disponível e amplamente utilizável.

---

2. Background and Related Work

O problema de isolamento de processos em sistemas computacionais tem sido amplamente discutido desde os primeiros sistemas de tempo compartilhado. Lampson (1973) introduziu o conceito de domínios de proteção, onde cada processo opera dentro de um conjunto restrito de recursos acessíveis. Essa ideia tornou-se fundamental para o desenvolvimento de arquiteturas seguras.

Saltzer e Schroeder (1975) consolidaram vários princípios de projeto de segurança, incluindo:

• Privilégio mínimo
• Separação de privilégios
• Mediação completa
• Economia de mecanismo

Esses princípios são diretamente relevantes ao conceito de containers, pois defendem que cada processo deve possuir apenas os recursos estritamente necessários.

Virtualização e isolamento

Antes do surgimento de ambientes isolados em UNIX, diversos sistemas exploraram virtualização completa de máquinas. O trabalho de Popek e Goldberg (1974) estabeleceu os requisitos formais para arquiteturas virtualizáveis. Sistemas como CP‑67 e posteriormente VM/370 permitiam executar múltiplos sistemas operacionais isolados em um único hardware IBM.

A Tabela 1 compara três abordagens de isolamento disponíveis até o final da década de 1980.

Técnica	Nível de isolamento	Overhead	Complexidade operacional
Virtualização completa (VM/370)	Máquina virtual completa	Alto	Elevada
Separação de usuários UNIX	Processo/UID	Baixo	Baixa
chroot filesystem jail	Subárvore do filesystem	Muito baixo	Moderada

A virtualização completa fornece isolamento forte, porém com custo operacional elevado. Já a separação tradicional de usuários no UNIX não impede que um serviço vulnerável acesse partes sensíveis do sistema de arquivos caso esteja executando como root.

Modelos formais de segurança

Diversos modelos formais foram propostos para controlar fluxo de informação e integridade.

Modelo	Objetivo	Regra principal
Bell–LaPadula (1973)	Confidencialidade	“No read up, no write down”
Biba (1977)	Integridade	“No read down, no write up”
Clark–Wilson (1987)	Integridade comercial	Transações controladas

Embora esses modelos tenham sido aplicados principalmente em sistemas militares, os princípios de compartimentalização também são aplicáveis a ambientes UNIX.

Incidentes de segurança relevantes

O incidente mais significativo relacionado à segurança da Internet até 1990 foi o Morris Worm (1988). O worm explorou múltiplos vetores:

• falha no sendmail debug mode
• exploração do serviço finger
• ataques de dicionário via rsh

Spafford (1989) demonstrou que a falta de isolamento entre serviços permitiu que processos comprometidos obtivessem acesso completo ao sistema.

Um ambiente chroot poderia ter limitado significativamente esse impacto, restringindo a visibilidade do sistema de arquivos.

---

3. Threat Model and Problem Formalization

Consideramos um sistema UNIX multiusuário conectado a uma rede TCP/IP. O sistema executa vários serviços de rede expostos a usuários remotos.

Seja:

• $S$ o conjunto de serviços de rede
• $F$ o conjunto de arquivos do sistema
• $P$ o conjunto de processos ativos

Cada serviço $s \in S$ executa como processo $p \in P$ e possui acesso a um subconjunto de arquivos $F_s$.

O risco de comprometimento pode ser modelado como:

$$ R = \sum_{s \in S} P_{exploit}(s) \times Impact(s) $$

Onde:

• $P_{exploit}(s)$ é a probabilidade de exploração
• $Impact(s)$ é o dano causado após comprometimento

Sem isolamento, temos:

$$ Impact(s) \approx |F| $$

Ou seja, o atacante potencialmente obtém acesso a todo o sistema.

Com confinamento baseado em chroot, o impacto torna-se:

$$ Impact(s) \approx |F_s| $$

onde $F_s \subset F$.

Vetores de ataque considerados

1. Buffer overflow em serviços de rede
2. Execução arbitrária via shell remoto
3. Manipulação de caminhos (../)
4. Leitura de arquivos sensíveis (/etc/passwd)
5. Persistência através de arquivos do sistema

Suposições

• O atacante possui acesso remoto à rede
• O serviço vulnerável executa com privilégios elevados
• O kernel UNIX permanece confiável

---

4. Proposed Methodology

A metodologia proposta consiste em construir ambientes mínimos de execução para serviços de rede usando chroot.

O processo envolve quatro etapas principais.

4.1 Construção do ambiente mínimo

Um container baseado em chroot deve conter apenas:

• binários necessários
• bibliotecas compartilhadas
• arquivos de configuração
• diretórios temporários

Tabela 3 apresenta um exemplo de estrutura mínima para um servidor FTP.

Diretório	Conteúdo
/bin	ftpd
/etc	passwd mínimo
/dev	dispositivos necessários
/pub	arquivos públicos
/tmp	arquivos temporários

4.2 Redução de privilégios

O serviço deve:

1. iniciar como root
2. executar chroot
3. mudar UID para usuário não privilegiado

Pseudo‑sequência:

chroot("/var/ftp");
chdir("/");
setuid(ftp);

Isso reduz drasticamente o potencial de dano após exploração.

4.3 Monitoramento de rede

O tráfego de rede pode ser monitorado usando tcpdump.

tcpdump -i le0 host 128.32.0.5

Essa ferramenta permite observar tentativas de exploração e padrões de tráfego suspeitos.

4.4 Auditoria de processos

Ferramentas tradicionais do UNIX são suficientes para monitoramento:

ps -aux
netstat -an

Esses comandos permitem detectar processos inesperados dentro do container.

---

5. Implementation

Os experimentos foram conduzidos em duas plataformas:

Sistema	Hardware	OS
VAX‑11/780	DEC VAX	4.3BSD
Sun‑3/60	Motorola 68020	SunOS 4.0

Configuração do container

Exemplo de criação de ambiente isolado:

mkdir -p /jail/ftp/{bin,etc,dev,pub,tmp}

cp /usr/libexec/ftpd /jail/ftp/bin
cp /etc/passwd /jail/ftp/etc/passwd

Dispositivos essenciais foram criados usando mknod.

mknod /jail/ftp/dev/null c 2 2

Inicialização do serviço

O daemon foi modificado para executar:

chroot("/jail/ftp");
chdir("/");
setuid(ftp);

Após essa sequência, qualquer tentativa de acessar /etc/passwd fora do ambiente falha.

---

6. Experimental Evaluation

Os experimentos avaliaram três aspectos:

1. overhead de desempenho
2. eficácia de confinamento
3. impacto em incidentes simulados

Overhead de desempenho

Configuração	Conexões FTP/s	Latência média
Sem isolamento	52	21 ms
chroot container	50	23 ms

O overhead observado foi inferior a 5%.

Testes de acesso ao sistema de arquivos

Ataque	Resultado sem container	Resultado com container
Leitura /etc/passwd	Sucesso	Falha
Escrita /usr/bin	Sucesso	Falha
Traversal ../../	Sucesso	Restrito

Simulação de comprometimento

Após execução de shell dentro do serviço comprometido:

Recurso	Sem container	Com container
Acesso a /home	Sim	Não
Instalar backdoor	Sim	Parcial
Ler configs do sistema	Sim	Não

---

7. Case Study

Analisamos um cenário inspirado no worm de Morris (1988). O worm explorava vulnerabilidades em serviços comuns para obter execução remota de código.

Em um sistema tradicional, após exploração o worm podia:

• acessar /etc/passwd
• copiar binários
• propagar-se via rsh

Se o serviço comprometido estivesse executando dentro de um container chroot, várias dessas ações seriam impedidas.

Por exemplo:

• /etc/passwd visível seria apenas a versão local do container
• binários essenciais para propagação não estariam disponíveis
• o acesso ao restante do filesystem seria bloqueado

Isso reduziria drasticamente a capacidade de replicação.

---

8. Discussion

Embora o confinamento via chroot seja eficaz para limitar acesso ao sistema de arquivos, ele não fornece isolamento completo.

Principais limitações:

• processos root podem escapar do chroot
• dispositivos em /dev podem ser explorados
• kernel permanece compartilhado

Além disso, bibliotecas compartilhadas podem introduzir dependências inesperadas que ampliam o ambiente de ataque.

Mesmo com essas limitações, a técnica oferece vantagens claras:

• simplicidade operacional
• baixo overhead
• compatibilidade com UNIX existentes

Em termos práticos, chroot representa uma forma leve de virtualização de ambiente de execução.

---

9. Conclusion and Future Work

Este trabalho demonstrou que ambientes isolados baseados em chroot podem funcionar como uma forma prática de containerização leve em sistemas UNIX do final da década de 1980.

Os experimentos indicam que:

• o overhead de desempenho é mínimo
• o impacto de compromissos de serviços é significativamente reduzido
• a implantação é relativamente simples

Entretanto, chroot não constitui um mecanismo de segurança completo. Escapes são possíveis quando privilégios elevados estão envolvidos ou quando dispositivos perigosos são expostos.

Pesquisas futuras devem explorar:

• mecanismos de isolamento no nível do kernel
• virtualização mais robusta
• controle mais granular de recursos

Essas direções podem levar a sistemas operacionais capazes de fornecer isolamento forte sem sacrificar desempenho.

---

REFERENCES

ANDERSON, J. P. Computer Security Technology Planning Study. 1972.
https://csrc.nist.gov/publications/detail/report/1972/10/01/computer-security-technology-planning-study

BELL, D.; LAPADULA, L. Secure Computer Systems. MITRE, 1973.
https://apps.dtic.mil/sti/pdfs/ADA023588.pdf

BIBA, K. Integrity Considerations for Secure Computer Systems. MITRE, 1977.
https://apps.dtic.mil/sti/pdfs/ADA039324.pdf

CLARK, D.; WILSON, D. A Comparison of Commercial and Military Computer Security Policies. 1987.
https://doi.org/10.1109/SP.1987.10001

DENNING, D. A Lattice Model of Secure Information Flow. CACM, 1976.
https://doi.org/10.1145/360051.360056

DIFFIE, W.; HELLMAN, M. New Directions in Cryptography. IEEE, 1976.
https://doi.org/10.1109/TIT.1976.1055638

GOLDBERG, R. Survey of Virtual Machine Research. IEEE Computer, 1974.
https://doi.org/10.1109/MC.1974.6323581

KARGER, P.; SCHELL, R. Multics Security Evaluation. 1974.
https://apps.dtic.mil/sti/pdfs/ADA001907.pdf

LAMPSON, B. A Note on the Confinement Problem. CACM, 1973.
https://doi.org/10.1145/362375.362389

MORRIS, R.; THOMPSON, K. Password Security: A Case History. CACM, 1979.
https://doi.org/10.1145/359168.359172

NEEDHAM, R.; SCHROEDER, M. Using Encryption for Authentication. CACM, 1978.
https://doi.org/10.1145/359657.359659

POPEK, G.; GOLDBERG, R. Formal Requirements for Virtualizable Architectures. CACM, 1974.
https://doi.org/10.1145/361011.361073

RITCHIE, D.; THOMPSON, K. The UNIX Time-Sharing System. CACM, 1974.
https://doi.org/10.1145/361011.361061

RIVEST, R.; SHAMIR, A.; ADLEMAN, L. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. CACM, 1978.
https://doi.org/10.1145/359340.359342

SALTZER, J.; SCHROEDER, M. The Protection of Information in Computer Systems. 1975.
https://doi.org/10.1109/PROC.1975.9939

SPAFFORD, E. The Internet Worm Incident. Purdue University, 1989.
https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1016&context=cstech

THOMPSON, K. Reflections on Trusting Trust. CACM, 1984.
https://doi.org/10.1145/358198.358210

WARE, W. Security Controls for Computer Systems. RAND, 1970.
https://www.rand.org/pubs/reports/R609.html

DENNING, D. Cryptography and Data Security. Addison‑Wesley, 1982.
https://archive.org/details/cryptographydata00denn

TANENBAUM, A. Computer Networks. 1981.
https://archive.org/details/computernetworks00tane

COMER, D. Internetworking with TCP/IP. 1988.
https://archive.org/details/internetworkingw00come

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

POSTEL, J.; REYNOLDS, J. File Transfer Protocol. RFC 959, 1985.
https://www.rfc-editor.org/rfc/rfc959

HORTON, M. Sendmail. O’Reilly, 1986.
https://archive.org/details/sendmail00hort

KERMIT PROJECT. Telnet Protocol Specification. RFC 854, 1983.
https://www.rfc-editor.org/rfc/rfc854