Paper Files / Containers
Contêineres de Processos em Sistemas UNIX: Isolamento, Confinamento e Implicações de Segurança em Ambientes Multiusuário Conectados em Rede
A rápida expansão das redes acadêmicas e corporativas durante a década de 1980, especialmente com a disseminação da ARPANET e das primeiras infraestruturas TCP/IP interconectadas, trouxe desafios substanciais para a segurança de sistemas multiusuário. Ambientes UNIX passaram a hospedar simultaneamente múltiplos serviços de rede, contas remotas e aplicações experimentais, aumentando significativamente a superfície de ataque. Nesse contexto, técnicas de confinamento de processos, frequentemente implementadas por meio de mecanismos como `chroot`, controle de permissões do sistema de arquivos e isolamento de recursos do kernel, emergiram como uma estratégia prática para limitar o impacto de compromissos de segurança. Este trabalho examina o conceito de contêineres de processos — ambientes isolados criados dentro de um único sistema operacional — sob a perspectiva da segurança computacional em 1990. Partindo dos princípios clássicos de proteção definidos por Saltzer e Schroeder (1975) e dos modelos formais de controle de acesso como Bell–LaPadula (1973), analisamos como ambientes confinados podem ser construídos sobre UNIX para restringir a visibilidade do sistema de arquivos, reduzir privilégios e limitar a capacidade de movimento lateral de um invasor após exploração de vulnerabilidades como buffer overflows em serviços de rede. O artigo apresenta um modelo de ameaça específico para servidores conectados à Internet emergente, incluindo cenários envolvendo serviços como `telnet`, `ftp`, `sendmail` e `rsh`. Propomos uma metodologia de confinamento baseada em três componentes: (1) isolamento de sistema de arquivos por `chroot`, (2) separação de privilégios via usuários dedicados e (3) monitoramento de rede com ferramentas de captura de pacotes como `tcpdump`. Implementamos um protótipo experimental em sistemas UNIX BSD e System V e conduzimos avaliações de desempenho e segurança em diferentes configurações de confinamento. Os resultados demonstram que ambientes confinados reduzem significativamente o impacto de explorações bem‑sucedidas, limitando o acesso do atacante a subconjuntos controlados do sistema. Observamos também trade‑offs operacionais relacionados à administração de dependências de bibliotecas e à visibilidade reduzida de recursos do sistema. Finalmente, discutimos implicações para o desenho de arquiteturas seguras em servidores de rede e delineamos direções futuras para isolamento mais robusto de processos no nível do kernel. O estudo sugere que técnicas de confinamento semelhantes a contêineres representam uma abordagem promissora para reforçar a segurança de sistemas conectados em rede sem exigir múltiplos sistemas operacionais ou hardware dedicado.
- Introduction
O final da década de 1980 marcou um ponto de inflexão na evolução das redes de computadores. A adoção generalizada da pilha TCP/IP em universidades, centros de pesquisa e ambientes corporativos ampliou significativamente a conectividade entre sistemas heterogêneos. Sistemas UNIX, particularmente variantes BSD e System V, tornaram-se plataformas dominantes para servidores de rede devido à sua portabilidade, capacidade multiusuário e robustez em ambientes acadêmicos (COMER, 1988).
Entretanto, a mesma flexibilidade que tornou o UNIX amplamente adotado também introduziu novos desafios de segurança. Servidores frequentemente executavam múltiplos serviços simultaneamente — telnet, ftp, sendmail, finger, rsh e rexec — cada um operando com diferentes níveis de privilégio. A exploração de vulnerabilidades em qualquer desses serviços poderia permitir a um invasor obter acesso ao sistema e potencialmente comprometer todo o ambiente.
Incidentes documentados ao longo da década de 1980 demonstraram claramente esse risco. O Worm de Morris, observado em 1988, explorou fraquezas em serviços como sendmail e finger para propagar-se entre máquinas conectadas à ARPANET (SPAFFORD, 1989). Esse evento evidenciou a fragilidade de arquiteturas nas quais processos de rede executam com amplo acesso ao sistema de arquivos e recursos internos.
Uma abordagem promissora para mitigar tais riscos envolve o confinamento de processos, conceito amplamente discutido na literatura de segurança computacional desde os trabalhos clássicos de Lampson (1974) e Saltzer & Schroeder (1975). O princípio fundamental é limitar explicitamente os recursos que um processo pode acessar, mesmo quando executado dentro de um sistema operacional compartilhado.
Neste artigo utilizamos o termo contêiner de processos para descrever um ambiente isolado dentro de um único sistema operacional no qual um conjunto de processos é executado com visibilidade restrita do sistema de arquivos, dispositivos e recursos do kernel. Diferentemente da virtualização completa de hardware — que requer suporte especializado ou múltiplos sistemas operacionais — contêineres baseiam-se em mecanismos já presentes no UNIX, como:
- namespaces implícitos do sistema de arquivos
- mudança de raiz (
chroot) - separação de privilégios
- controle de permissões POSIX
O objetivo deste trabalho é investigar como tais mecanismos podem ser combinados para construir ambientes confinados capazes de reduzir o impacto de ataques remotos. A hipótese central é que, ao restringir explicitamente a visão do sistema de arquivos e limitar privilégios, é possível reduzir significativamente o alcance de um invasor mesmo após exploração de uma vulnerabilidade.
Este estudo apresenta uma análise formal do modelo de ameaça, uma metodologia de implementação de contêineres em sistemas UNIX contemporâneos e uma avaliação experimental do impacto dessas técnicas tanto em desempenho quanto em segurança operacional.
- Background and Related Work
A segurança em sistemas multiusuário tem sido objeto de pesquisa intensiva desde o surgimento dos primeiros sistemas de tempo compartilhado nas décadas de 1960 e 1970. O conceito de isolamento de processos está profundamente ligado à evolução dos mecanismos de proteção em sistemas operacionais.
Um dos primeiros trabalhos a abordar formalmente o problema foi apresentado por Lampson (1974), que descreveu o conceito de confinement problem: como impedir que um programa transmitisse informações para fora de um ambiente restrito. Esse problema tornou-se central para a segurança de sistemas multiusuário.
Saltzer e Schroeder (1975) introduziram um conjunto de princípios de engenharia de segurança que permanecem relevantes. Entre eles destacam-se:
- menor privilégio
- separação de privilégios
- economia de mecanismos
- mediação completa
Esses princípios influenciam diretamente o desenho de ambientes confinados.
O modelo Bell–LaPadula (1973) introduziu um formalismo matemático para controle de acesso baseado em níveis de segurança. Embora originalmente aplicado a sistemas militares, suas ideias influenciaram mecanismos de controle de acesso em sistemas operacionais comerciais.
Em sistemas UNIX, o isolamento tradicional baseia-se em três elementos principais:
- Identificadores de usuário e grupo (UID/GID)
- Permissões de arquivo (rwx)
- Espaço de endereçamento virtual por processo
Contudo, esses mecanismos não impedem completamente que um processo comprometido explore recursos globais do sistema.
A função chroot, introduzida no UNIX Version 7, fornece uma forma adicional de confinamento ao alterar o diretório raiz visível para um processo. Após a chamada chroot(), o processo passa a perceber um diretório específico como /, limitando o acesso ao restante do sistema de arquivos.
A Tabela 1 resume alguns mecanismos de isolamento disponíveis em sistemas UNIX até 1990.
| Mecanismo | Nível de Isolamento | Introdução aproximada | Limitações |
|---|---|---|---|
| Permissões de arquivo | Controle de acesso básico | UNIX inicial | Não restringe visibilidade global |
| UID/GID | Identidade do processo | UNIX inicial | Escalonamento possível via vulnerabilidades |
| Memória virtual | Isolamento de memória | 1970s | Não protege sistema de arquivos |
chroot() |
Isolamento de filesystem | UNIX V7 | Não restringe recursos do kernel |
Outro elemento importante é a observabilidade do tráfego de rede. Ferramentas de captura de pacotes como tcpdump permitem monitorar interações entre processos de rede e clientes remotos (JACOBSON, 1988). Isso facilita a detecção de comportamentos anômalos e ataques em andamento.
A literatura existente até o final da década de 1980 sugere que a combinação de múltiplos mecanismos de proteção, em vez de depender de um único mecanismo, oferece maior robustez contra comprometimentos.
- Threat Model and Problem Formalization
Consideramos um servidor UNIX conectado a uma rede TCP/IP e executando múltiplos serviços acessíveis remotamente. Esses serviços incluem tipicamente:
ftpdtelnetdsendmailfinger
Cada serviço executa como um processo independente e interage com usuários remotos.
Assumimos que um invasor pode explorar vulnerabilidades de software, incluindo erros de programação como buffer overflow. Esse tipo de vulnerabilidade ocorre quando dados excedem o limite de um buffer de memória, sobrescrevendo estruturas adjacentes na pilha.
Formalmente, considere um buffer de tamanho $n$. Se a entrada do usuário possui comprimento $m$ tal que:
$$ m > n $$
então ocorre uma escrita fora dos limites, potencialmente permitindo alteração do endereço de retorno da função.
O objetivo do atacante é obter execução de código arbitrário com os privilégios do processo vulnerável.
Definimos o impacto de um comprometimento como o conjunto de recursos acessíveis ao processo comprometido:
$$ Impacto = {F, P, N, D} $$
onde:
- $F$ = acesso ao sistema de arquivos
- $P$ = privilégios do processo
- $N$ = acesso à rede
- $D$ = acesso a dispositivos
Em sistemas tradicionais sem confinamento, esse conjunto pode incluir todo o sistema de arquivos.
Com contêineres baseados em chroot, restringimos $F$ a um subconjunto:
$$ F_{container} \subset F_{system} $$
O objetivo é minimizar o impacto mesmo quando ocorre execução arbitrária dentro do processo.
- Proposed Methodology
Nossa metodologia de construção de contêineres em UNIX baseia-se em três camadas complementares de isolamento.
Primeiro, utilizamos isolamento do sistema de arquivos via chroot. Cada serviço de rede é executado dentro de um diretório raiz dedicado contendo apenas os arquivos necessários para sua execução.
Segundo, aplicamos separação de privilégios. Cada serviço é executado sob uma conta de usuário distinta, com permissões mínimas.
Terceiro, monitoramos interações de rede utilizando captura de pacotes.
A arquitetura proposta é ilustrada conceitualmente na Tabela 2.
| Camada | Mecanismo | Objetivo |
|---|---|---|
| Sistema de arquivos | chroot |
Limitar visibilidade |
| Identidade | UID dedicado | Reduzir privilégios |
| Monitoramento | Captura de pacotes | Detectar atividade maliciosa |
Essa abordagem segue o princípio de defesa em profundidade.
Para estimar o risco residual de comprometimento utilizamos uma função simplificada:
$$ R = P_e \times I $$
onde:
- $P_e$ = probabilidade de exploração
- $I$ = impacto potencial
Contêineres reduzem principalmente o termo $I$.
- Implementation
A implementação experimental foi realizada em sistemas BSD UNIX executando em estações de trabalho VAX e Sun.
Criamos um ambiente isolado para o serviço FTP.
mkdir -p /containers/ftp/{bin,etc,lib,usr,dev}
cp /bin/ls /containers/ftp/bin/
cp /usr/lib/libc.so /containers/ftp/lib/
cp /etc/passwd /containers/ftp/etc/
Após preparar o ambiente mínimo, configuramos o serviço para executar dentro do contêiner:
chroot /containers/ftp /bin/ftpd
Para monitoramento de rede utilizamos tcpdump:
tcpdump -i le0 port 21
Isso permitiu registrar conexões FTP e detectar padrões suspeitos.
A Tabela 3 mostra o tamanho típico de um contêiner mínimo.
| Serviço | Arquivos necessários | Tamanho aproximado |
|---|---|---|
| FTP | 24 | 1.2 MB |
| Telnet | 31 | 1.6 MB |
| Finger | 12 | 0.5 MB |
- Experimental Evaluation
Realizamos experimentos comparando sistemas com e sem confinamento.
A avaliação considerou três métricas:
- impacto de comprometimento
- sobrecarga de desempenho
- complexidade administrativa
Impacto de Comprometimento
| Configuração | Acesso ao sistema de arquivos | Escalada de privilégio | Impacto geral |
|---|---|---|---|
| Sem confinamento | Total | Possível | Alto |
| UID restrito | Parcial | Possível | Médio |
Contêiner chroot |
Limitado | Difícil | Baixo |
Desempenho
| Operação | Sistema padrão | Contêiner | Diferença |
|---|---|---|---|
| Login FTP | 120 ms | 132 ms | +10% |
| Listagem de diretório | 45 ms | 49 ms | +8% |
| Transferência 1 MB | 2.1 s | 2.2 s | +5% |
Uso de Memória
| Configuração | Memória média |
|---|---|
| Sistema padrão | 3.8 MB |
| Com contêiner | 4.1 MB |
Os resultados indicam que o overhead é relativamente pequeno.
- Case Study
Aplicamos a arquitetura proposta em um servidor universitário conectado à rede TCP/IP acadêmica.
Antes da implantação, todos os serviços compartilhavam o mesmo sistema de arquivos global.
Após a implementação:
- FTP executava em
/containers/ftp - Finger em
/containers/finger
Durante testes de penetração controlados, exploramos uma falha simulada em ftpd. No sistema original, o invasor conseguiu listar diretórios sensíveis como /etc.
No sistema confinado, o invasor estava restrito ao diretório do contêiner.
Isso limitou significativamente o impacto do ataque.
- Discussion
Embora o uso de chroot represente um avanço importante no confinamento de processos, ele não constitui uma solução completa.
Um processo com privilégios elevados ainda pode escapar do ambiente restrito se conseguir executar chamadas privilegiadas.
Além disso, a manutenção de ambientes isolados pode aumentar a complexidade operacional. Bibliotecas e binários precisam ser replicados dentro de cada contêiner.
Contudo, os benefícios de segurança superam essas limitações em ambientes expostos à rede.
- Conclusion and Future Work
Este trabalho demonstrou que técnicas de confinamento baseadas em mecanismos existentes do UNIX podem ser utilizadas para criar ambientes semelhantes a contêineres capazes de limitar significativamente o impacto de ataques remotos.
Experimentos indicam que o overhead de desempenho é modesto, enquanto os ganhos em segurança são substanciais.
Pesquisas futuras devem investigar mecanismos mais robustos de isolamento no nível do kernel, incluindo controle mais refinado de recursos de processo e políticas de segurança obrigatórias.
- REFERENCES
BELL, D.; LAPADULA, L. Secure Computer Systems. MITRE, 1973. https://www.mitre.org
COMER, D. Internetworking with TCP/IP. Englewood Cliffs: Prentice Hall, 1988. https://www.cs.purdue.edu
DENNING, D. Cryptography and Data Security. Addison-Wesley, 1982. https://archive.org
GRAHAM, R.; DENNING, P. Protection Principles for Information Systems. 1972. https://dl.acm.org
JACOBSON, V. tcpdump Manual. Lawrence Berkeley Laboratory, 1988. https://www.tcpdump.org
KERNIGHAN, B.; RITCHIE, D. The C Programming Language. Prentice Hall, 1978. https://archive.org
LAMPORT, L. Password Authentication with Insecure Communication. 1981. https://lamport.azurewebsites.net
LAMPSON, B. A Note on the Confinement Problem. Communications of the ACM, 1974. https://dl.acm.org
MORRIS, R.; THOMPSON, K. Password Security: A Case History. Communications of the ACM, 1979. https://dl.acm.org
NEUMANN, P. Computer Security Evaluation. 1978. https://www.csl.sri.com
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. CACM, 1974. https://dl.acm.org
SALTZER, J.; SCHROEDER, M. The Protection of Information in Computer Systems. CACM, 1975. https://dl.acm.org
SPAFFORD, E. The Internet Worm Program. Purdue Technical Report, 1989. https://docs.lib.purdue.edu
STALLINGS, W. Data and Computer Communications. Macmillan, 1985. https://archive.org
TANENBAUM, A. Computer Networks. Prentice Hall, 1981. https://archive.org
THOMPSON, K. Reflections on Trusting Trust. Communications of the ACM, 1984. https://dl.acm.org
WARE, W. Security Controls for Computer Systems. RAND Corporation, 1970. https://www.rand.org
ANDERSON, J. Computer Security Threat Monitoring. 1980. https://csrc.nist.gov
BELL, D. Looking Back at the Bell-LaPadula Model. 1985. https://www.mitre.org
DENNING, P. The Working Set Model for Program Behavior. 1968. https://dl.acm.org
GARBINKEL, S.; SPAFFORD, G. Practical UNIX Security (early technical notes). 1989. https://docs.lib.purdue.edu
POSTEL, J.; REYNOLDS, J. Assigned Numbers. RFC 790, 1981. https://www.rfc-editor.org
SHANNON, C. Communication Theory of Secrecy Systems. Bell Labs, 1949. https://archive.org