Sistemas operacionais imutáveis e baseados em imagem

Parte: Engenharia · Capítulo: Sistemas operacionais imutáveis e baseados em imagem · Edição: 2026-11-13
Palavras-chave: sistema operacional imutável, atualizações por imagem, OSTree, bootc, NixOS, Fedora Silverblue, arranque medido, TPM, SELinux, atualização atômica
Glossário: sistema operacional imutável, OSTree, bootc, modo de verificação — ver GLOSSÁRIO

Em resumo

• Um sistema operacional imutável e baseado em imagem trata o anfitrião em execução como uma imagem versionada: substitui-se o conjunto como unidade, e é possível reverter.
• As perguntas de desenho são o que fica congelado, o que permanece estado, como se identifica uma atualização, e como uma afirmação sobre esse sistema pode ser verificada.
• Sistemas públicos como OSTree, bootc, Fedora Silverblue e NixOS aparecem aqui apenas como ilustrações.

Referências online (verificadas)

• Operating system
• OSTree
• NixOS
• Fedora Silverblue
• Trusted Platform Module
• SELinux
• bootc

Instantâneos offline (proteção contra links quebrados)

Instantâneo offline omitido nesta edição web. Instantâneo offline · Operating system · https://en.wikipedia.org/wiki/Operating_system · recuperado em 2026-07-12

Operating system

Instantâneo offline omitido nesta edição web. Instantâneo offline · Computer security · https://en.wikipedia.org/wiki/Computer_security · recuperado em 2026-07-12

Computer security

Instantâneo offline omitido nesta edição web. Instantâneo offline · Zero trust · https://en.wikipedia.org/wiki/Zero_trust_security_model · recuperado em 2026-07-12

Zero trust security model

Este capítulo é um relato geral dos sistemas operacionais imutáveis e baseados em imagem: os princípios, as arquiteturas usuais, os compromissos de desenho e um pequeno modelo de referência para falar do que de fato se pode verificar. É orientação, não um prospecto de produto e não um manual de instalação.

Aplicações na Keyne Digital Assets

A integridade do caminho de arranque, das imagens de sistema e de um controle de mudanças conservador importa em qualquer ambiente que armazena conhecimento em evolução. O Situation Monitor e os serviços que oferecemos — engenharia de software, ciência de dados e consultoria — dependem do trato cuidadoso de fontes e de caminhos de escrita; este capítulo orienta essa preocupação. Não acrescentamos um produto de sistema operacional à oferta pública do Situation Monitor, e não afirmamos que uma distribuição particular baseada em imagem faça parte desse produto.

Índice de Engenharia — um mapa curto das mesmas ideias: identidade da imagem, atualizações atômicas e quatro modos de verificação. Ficha: Engenharia.

---

1. Princípios

No modelo convencional baseado em pacotes, a máquina em execução é o resíduo de muitas instalações e atualizações incrementais. Dois anfitriões que começaram no mesmo instalador podem divergir. Na família imutável e baseada em imagem, o sistema em execução está mais próximo de um artefato versionado: uma árvore, uma imagem ou uma geração que se pode nomear, comparar, substituir como unidade e reverter.

Alguns princípios se repetem.

A identidade é um digest, não um apelido. Um caminho de atualização sério fixa um hash de conteúdo, um commit OSTree, uma geração Nix ou o digest de uma imagem. Etiquetas como latest ou stable são conveniências, não identidade.

A imagem é somente leitura; o estado é explícito. Em geral /usr (e, com frequência, a maior parte de /etc tal como veio na imagem) é imutável em tempo de execução. Dados mutáveis vivem em lugares designados — /var, /home, talvez uma sobreposição gravável ou um conjunto de montagens. A pergunta de desenho não é “pode alguma coisa mudar”, e sim “quais mudanças fazem parte da imagem, e quais são estado local.”

As atualizações são transações. A próxima árvore é montada por completo; em seguida o carregador de arranque (ou um equivalente) aponta para ela. Uma atualização falha deixa a geração anterior inicializável. Este é o sentido operacional de atomicidade aqui: o anfitrião não passa tempo com um conjunto de pacotes pela metade.

A política é mais útil quando é estrutural. Um kernel que ainda recusa uma escrita depois da reinicialização, depois de uma atualização e depois de um processo privilegiado dentro do seu isolamento é uma afirmação mais forte do que uma linha de registro que diz que um caminho era somente leitura. Opções de montagem como noexec,nosuid,nodev, o SELinux (ou um MAC equivalente) e o acesso a repositórios pessoais por omissão de negação são exemplos de política estrutural. Não resolvem todos os problemas — em particular, não contêm por si sós a condução semântica de um modelo — mas são o tipo de controle que um auditor pode sentar e tentar quebrar.

A composição precisa de um artefato nomeado em cada fronteira. Se um sistema fixa um conjunto de pacotes, outro produz um armazém de derivações, e um terceiro implanta uma árvore inicializável, “reproduzível” ainda não é um procedimento até que se publique a função que transforma o primeiro no segundo e no terceiro. Um anfitrião reconstruível precisa de um artefato que um terceiro possa calcular o hash e comparar.

---

2. Arquiteturas e ilustrações públicas

Estes são modelos de referência, não um catálogo de produtos que entregamos.

OSTree guarda árvores de sistema de arquivos por hash de conteúdo e faz o checkout de uma implantação que o carregador de arranque pode iniciar. O Fedora Silverblue é a ilustração de desktop mais conhecida: o sistema é uma árvore, pacotes empilhados são uma válvula de escape, e o software do dia a dia costuma viver em contentores ou numa caixa de ferramentas, e não num /usr mutado.

bootc toma o hábito de construir e assinar imagens OCI e usa-o para o próprio anfitrião. A unidade prática que se fixa e se transporta é o digest da imagem; o OSTree permanece, no desenho atual, o mecanismo de implantação em disco. Para uma única estação de trabalho, fixar esse digest costuma bastar para dizer “esta máquina arrancou aquela árvore.” Um parque grande que já espelha RPMs para muitas máquinas pode ainda querer uma fábrica de conteúdo à frente; um único anfitrião não precisa disso.

NixOS é um substrato diferente, com uma moral semelhante. O estado desejado é declarado; o armazém é endereçado por conteúdo; as gerações podem ser revertidas. O Nix também pode ficar ao lado de um anfitrião baseado em imagem: um construtor que produz uma imagem bootc ou de disco, sem que o Nix seja o que o portátil arranca. Misturar Nix, uma visão de conteúdo RPM e uma implantação OSTree sem nomear o artefato que atravessa cada fronteira é o modo como “reproduzível” vira prosa, e não um procedimento.

As partições A/B são o primo mais próximo do hardware: duas (ou mais) ranhuras, uma ativa, outra atualizada, depois uma troca. A ideia é a mesma — substituir uma unidade, conservar um recurso — mesmo quando o armazém não é endereçado por conteúdo.

Outros sistemas públicos vivem no mesmo bairro (openSUSE MicroOS, descendentes do Flatcar / Container Linux, Ubuntu Core). Diferem no empacotamento, nos servidores de atualização e na política padrão; compartilham o hábito da imagem ou da geração.

---

3. Compromissos de desenho

Selagem versus trabalho do dia a dia. Um anfitrião que não se pode mutar no lugar é mais fácil de raciocinar e mais difícil de depurar com os reflexos antigos (instale este pacote até funcionar). Escapes comuns — empilhar pacotes, uma caixa de ferramentas privilegiada, um contentor com o sistema de arquivos do anfitrião montado — reintroduzem a deriva se passarem a ser o sistema de verdade. O compromisso é honesto quando esses escapes são nomeados e limitados.

Estado versus imagem. Diretórios pessoais, registros, armazenamento de contentores, segredos e bases de dados têm de viver em algum lugar. Se entram na imagem, cada atualização vira um problema de migração de dados. Se são montagens ilimitadas, o “anfitrião imutável” é um /usr somente leitura com um universo gravável ao lado. Bons desenhos enumeram os volumes de estado e a política de montagem em cada um deles.

Reprodutibilidade versus conveniência. Etiquetas flutuantes constroem depressa e divergem. Entradas fixadas e um segundo construtor são mais lentos, e são o que “reproduzível” significa. O mesmo vale para pesos de modelo e ficheiros de política se o anfitrião executa agentes: um artefato não fixado falseia um replay bit a bit mesmo quando o digest do sistema está fixado.

Densidade de isolamento. Espaços de nomes e cgroups do Linux, com um MAC como o SELinux, compartilham o kernel com o anfitrião: são densos e rápidos, e uma exploração do kernel é uma exploração do anfitrião. Uma microVM (Kata Containers, Firecracker, ou um kernel convidado semelhante) sobe a fronteira, ao custo de um monitor de máquinas virtuais, kernels convidados, blocos de firmware e uma história mais difícil para GPU, USB e árvores compartilhadas. Um emulador completo é ainda mais pesado. “Espaços de nomes e uma microVM e um emulador completo” são três produtos, não uma bandeira. Enquanto uma carga não exigir o modelo extra de dispositivos, um nível quotidiano e um nível mais forte costumam ser toda a história — e a razão pela qual uma carga foi colocada num nível deve constar do registro.

Armazenamento preso à topologia. Manter os dados na máquina que executa a carga, sem um sistema de arquivos em rede no caminho, é um desenho claro. Ele implica, em silêncio, uma regra de colocação: se o volume vive no nó A, o trabalho tem de correr no nó A, e se A falha o volume não está em B. Isso é um problema de escalonador, use-se ou não o Kubernetes.

Firmware e atestado são perfis, não um slogan. “O TPM é a raiz de confiança, portanto a afirmação é a mesma num desktop, num portátil e numa instância em nuvem” é depressa demais.

O coreboot existe nas placas que têm porte. A maior parte dos modelos de prateleira, e uma gota de nuvem pública, não têm. O Intel Management Engine (e o Platform Security Processor da AMD) é um computador à parte no chipset; “neutralizado” é um firmware reduzido, não “desaparecido.” A medição dinâmica (um lançamento tardio depois do firmware inicial) é um piso opcional mais apertado, não o padrão. Uma afirmação conservadora e verificável em hardware comum fica mais perto de: UEFI de fábrica, Secure Boot, uma imagem unificada de kernel, e uma citação TPM2 ligada ao digest da imagem, em máquinas que de fato têm um TPM2.

---

4. O que se pode verificar: quatro modos de verificação

Ajuda dizer, para cada afirmação, de que modo ela pode ser verdadeira. Suavizar uma afirmação que não cabe num modo é melhor do que inflar o modo.

Dois cortes pertencem a este vocabulário.

A execução de código carregada no conteúdo é um problema de isolamento; a condução semântica carregada no conteúdo é um problema de modelo. Um diretório de documentos com noexec e uma concessão estreita delimitam o primeiro. Não fecham um prompt que viaja dentro de um ficheiro que o agente tem permissão de ler. Quem afirma um fechamento completo desse segundo problema só com política de montagem está a reivindicar demais; o resto honesto é o raio de alcance e um incidente reconstruível.

Os internos de um modelo são observados, não atestados. Instrumentos como autoencoders esparsos treinados sobre ativações de um modelo são ferramentas reais de pesquisa em pesos abertos. São por modelo, por camada, por treino; a cobertura é parcial; não há ativação dourada; um detetor pode ser otimizado contra ele depois de público. Isso sustenta uma decomposição offline de uma execução suspeita — pesos fixados, semente registrada, estados gravados — que é uma forma de replay. Não é um controle de sistema operacional no sentido em que mount -o noexec ou uma negação SELinux o são. Colocar os dois na mesma frase mistura uma recusa do kernel com uma pista estatística.

O próprio replay se divide. O replay bit a bit só se sustenta num mundo fechado: pesos fixados, kernels fixados, semente registrada, recuperação congelada, sem rede ao vivo. Uma chamada de ferramenta que toca o correio ou a web falseia o “resultado idêntico.” Uma forma mais fraca, ainda útil, é o replay validável: recibos ou registros que um validador ainda aceita, e que rejeita depois da alteração de um único campo. A segunda não deve ser vendida, em silêncio, como a primeira.

Uma fatia pequena e conservadora que muitas vezes basta para raciocinar — não um nome de produto, apenas um mínimo pedagógico — é: um digest de imagem fixado, montagens por omissão de negação com noexec em dados, um nível de isolamento por espaços de nomes, concessões e recibos que um validador possa rejeitar, e uma máquina com TPM2 se afirmar atestado. Pisos de firmware mais fortes, escalonadores de agrupamento, microVMs e instrumentos no nível do modelo podem entrar quando uma carga os force, cada um com o seu modo de evidência.

---

5. Páginas relacionadas

• Índice de Engenharia
• Sistemas do tipo Unix
• Cibersegurança
• Arquitetura de computadores
• Aprendizado de máquina: LLMs
• Knowledge OS

---

Orientação, 2026-11-13. Os exemplos públicos evoluem; consulte a documentação de origem para formatos de imagem e ferramentas atuais. Afirmações sobre um sistema em execução só são verificáveis no modo que lhes cabe.