Erik Inkinen

O que é um sistema operacional baseado em capacidades

Thu, 16 Apr 2026 00:00:00 +0000

Os sistemas operacionais modernos impõem limites de segurança entre processos, arquivos, dispositivos e usuários. No entanto, a forma como esses limites são implementados varia significativamente entre diferentes projetos de sistema.

A maioria dos sistemas operacionais convencionais depende de controle de acesso baseado em identidade e de espaços de nomes globais. Sistemas operacionais baseados em capacidades adotam uma abordagem fundamentalmente diferente: representam a autoridade explicitamente e a tornam um conceito de primeira classe.

Este artigo apresenta sistemas baseados em capacidades, explica como eles diferem de modelos tradicionais e descreve por que são centrais para o design do EriX.

O problema: autoridade ambiente

Em sistemas tradicionais, processos frequentemente têm acesso a recursos por meio de autoridade ambiente.

Autoridade ambiente significa que um programa pode acessar um recurso simplesmente porque ele existe em um espaço de nomes compartilhado e o sistema determina que o programa tem permissão para usá-lo.

Por exemplo:

Um processo pode abrir /etc/passwd se tiver permissões suficientes.
Um programa pode se conectar a um socket de rede se o sistema operacional permitir.
Um serviço pode acessar arquivos com base na identidade do usuário ou na associação a grupos.

Em todos esses casos, a autoridade para acessar o recurso é implícita.

O processo não possui uma referência direta e explícita ao recurso. Em vez disso, depende de:

nomes globais (caminhos de arquivo, portas, identificadores de dispositivo)
verificações de acesso (IDs de usuário, permissões, ACLs)

Esse modelo cria vários problemas:

1. Problema do delegado confuso

Um programa pode acidentalmente usar sua autoridade de forma indevida em nome de outro programa.

Por exemplo, um serviço privilegiado pode ler um arquivo solicitado por um cliente não confiável, mesmo que esse cliente não devesse ter acesso a ele.

2. Autoridade ampla demais

Programas frequentemente executam com mais permissões do que realmente precisam. Isso aumenta o impacto de bugs ou comprometimentos.

3. Raciocínio difícil

É difícil determinar o que um processo pode fazer sem analisar o estado global, as identidades de usuário e as políticas de controle de acesso.

A ideia central: capacidades

Uma capacidade é um token não falsificável que concede acesso a um objeto específico com direitos específicos.

Em vez de perguntar:

“Este processo tem permissão para acessar este recurso?”

um sistema baseado em capacidades pergunta:

“Este processo possui uma capacidade que autoriza esta operação?”

Se a resposta for não, a operação não pode prosseguir.

Propriedades das capacidades

Capacidades têm várias propriedades definidoras:

1. Não falsificabilidade

Um processo não pode criar uma capacidade válida do nada.

Capacidades são criadas e gerenciadas pelo kernel, o que garante que não possam ser falsificadas nem adivinhadas.

2. Autoridade explícita

Toda autoridade é representada explicitamente por meio de capacidades.

Se um processo pode executar uma operação, ele deve possuir uma capacidade que a permita. Não existe acesso implícito por meio de espaços de nomes globais.

3. Direitos granulares

Capacidades podem codificar permissões específicas, como:

acesso somente leitura
acesso de escrita
permissões de execução
subconjuntos limitados de operações

Isso permite controle preciso sobre o que cada processo pode fazer.

4. Transferibilidade

Capacidades podem ser transferidas entre processos, normalmente por meio de comunicação entre processos (IPC).

Isso permite delegação controlada de autoridade.

Objetos e capacidades

Em um sistema baseado em capacidades, tudo é modelado como um objeto:

regiões de memória
arquivos
dispositivos
endpoints de IPC
processos

Uma capacidade é uma referência a um objeto combinada com um conjunto de direitos.

Um processo interage com o sistema invocando operações sobre objetos por meio de suas capacidades.

Não há necessidade de nomes globais como caminhos de arquivo ou identificadores de dispositivo dentro do kernel. Todo acesso é mediado por capacidades.

Como sistemas baseados em capacidades funcionam

Em alto nível, um sistema baseado em capacidades funciona assim:

O kernel cria objetos e capacidades.
Cada processo possui um espaço de capacidades (frequentemente chamado de CSpace), que armazena suas capacidades.
Um processo só pode operar sobre objetos para os quais possui capacidades.
Capacidades podem ser transferidas entre processos por meio de IPC.
O kernel impõe todas as verificações de capacidades.

Isso resulta em um sistema no qual a autoridade é:

explícita
localizada
transferível
fácil de analisar

Exemplo: abrir um arquivo

Modelo tradicional

Em um sistema tradicional:

Um processo chama open("/etc/config")
O kernel verifica permissões:
- ID de usuário
- associação a grupos
- bits de modo do arquivo
Se permitido, um descritor de arquivo é retornado

A autoridade vem de estado global e identidade.

Modelo baseado em capacidades

Em um sistema baseado em capacidades:

Um processo já deve possuir uma capacidade de arquivo
Ele usa essa capacidade para realizar operações de leitura ou escrita

Se o processo não tiver a capacidade, ele não poderá acessar o arquivo, independentemente do nome que usar.

Não existe etapa de busca global dentro do kernel.

Delegação e menor privilégio

Um dos aspectos mais poderosos de sistemas baseados em capacidades é a delegação.

Um processo pode dar a outro processo um subconjunto de sua autoridade transferindo uma capacidade.

Por exemplo:

Um servidor de arquivos dá a um cliente acesso somente leitura a um arquivo
Um gerenciador de memória concede acesso a uma região específica de memória
Um processo concede acesso a um endpoint de IPC

Isso viabiliza o princípio do menor privilégio:

Cada componente recebe apenas a autoridade de que realmente precisa.

Eliminando a autoridade ambiente

Sistemas baseados em capacidades eliminam completamente a autoridade ambiente.

Não há:

espaços de nomes globais dentro do kernel
acesso implícito baseado em identidade
privilégios ocultos

Toda autoridade deve ser passada explicitamente.

Isso torna muito mais fácil analisar:

o que um processo pode fazer
como a autoridade flui pelo sistema
onde podem surgir problemas de segurança

Revogação (um problema difícil)

Um dos desafios em sistemas baseados em capacidades é a revogação.

Depois que uma capacidade é dada a um processo, como ela pode ser retirada?

Diferentes sistemas implementam revogação de maneiras diferentes:

camadas de indireção
rastreamento de referências
árvores de capacidades
mecanismos de versionamento

Revogação é uma área importante de pesquisa e será explorada em estágios posteriores do EriX.

Sistemas baseados em capacidades na prática

Ideias baseadas em capacidades não são novas. Vários sistemas as implementaram:

KeyKOS / EROS
seL4 (um micronúcleo formalmente verificado)
CHERI (capacidades assistidas por hardware)
Capsicum (extensões de capacidades para FreeBSD)

Esses sistemas demonstram que projetos baseados em capacidades são ao mesmo tempo práticos e poderosos.

Como o EriX usa capacidades

O EriX foi projetado desde o início como um sistema baseado em capacidades.

No EriX:

toda autoridade é representada por meio de capacidades
capacidades são fortemente tipadas
capacidades são imutáveis depois de criadas
capacidades são transferidas via IPC
o kernel impõe não falsificabilidade e invariantes de segurança

Não há espaços de nomes globais dentro do kernel. Todo acesso a recursos é mediado por capacidades.

Isso se alinha ao objetivo mais amplo de tornar a autoridade:

explícita
mínima
fácil de analisar

Por que isso importa

Sistemas baseados em capacidades fornecem uma base para construir:

sistemas mais seguros
arquiteturas mais modulares
sistemas mais fáceis de analisar e verificar

Ao remover autoridade implícita e tornar todo acesso explícito, eles eliminam classes inteiras de vulnerabilidades comuns em sistemas tradicionais.

Olhando adiante

Capacidades são um conceito fundamental no EriX. Em artigos futuros, exploraremos como elas são implementadas na prática, incluindo:

espaços de capacidades (CSpace)
comunicação entre processos (IPC)
gerenciamento de memória usando capacidades não tipadas
delegação e grafos de autoridade

Entender capacidades é o primeiro passo para entender o restante do sistema.

Por que estou construindo um micronúcleo baseado em capacidades do zero

Wed, 11 Mar 2026 00:00:00 +0000

Os sistemas operacionais estão entre os programas mais complexos já construídos. Eles gerenciam memória, escalonam computação, controlam hardware e impõem os limites de segurança que protegem cada aplicação em execução em uma máquina.

Ainda assim, muitos dos sistemas operacionais dos quais dependemos hoje foram construídos sobre ideias arquitetônicas que remontam a várias décadas. Embora esses sistemas sejam extraordinariamente poderosos e bem testados, eles também carregam décadas de complexidade acumulada.

Este projeto explora uma direção diferente: construir um sistema operacional moderno de micronúcleo baseado em capacidades do zero, com forte foco em autoridade explícita, base de computação confiável (TCB) mínima e separação estrita entre núcleo e espaço de usuário.

Este sistema operacional se chama EriX.

Por que construir outro sistema operacional?

À primeira vista, construir um novo sistema operacional parece desnecessário. Sistemas maduros como Linux, Windows e BSD já existem e alimentam bilhões de dispositivos.

No entanto, esses sistemas evoluíram sob restrições históricas. Com o tempo, acumularam camadas de abstrações, mecanismos de compatibilidade e interfaces legadas. Embora esses recursos sejam frequentemente necessários em software do mundo real, eles também dificultam experimentar ideias arquitetônicas fundamentalmente diferentes.

Sistemas operacionais de pesquisa há muito tempo exploram abordagens alternativas para o projeto de sistemas operacionais. Micronúcleos, sistemas de capacidades e núcleos formalmente verificados demonstraram que é possível construir sistemas menores, mais seguros e mais fáceis de raciocinar.

O objetivo do EriX não é substituir os sistemas operacionais existentes. Em vez disso, é uma exploração de como um sistema operacional moderno poderia ser projetado se começarmos de primeiros princípios.

Micronúcleos e a base de computação confiável

Uma das ideias centrais por trás do EriX é a arquitetura de micronúcleo.

Kernels monolíticos tradicionais incluem muitos serviços diretamente dentro do próprio núcleo. Isso frequentemente inclui:

controladores de dispositivos
sistemas de arquivos
pilhas de rede
subsistemas de gerenciamento de processos

Embora essa abordagem possa ser eficiente, ela também aumenta o tamanho da base de computação confiável (TCB). A TCB inclui cada parte de código que precisa se comportar corretamente para que o sistema permaneça seguro e confiável.

Micronúcleos adotam uma abordagem diferente.

Um micronúcleo mantém dentro do núcleo apenas os mecanismos mais fundamentais, tipicamente incluindo:

escalonamento de threads de execução
gerenciamento de espaço de endereçamento
comunicação entre processos (IPC)
gerenciamento de capacidades
tratamento de interrupções e exceções

Todo o resto roda em espaço de usuário, incluindo controladores, sistemas de arquivos e serviços de nível mais alto.

Esse projeto reduz drasticamente a quantidade de código em que é necessário confiar. Falhas em componentes de espaço de usuário têm menor probabilidade de comprometer todo o sistema, e componentes individuais podem ser reiniciados ou substituídos sem derrubar o núcleo.

Segurança baseada em capacidades

Outro princípio central de projeto do EriX é a segurança baseada em capacidades.

A maioria dos sistemas operacionais depende fortemente de autoridade ambiente. Nesses sistemas, processos frequentemente têm acesso implícito a recursos com base em espaços de nomes globais, identidades de usuário ou privilégios herdados.

Por exemplo, um processo pode abrir um arquivo simplesmente porque conhece o caminho do arquivo e o sistema operacional decide que o processo tem permissão para acessá-lo.

Sistemas de capacidades adotam uma abordagem diferente.

Uma capacidade é um token infalsificável que concede acesso a um objeto específico com direitos específicos. Um processo só pode acessar um objeto se possuir uma capacidade que autorize esse acesso.

Capacidades têm várias propriedades importantes:

Elas representam autoridade explicitamente.
Elas podem ser transferidas entre processos.
Elas podem restringir operações a um conjunto preciso de direitos.

Em um sistema baseado em capacidades, a autoridade flui por transferências explícitas em vez de espaços de nomes globais. Isso torna o sistema mais fácil de raciocinar e ajuda a eliminar classes inteiras de vulnerabilidades de segurança.

Por que Rust?

Sistemas operacionais são tradicionalmente escritos em C ou assembly. Essas linguagens fornecem controle preciso sobre hardware e memória, mas também tornam fácil introduzir bugs sutis.

Bugs de segurança de memória, como uso após liberação, estouros de buffer e corridas de dados, têm sido historicamente uma das maiores fontes de vulnerabilidades em software de sistemas.

EriX é escrito principalmente em Rust.

Rust fornece fortes garantias de segurança de memória enquanto ainda permite controle de baixo nível sobre hardware. O modelo de propriedade da linguagem ajuda a evitar muitas classes de bugs em tempo de compilação, enquanto seus blocos unsafe explícitos tornam operações potencialmente perigosas visíveis e auditáveis.

Usar Rust não elimina todos os erros possíveis, mas eleva significativamente a linha de base de segurança na programação de sistemas.

Um sistema operacional de sala limpa

Um aspecto incomum do projeto EriX é sua abordagem de desenvolvimento em sala limpa.

Todos os componentes do sistema são implementados dentro do próprio projeto. Nenhum código-fonte externo é copiado ou incorporado, e nenhuma biblioteca de terceiros é usada.

Essa restrição serve a vários propósitos:

Ela garante que todo o sistema possa ser compreendido e auditado.
Ela evita dependências ocultas e comportamentos inesperados.
Ela força decisões arquitetônicas a serem explícitas, em vez de herdadas.

O desenvolvimento em sala limpa também transforma o projeto em um exercício educacional. Cada subsistema, do carregador de inicialização ao gerenciador de memória, precisa ser projetado e implementado deliberadamente.

Um objetivo de longo prazo: auto-hospedagem

Um dos objetivos de longo prazo do EriX é a auto-hospedagem.

Um sistema é considerado auto-hospedado quando consegue compilar seu próprio código-fonte usando ferramentas que rodam no próprio sistema.

Para o EriX, isso significa que, eventualmente:

o compilador Rust roda no EriX
as ferramentas de compilação rodam no EriX
todo o sistema operacional pode ser compilado nativamente dentro do EriX

Alcançar esse marco exige implementar muitas camadas de infraestrutura, incluindo sistemas de arquivos, gerenciamento de processos e um ambiente de espaço de usuário compatível com POSIX.

Por que documentar a jornada?

Construir um sistema operacional é um processo longo e complexo. Muitas das percepções mais interessantes não aparecem no sistema final, mas nas decisões, compromissos e erros encontrados ao longo do caminho.

Este blog documenta o desenvolvimento do EriX à medida que ele evolui. Posts futuros abordarão tópicos como:

projetar um formato de imagem de inicialização
implementar espaços de capacidades
construir um sistema de IPC
gerenciar autoridade de memória
construir servidores em espaço de usuário

O objetivo é tornar o processo de desenvolvimento transparente e educativo.

Olhando adiante

O EriX ainda está em seus estágios iniciais. Grande parte do sistema ainda precisa ser construída, e muitas decisões de projeto certamente evoluirão ao longo do tempo.

Mas os princípios orientadores já estão claros:

núcleo mínimo
autoridade explícita
segurança baseada em capacidades
modularidade estrita
implementação em sala limpa

No próximo post, exploraremos uma das ideias centrais por trás do sistema:

o que são sistemas operacionais baseados em capacidades e por que eles importam.

Sobre mim

Mon, 01 Jan 0001 00:00:00 +0000

Estudo tecnologia da informação na Universidade de Tampere. No meu tempo livre, contribuo para software livre e de código aberto, distribuições de software e projetos de sistemas baseados em capacidades, como EriX Project, AES, Cutie Shell Project e Droidian GNU/Linux.

Utilizei várias linguagens de programação. Por exemplo, C, C++, Python, JavaScript e Rust são linguagens com as quais tenho familiaridade por meio de trabalho prático. Também tenho experiência com linguagens de marcação comuns, como HTML e QML. Além disso, utilizei frameworks de software conhecidos, incluindo Qt Framework.

Além disso, contribuí para bibliotecas de software e escrevi documentação de referência para elas. Meu trabalho nesses projetos inclui tanto trabalho em equipe com outros contribuidores quanto pesquisa e implementação independentes.

Tenho experiência com a metodologia DevOps, que enfatiza a integração e a automação de vários processos de desenvolvimento e entrega de software. Tanto no Droidian quanto no Cutie Shell Project, os patches são mesclados na branch principal o mais cedo possível. Adições maiores de funcionalidades são desenvolvidas inicialmente em branches de funcionalidade. No entanto, todas as branches de funcionalidade em andamento são rebaseadas na branch principal com frequência, para que possam ser mescladas a qualquer momento. Tanto a branch principal quanto as branches de funcionalidade são compiladas e empacotadas após cada commit. Além do repositório de produção, existem o repositório de homologação e repositórios de funcionalidade correspondentes a cada branch de funcionalidade. Esses repositórios de pacotes são usados para automatizar com facilidade a criação de um ambiente de testes.

Também me interessam as línguas naturais e estudá-las. Como resultado, falo vários idiomas.

Projetos

EriX Project : 2/2026-

https://git.erikinkinen.fi/erix

“Um sistema operacional de micronúcleo, baseado em capacidades e desenvolvido em sala limpa, escrito inteiramente em Rust.”

AES : 1/2026-
https://git.erikinkinen.fi/erikinkinen/AES

“AES (Authority Evolution Simulator) é um simulador de pesquisa para estudar como a autoridade evolui ao longo do tempo em sistemas baseados em capacidades.”

Droidian GNU/Linux : 3/2021-

https://droidian.org/ / https://github.com/droidian/

“Droidian é uma distribuição GNU/Linux baseada em Debian para dispositivos móveis. O objetivo do Droidian é conseguir executar Debian em telefones Android. Isso é alcançado com o uso de tecnologias conhecidas, como libhybris e Halium.”

Um vídeo meu apresentando o Droidian no Volla Community Days 2021:

Cutie Shell : 8/2021-

https://cutie-shell.org/ / https://github.com/cutie-shell/

“Cutie Shell tem como objetivo ser uma interface móvel bonita e fácil de usar para dispositivos Linux executando Halium ou Linux mainline. Nossa interface é inspirada no Sailfish OS da Jolla, mas não buscamos criar um clone. Uma grande diferença em relação ao Sailfish OS é que nosso código-fonte é totalmente aberto.”

Um vídeo meu apresentando o Cutie Shell no Volla Community Days 2023:

Outro vídeo meu apresentando o progresso do Cutie Shell no Volla Community Days 2024:

Educação

Universidade de Tampere : 9/2022-
Estudos de bacharelado em Tecnologia da Informação

Atualmente, estou cursando o bacharelado e meu objetivo é concluir um mestrado.

Helsingin matematiikkalukio : 8/2018-5/2022
Ensino secundário geral finlandês

Competências linguísticas

Finlandês	nativo
Inglês	avançado
Espanhol	avançado
Catalão	intermediário
Sueco	intermediário
Francês	básico