Proteção, isolamento e máquinas virtuais

Um programa precisa de liberdade suficiente para calcular rapidamente sem assumir o controle de todo o computador. O modo usuário permite que ele execute instruções comuns diretamente. O modo núcleo, também chamado modo supervisor, dá ao sistema operacional acesso às instruções que controlam a máquina.

Deixe o hardware aplicar os privilégios

A CPU mantém um nível de privilégio atual. Adições, leituras, escritas e saltos normalmente são executados em velocidade máxima, sujeitos às permissões de memória. O núcleo não inspeciona cada instrução por software. Isso é execução direta limitada: executar diretamente até que uma operação protegida ou uma interrupção exija o núcleo.

Uma instrução privilegiada gera uma armadilha se o código de usuário tentar executá-la. No x86-64, HLT, a escrita no registrador base da tabela de páginas CR3 e a instalação de uma tabela de interrupções com LIDT exigem privilégio de núcleo. Caso contrário, uma aplicação poderia parar a CPU, substituir suas próprias fronteiras de memória ou redirecionar o tratamento de interrupções.

Suponha que uma aplicação execute HLT. A CPU gera uma falha de proteção geral em vez de parar. Ela entra no tratador registrado pelo núcleo. O Linux normalmente envia SIGSEGV ao processo, encerrando-o enquanto outros programas continuam. A aplicação não pode escolher um endereço conveniente dentro do núcleo e começar a executá-lo ali.

Atravesse a fronteira por uma entrada controlada

Armadilhas, exceções e interrupções entram por endereços registrados pelo núcleo. O hardware altera o privilégio e transfere o controle ao tratador; o código de entrada do núcleo preserva o estado necessário para o retorno. Uma instrução especial de retorno restaura a execução em modo usuário no contador de programa salvo. No x86-64, o retorno pode usar SYSRET ou IRETQ.

O temporizador torna esse controle útil mesmo quando um programa nunca solicita um serviço. Antes de executá-lo, o núcleo programa um temporizador. Quando a interrupção chega, o escalonador pode selecionar outro processo. O código de usuário não pode desativar interrupções nem reprogramar esse temporizador, então um laço infinito não pode manter um núcleo de processamento para sempre.

Leia corretamente os diagramas de privilégios

As convenções de numeração diferem: um número menor de anel x86 significa mais privilégio, enquanto um nível de exceção ARM maior significa mais privilégio. A virtualização Intel também acrescenta operação VMX root e não root; elas são independentes do número do anel.

Mantenha identidade e modo da CPU separados

Root é uma identidade de usuário, UID 0, que o software do núcleo reconhece. O código comum de uma aplicação root ainda é executado em modo usuário e entra no núcleo por chamadas de sistema. Um driver de dispositivo executado em modo núcleo tem muito mais poder direto: um erro de memória nele pode danificar o estado do núcleo sem passar por uma verificação de permissão de arquivo.

A camada que impõe uma fronteira deve controlar a camada dentro dela. O núcleo impõe fronteiras entre processos com modos da CPU e tabelas de memória. De modo semelhante, um hipervisor controla sistemas operacionais convidados usando suporte de hardware à virtualização.

Uma chamada de sistema é uma requisição controlada de um serviço do núcleo. Abrir arquivos, criar processos e enviar dados pela rede exigem decisões que uma aplicação não pode tomar com segurança por conta própria. Entrar no núcleo dá autoridade ao tratador; isso não dá a quem fez a chamada permissão para fazer tudo que solicitou.

Acompanhe a requisição

Uma função da biblioteca C que encapsula a chamada, como open(), coloca o número da chamada e os argumentos em registradores. Ela usa SYSCALL no x86-64, SVC no ARM64 ou ECALL no RISC-V. O núcleo então:

1. Entra pelo ponto de entrada registrado e salva os registradores do usuário.
2. Seleciona o tratador na tabela de chamadas de sistema, rejeitando um número desconhecido.
3. Lê a identidade e as credenciais de quem fez a chamada a partir do processo atual.
4. Verifica argumentos, direitos de acesso e os objetos envolvidos.
5. Executa a operação ou retorna um erro.
6. Restaura o estado salvo e retorna ao modo usuário.

A identidade vem das credenciais do processo, não de um nome fornecido pelo usuário. Quem faz uma chamada não pode obter os direitos de outro usuário acrescentando o nome dele a uma requisição.

Trate argumentos como não confiáveis

Um ponteiro é apenas um número fornecido por quem faz a chamada. O núcleo deve verificar todo o intervalo de memória de usuário solicitado, incluindo seu tamanho e a direção do acesso. O Linux usa rotinas verificadas como copy_from_user e copy_to_user para atravessar a fronteira com segurança.

Em read(fd, buf, 4096), um buf que aponta para a memória do núcleo não deve se tornar um destino para dados de arquivo. O Linux retorna EFAULT para esse buffer de usuário inválido. Um erro diferente tem outra causa: write() por meio de um descritor aberto com O_RDONLY falha com EBADF, pois o descritor nunca recebeu acesso de escrita. Uma requisição comum negada retorna um erro; ela não encerra automaticamente o processo. Em C, a função que encapsula a chamada normalmente retorna −1 e define errno.

Verifique o objeto realmente usado

Uma condição de corrida entre verificação e uso (TOCTTOU) separa uma decisão do objeto que ela deveria proteger. Um programa auxiliar privilegiado verifica access("/tmp/report", W_OK) e depois abre o caminho. Um atacante substitui o caminho por uma ligação simbólica para /etc/passwd entre essas operações. O nome não muda, mas o objeto aberto é diferente.

A correção é acessar o objeto realmente aberto usando as credenciais pretendidas. Abandone privilégios antes de abrir e use opções como O_NOFOLLOW quando ligações simbólicas não forem desejadas. Copiar argumentos uma vez para a memória do núcleo também evita confiar repetidamente em dados de usuário que podem mudar; a estrutura copiada ainda deve ser validada.

Identifique em que se deve confiar

Um monitor de referência intermedeia o acesso. Ele deve ser acionado sempre que o acesso for obtido, protegido contra alterações e pequeno o suficiente para ser examinado com cuidado. Depois que o núcleo concede um mapeamento de memória, cada leitura e escrita passa pelas verificações de permissão da MMU; cada uma delas não faz uma chamada de sistema.

A base de computação confiável (TCB) é o hardware, o firmware e o software privilegiado de cujo funcionamento correto depende a proteção. Ela inclui a CPU, a cadeia de inicialização, o núcleo e componentes confiáveis de login. Transferir drivers ou sistemas de arquivos para servidores em modo usuário pode reduzir a parte dessa base que fica no núcleo, como fazem projetos de micronúcleo. Uma aplicação comum comprometida usa indevidamente os direitos que recebeu; um componente confiável comprometido pode prejudicar as próprias verificações.

A memória virtual protege programas além de traduzir endereços. Um processo pode alcançar os quadros físicos indicados por sua tabela de páginas ativa, com as permissões definidas pelo núcleo. Os quadros privados de outro processo estão ausentes; mapeamentos deliberados de memória compartilhada são uma exceção explícita.

Verifique cada acesso à memória

A unidade de gerenciamento de memória (MMU) verifica as entradas da tabela de páginas nos acessos. Permissões importantes incluem presença ou validade, permissão de escrita, acesso pelo usuário e execução. No x86, U/S distingue páginas acessíveis ao usuário de páginas exclusivas do supervisor; NX ou XD desativa a execução. O ARM chama sua restrição de execução de XN.

Uma violação gera uma falta de página. A falta informa que uma verificação de hardware falhou; o núcleo decide se essa falha é esperada e reparável. Considere duas escritas em páginas somente para leitura:

• Um processo sobrescreve uma página de código que não é de cópia na escrita. O núcleo a trata como uma escrita inválida e normalmente envia SIGSEGV.
• Após fork(), um processo escreve em dados compartilhados marcados para cópia na escrita. O núcleo aloca uma cópia privada, altera o mapeamento para permitir escrita e tenta novamente a instrução.

Ambas as faltas começam em um bit de proteção. Os registros do núcleo explicam por que os mapeamentos eram somente para leitura e determinam a resposta. Portanto, uma falta de página não é automaticamente uma falha fatal nem uma requisição para buscar dados no disco.

Proteja os mapeamentos do núcleo nos dois sentidos

Organizações tradicionais mapeiam a memória do núcleo nos espaços de endereçamento dos processos como exclusiva do supervisor, facilitando a entrada no núcleo enquanto bloqueiam leituras e escritas em modo usuário. O ataque Meltdown, de 2018, mostrou que alguns processadores podiam vazar esses dados por execução especulativa. O isolamento das tabelas de páginas do núcleo (KPTI) remove a maioria dos mapeamentos do núcleo enquanto o código de usuário é executado em sistemas afetados.

O código do núcleo também precisa de proteção contra redirecionamento para memória controlada pelo usuário. No x86, a SMEP impede a execução em modo núcleo a partir de páginas de usuário. A SMAP bloqueia acessos a dados em páginas de usuário pelo modo núcleo, exceto durante operações de cópia autorizadas deliberadamente. O ARM fornece proteções relacionadas por meio de PXN e PAN. Essas verificações reduzem as formas pelas quais um atacante pode usar um erro no núcleo para executar código ou fornecer dados falsos ao núcleo.

O acesso somente para leitura protege a integridade, não o sigilo. Se um processo pode ler uma página mapeada, ele pode conhecer seu conteúdo mesmo quando as escritas falham. Dados confidenciais devem ser inacessíveis a esse processo: deixe-os sem mapeamento ou imponha uma fronteira apropriada exclusiva do supervisor.

Dê aos dispositivos sua própria fronteira

Aplicações normalmente solicitam operações de dispositivos por meio de um driver. Os registradores de dispositivos costumam ser exclusivos do núcleo, embora um processo autorizado possa receber determinados mapeamentos, como ocorre com drivers gráficos ou entrada e saída em espaço de usuário no Linux.

Um dispositivo que realiza acesso direto à memória (DMA) lê ou escreve na RAM sem enviar esses acessos pela MMU da CPU. As permissões de página da CPU, por si só, não conseguem impedir que um dispositivo defeituoso sobrescreva os quadros de outro processo. Uma IOMMU traduz e restringe endereços de dispositivos com mapeamentos por dispositivo. Intel VT-d e AMD-Vi fornecem esse mecanismo.

Para um dispositivo atribuído a uma VM, a IOMMU restringe o DMA à memória atribuída a essa VM. O lado da CPU precisa de uma fronteira paralela: uma segunda etapa de tradução de páginas mapeia endereços físicos do convidado somente para quadros permitidos pelo hipervisor. Proteger uma carga de trabalho exige cobrir tanto os acessos da CPU quanto os acessos dos dispositivos.

Um erro de segurança de memória pode dar origem a um ataque quando dados corrompidos alteram o fluxo de controle do programa. Um estouro de buffer na pilha, por exemplo, pode sobrescrever um endereço de retorno salvo. As defesas do sistema operacional restringem o que um atacante pode fazer com esse erro; elas não corrigem a escrita incorreta.

Separe dados de código executável

O bit NX marca páginas de dados como não executáveis. O Windows chama isso de prevenção de execução de dados (DEP). Injetar instruções em um buffer na pilha é menos útil quando saltar para ele causa uma falta.

W^X, escrita ou execução, mutuamente exclusivas, é mais rígida: nenhuma página permite escrita e execução ao mesmo tempo. A DEP, por si só, não impede que um programa solicite explicitamente esse mapeamento. Sob W^X, um compilador just-in-time escreve o código gerado em memória gravável e depois altera suas permissões antes de executá-lo.

Um atacante pode, em vez disso, reutilizar instruções executáveis existentes. A programação orientada a retornos (ROP) encadeia pequenas sequências de instruções chamadas gadgets. A aleatorização do espaço de endereçamento (ASLR) altera as localizações de pilhas, áreas de alocação dinâmica, bibliotecas e programas independentes de posição, tornando os endereços dos gadgets difíceis de prever.

Com a base de uma biblioteca escolhida uniformemente entre $2^{28}$ posições, uma tentativa às cegas tem probabilidade de acerto de 1 em 268.435.456. Com apenas $2^8=256$ posições e uma organização preservada após falhas de processos trabalhadores, testar posições distintas exige no máximo 256 tentativas e, em média, 128,5. Um endereço vazado dentro de uma biblioteca conhecida revela sua base e os deslocamentos dos gadgets nessa biblioteca. Uma pilha aleatorizada separadamente ainda pode permanecer desconhecida.

Reduza os serviços que um atacante pode solicitar

Filtros seccomp do Linux restringem as chamadas de sistema que um processo pode fazer. Um renderizador de navegador, por exemplo, pode ser impedido de fazer chamadas para iniciar programas ou abrir arquivos diretamente. Os filtros são herdados pelos processos filhos e não podem ser removidos; filtros posteriores podem aumentar as restrições. Um renderizador comprometido ainda tem suas operações permitidas, então um filtro é uma fronteira em torno dos serviços, não uma prova de que o programa não tem erros. O pledge do OpenBSD e o App Sandbox do macOS fornecem restrições relacionadas.

Verifique a inicialização e preserve evidências

A inicialização segura verifica assinaturas ao longo da cadeia de inicialização. O firmware verifica um carregador de inicialização confiável; o carregador verifica o núcleo; o núcleo pode exigir módulos assinados. Um componente modificado sem uma assinatura confiável é recusado. Isso ajuda a impedir alterações persistentes no software de inicialização, mas uma assinatura válida não prova que o software não tem vulnerabilidades.

A inicialização medida registra hashes dos componentes carregados, normalmente usando um módulo de plataforma confiável (TPM). Essas medições dão suporte à atestação: outra parte pode comparar o que foi iniciado com um estado esperado. Medir e recusar a inicialização são operações diferentes.

O registro de auditoria documenta logins, falhas de autenticação, permissões negadas, alterações em contas e ações privilegiadas como sudo. Os registros ajudam na detecção e na reconstrução. Um atacante que controla um hospedeiro pode apagar registros locais, então o registro protegido ou remoto preserva evidências fora desse hospedeiro.

Atacantes podem combinar um vazamento de endereço, um erro de corrupção de memória e uma fuga do ambiente isolado. Atualizações eliminam as vulnerabilidades subjacentes que essas defesas deixam presentes.

Um login bem-sucedido associa uma identidade humana a credenciais de processo mantidas pelo núcleo. A autenticação verifica a identidade declarada; a autorização decide o que essa identidade pode fazer. Uma entidade de segurança pode ser uma pessoa ou uma conta de serviço, e processos agem em seu nome.

Leve a identidade aos programas em execução

Sistemas semelhantes ao Unix identificam usuários por UIDs numéricos e grupos por GIDs. /etc/passwd associa nomes a UIDs, diretórios pessoais e interpretadores de comandos. As comparações do núcleo usam os números: dois nomes de conta com um único UID são uma identidade para as verificações de acesso. O UID 0 é root e ignora a maioria das verificações comuns de permissão.

O Windows usa identificadores de segurança (SIDs) para usuários e grupos. O token de acesso de um processo registra seu SID de usuário, SIDs de grupos e privilégios. Nas duas plataformas, as credenciais do programa em execução fornecem a identidade para decisões posteriores.

Um login típico com senha no Linux segue esta sequência:

1. Um serviço de login privilegiado, como login, sshd ou um gerenciador gráfico de sessão, recebe as credenciais.
2. O PAM, módulos de autenticação conectáveis, verifica-as por meio dos módulos de autenticação configurados.
3. O serviço define os grupos suplementares e o GID do usuário e depois altera o UID para abandonar root.
4. Ele inicia o interpretador de comandos. Processos filhos herdam essas credenciais por fork() e normalmente as mantêm após execve().

A ordem importa. Abandonar root antes de definir os grupos pode deixar o processo sem condições de substituir sua lista herdada de grupos privilegiados. Além disso, editar a associação de uma conta a grupos não reescreve as credenciais de processos que já estão em execução; uma nova sessão de login recebe a nova lista.

Entenda uma alteração controlada de privilégio

Um processo tem um UID real, que normalmente identifica quem o iniciou; um UID efetivo, usado na maioria das verificações de acesso; e um UID salvo, que permite retornar de forma controlada após uma redução temporária. Em programas comuns, os três são iguais.

O /usr/bin/passwd, pertencente a root, ilustra o setuid. Seu modo 4755, exibido como -rwsr-xr-x, faz o UID efetivo ser root quando um usuário comum o executa. Se alice tem UID 1000, seu UID real permanece 1000 enquanto o UID efetivo passa a ser 0. O programa pode atualizar /etc/shadow e usa a identidade real de quem fez a chamada para restringir de quem a senha pode ser alterada. Um executável setgid altera de modo semelhante o grupo efetivo.

Esse pequeno programa confiável possui uma autoridade perigosa. Um erro pode expor direitos de root, então os sistemas reduzem ao mínimo os programas setuid e abandonam privilégios cedo. Para um serviço que precisa apenas de uma porta de número baixo, CAP_NET_BIND_SERVICE concede um privilégio do Linux mais restrito do que root completo.

Administre sem compartilhar uma identidade

sudo autentica o usuário que o invoca, verifica quais comandos esse usuário pode executar como qual identidade de destino e registra o uso. Sua política normalmente fica em /etc/sudoers. Identidades individuais preservam a responsabilização que se perde ao compartilhar uma senha de root. No Windows, o UAC normalmente inicia os programas de um administrador com um token filtrado e solicita consentimento para elevação.

Aplicações cotidianas devem ser executadas com direitos comuns, e serviços devem ter contas dedicadas como www-data. Assim, um visualizador de documentos comprometido herda essas credenciais limitadas em vez da autoridade completa de um administrador.

Um verificador de senha precisa reconhecer uma senha correta sem armazenar uma cópia recuperável. Ele armazena um hash de senha com as informações necessárias para repetir a verificação. No login, o sistema recalcula o hash a partir da senha digitada e compara os resultados; ele nunca descriptografa o hash armazenado.

Proteja o verificador armazenado

No Linux, /etc/shadow contém hashes de senhas protegidos. O arquivo /etc/passwd, legível por muitos usuários, contém informações de contas e um x no lugar da senha. Um campo de senha em shadow registra um identificador de algoritmo, parâmetros de custo, um sal e o hash resultante. $y$ identifica yescrypt, usado por padrão no Debian 11, Ubuntu 22.04, Fedora 35 e versões posteriores; $6$ identifica SHA-512-crypt.

Um arquivo de hashes roubado permite um ataque offline. O atacante calcula hashes de tentativas em hardware separado, sem os atrasos do serviço de login. Um ataque de força bruta enumera sequências; um ataque de dicionário começa com palavras prováveis, senhas vazadas e variações como “Senha1!”.

Para exatamente oito letras minúsculas, são possíveis ${26}^8=\mathrm{208.827.064.576}$ sequências. A ${10}^{10}$ tentativas por segundo, esgotar o espaço leva cerca de 21 segundos. A ${10}^4$ tentativas por segundo, leva cerca de $\mathrm{2,09}\times {10}^7$ segundos, aproximadamente 242 dias. Esses são tempos de busca completa, não garantias para uma senha individual. Doze letras minúsculas fornecem cerca de $\mathrm{9,5}\times {10}^{16}$ sequências, aproximadamente 110 dias mesmo na taxa mais rápida.

Torne caro atacar cada conta

Um sal criptográfico é um novo valor aleatório armazenado ao lado de cada hash de senha. Ele faz senhas iguais produzirem hashes diferentes e inviabiliza tabelas pré-calculadas reutilizáveis. O sal é público; sua função é exigir trabalho separado para contas diferentes.

Considere 1.000 contas e uma lista de ${10}^6$ tentativas, verificadas a ${10}^4$ hashes por segundo. Sem sais, calcular a lista uma vez leva 100 segundos e serve para todas as contas. Sais únicos exigem ${10}^9$ cálculos, cerca de ${10}^5$ segundos ou 27,8 horas. Uma senha comum ainda pode ser encontrada perto do início da lista.

Esquemas de hash de senhas como bcrypt, scrypt, yescrypt, Argon2 e PBKDF2 têm custos de processamento ajustáveis. Scrypt, yescrypt e Argon2 também impõem custos de memória. Um login prático pode tolerar uma fração de segundo; uma campanha de tentativas em grande escala repete esse custo milhões de vezes. Um único cálculo rápido de SHA-256 não tem esse custo deliberado.

Projete a política de login em torno das tentativas

A norma NIST SP 800-63B-4 (2025) exige sais de pelo menos 32 bits e um custo de hash de senhas tão alto quanto viável. Sua orientação para senhas exige pelo menos 15 caracteres para autenticação somente por senha, ou pelo menos oito quando a senha faz parte da MFA, e recomenda aceitar pelo menos 64 caracteres.

Ela rejeita combinações obrigatórias, como um dígito e um símbolo, e alterações periódicas forçadas de senha. Exige bloquear escolhas comuns ou comprometidas, limitar tentativas online e exigir uma alteração quando houver evidência de comprometimento. Limites de taxa online protegem o serviço em funcionamento; hashes lentos com sal protegem verificadores roubados. Uma senha mais longa escolhida de forma previsível em uma lista comum ainda pode ser fraca.

Senhas comprovam conhecimento. Outros autenticadores comprovam a posse de um objeto ou uma característica física. O sistema operacional acaba associando a identidade autenticada aos processos, mas o caminho até essa identidade afeta a facilidade com que um atacante pode se passar pelo usuário.

Combine tipos diferentes de fatores

Os três tipos de fatores são algo que você sabe, como uma senha ou PIN; algo que você possui, como um celular, cartão inteligente ou chave de segurança; e algo que você é, como uma impressão digital. A autenticação multifator (MFA) combina tipos diferentes. Uma senha mais uma pergunta de segurança repetem o fator de conhecimento.

Senhas de uso único baseadas em tempo (TOTP) usam um segredo compartilhado e um intervalo de tempo, normalmente de 30 segundos, para produzir códigos correspondentes em um autenticador e em um servidor. A RFC 6238 define o método. Um código expira rapidamente, mas uma página falsa de login pode repassar um código recente antes que ele expire. Códigos de aplicativo evitam a troca fraudulenta de chip; códigos por SMS dependem do controle do número de telefone e podem ser redirecionados se ele for tomado.

Comprove a posse sem enviar a chave

Um autenticador de chave pública assina um novo desafio com uma chave privada. O servidor o verifica com uma chave pública armazenada, que não pode, por si só, ser reutilizada para assinar um login. Chaves de segurança FIDO2 e chaves de acesso também vinculam a autenticação à identidade do site, de modo que uma resposta para um site falso não pode autenticar no verdadeiro. Uma chave SSH comum também comprova posse, mas não se deve presumir que tenha o mesmo mecanismo de vinculação ao site.

O armazenamento muda o risco. Chaves vinculadas ao dispositivo em uma chave de segurança de hardware, TPM ou enclave seguro assinam dentro do hardware sem expor a chave privada. Chaves de acesso sincronizadas copiam material de chave criptografado entre dispositivos por meio de uma conta da plataforma, facilitando a recuperação e ao mesmo tempo incluindo essa conta na fronteira de confiança. Uma chave privada SSH comum é um arquivo protegido por permissões e, opcionalmente, por uma frase secreta.

Interprete erros biométricos

Um sistema biométrico compara características medidas com um modelo armazenado. Ele aceita quando uma pontuação de similaridade atinge um limiar; não exige uma imagem idêntica a cada vez.

Dois impostores aceitos em 10.000 tentativas resultam em FAR de 0,02%. Trinta rejeições em 1.000 tentativas legítimas resultam em FRR de 3%. Aumentar o limiar de similaridade reduz a FAR e aumenta a FRR. Uma correspondência mais exigente reduz o sucesso de impostores, mas torna mais comuns novas tentativas legítimas.

Uma característica biométrica vazada não pode ser alterada como uma senha, e sensores precisam de defesas contra fotos ou impressões digitais copiadas. Um projeto útil usa biometria localmente para desbloquear uma chave protegida, enviando somente uma assinatura ao servidor.

Autentique processos também

Para uma conexão local de domínio Unix, SO_PEERCRED no Linux obtém as credenciais da outra parte a partir do núcleo, em vez de confiar em um nome enviado pelo cliente. Entre máquinas, serviços usam chaves, certificados ou tokens armazenados com acesso restrito à conta de serviço. Após o login, as verificações comuns de acesso do sistema operacional usam o UID ou token de acesso; elas não perguntam se o usuário digitou uma senha ou tocou em uma chave.

Uma decisão de acesso tem três partes: um sujeito pede para executar uma operação em um objeto. O sujeito normalmente é um processo que age em nome de uma entidade de segurança; objetos incluem arquivos, dispositivos e outros processos. Uma matriz de acesso representa os direitos em células, com sujeitos nas linhas e objetos nas colunas.

Armazene os mesmos direitos de duas formas

Suponha que alice possa ler e escrever em report.txt, bob possa apenas lê-lo e o serviço de backup possa ler tanto report.txt quanto payroll.db. Bob também pode ler e escrever em payroll.db. Alice e bob podem usar a impressora; o serviço de backup não pode. A maioria das células da matriz muito maior de um sistema real está vazia.

Uma lista de controle de acesso (ACL) armazena uma coluna junto com seu objeto. A lista de report.txt nomeia alice, bob e backup com seus respectivos direitos. Uma lista de capacidades armazena uma linha junto com o sujeito. Bob possui tokens para ler o relatório, ler e escrever na folha de pagamento e usar a impressora.

Uma capacidade identifica tanto um objeto quanto as operações permitidas e não pode ser falsificada nem ampliada por quem a possui. Cópias e delegações autorizadas são possíveis. O núcleo pode manter o token real enquanto o código de usuário mantém um índice; outro projeto protege um token com criptografia.

Acompanhe um descritor após a abertura

O Unix combina as duas abordagens. open() verifica quem fez a chamada em relação às permissões do arquivo e retorna um descritor de arquivo que registra o acesso concedido. Leituras e escritas posteriores verificam esse identificador aberto. Um processo filho pode herdá-lo por fork(), ou um processo pode recebê-lo por um socket de domínio Unix.

Alice abre app.log para escrita. Seu proprietário altera o modo para 444. O descritor de alice, já aberto, ainda pode escrever; uma nova tentativa de abrir o arquivo para escrita encontra o novo modo. Atualizar a ACL que rege aberturas futuras não cancela todas as capacidades já emitidas. Os identificadores do Windows seguem o mesmo padrão geral.

O Capsicum do FreeBSD torna isso útil para confinamento. Após cap_enter(), um processo não pode abrir um caminho absoluto arbitrário. Ele pode operar por meio de descritores existentes, receber descritores e usar openat() dentro de um diretório cujo descritor possui. Assim, um processo pai pode dar a um trabalhador exatamente os arquivos de que ele precisa. Núcleos baseados em capacidades, como seL4 e Fuchsia, estendem a ideia aos objetos do núcleo em geral.

Diferencie o outro significado de capacidade no Linux

As capacidades do Linux dividem os privilégios de root em categorias. CAP_NET_BIND_SERVICE permite a associação a portas de número baixo; CAP_DAC_OVERRIDE ignora verificações comuns de acesso a arquivos. Esses privilégios não identificam um objeto específico, então são diferentes de uma capacidade no sentido da matriz de acesso. Um único privilégio do Linux pode autorizar uma classe de operações em muitos objetos.

As permissões do Unix associam direitos ao proprietário, ao grupo proprietário e a todos os demais. Para decidir sobre o acesso, identifique primeiro a operação e o objeto relevante. Ler o conteúdo de um arquivo, atravessar um diretório e excluir um nome exigem permissões diferentes.

Decodifique e selecione os bits

Leitura é 4, escrita é 2 e execução é 1. Some esses valores para cada classe: 754 significa rwxr-xr--; 640 significa rw-r-----. chmod 640 notes.txt define um modo, enquanto chmod g+w,o-r notes.txt edita bits selecionados. O proprietário ou root pode alterar o modo; alterar a propriedade exige autoridade de root, representada por CAP_CHOWN no Linux.

O núcleo seleciona a primeira classe correspondente: proprietário se o UID efetivo corresponder, caso contrário grupo se um grupo do processo corresponder, caso contrário demais. Ele não combina classes nem tenta novamente uma mais generosa. Alice é proprietária de um arquivo de modo 077: seus bits de proprietário estão vazios, então ela não pode lê-lo, embora grupo e demais tenham direitos completos. Ela ainda pode alterar o modo como proprietária.

Root normalmente ignora as verificações de leitura e escrita. Para executar um arquivo comum sob as verificações discricionárias comuns do Linux, pelo menos um bit de execução deve estar definido. Uma política obrigatória pode impor outras restrições.

Interprete bits de diretório e bits especiais

A leitura de diretório lista nomes; a execução permite travessia e busca; a escrita junto com a execução permite criar, excluir e renomear entradas. Remover um nome altera seu diretório, então um arquivo de modo 000 pode ser excluído por alguém com os direitos necessários no diretório.

Setuid acrescenta octal 4000 ao modo de um executável e altera a identidade efetiva de usuário na execução. Setgid acrescenta 2000 e altera o grupo de modo semelhante; em um diretório, faz com que novos arquivos herdem o grupo do diretório. O bit de restrição de exclusão acrescenta 1000. Um diretório como /tmp, de modo 1777, permite exclusão ou renomeação apenas pelo proprietário do arquivo, proprietário do diretório ou um processo privilegiado, ainda exigindo as permissões comuns do diretório.

Remova bits ao criar arquivos

Uma umask limpa bits do modo solicitado por um programa. É uma operação de bits, não uma subtração octal. Com as solicitações usuais de 666 para arquivos e 777 para diretórios:

Uma umask não pode acrescentar direitos de execução ausentes da solicitação do arquivo.

Interprete listas de acesso mais detalhadas

ACLs POSIX acrescentam usuários e grupos nomeados. setfacl -m u:bob:r report.txt dá a bob uma entrada nomeada de leitura; getfacl a exibe e ls -l marca a ACL estendida com +. A máscara da ACL limita usuários nomeados, grupos nomeados e o grupo proprietário, então uma entrada nomeada pode mostrar mais direitos do que os efetivos.

O NTFS do Windows usa um descritor de segurança com um SID de proprietário e uma DACL de ACEs ordenadas que permitem ou negam acesso. A avaliação para quando um direito solicitado é negado ou todos os direitos solicitados foram concedidos; direitos não concedidos são negados. A ordem preferida coloca entradas explícitas antes das herdadas, com negações antes de permissões dentro de cada grupo. Uma permissão explícita pode, portanto, resolver uma requisição antes que uma negação herdada seja alcançada. Uma SACL separada seleciona eventos de acesso para auditoria.

Modelos diferentes de controle de acesso respondem a perguntas diferentes de gerenciamento. Quem pode conceder acesso? Um programa comprometido pode compartilhar dados de um usuário? Como um administrador pode alterar os direitos de muitos funcionários sem editar cada arquivo? Um sistema operacional pode aplicar vários modelos à mesma requisição.

Diferencie a escolha do proprietário da política do sistema

No controle de acesso discricionário (DAC), o proprietário de um objeto decide quem pode usá-lo. Modos Unix e ACLs são mecanismos conhecidos. O ponto fraco é que um programa malicioso agindo como o usuário pode exercer os direitos desse usuário, inclusive copiar para outro lugar dados que ele possa ler.

No controle de acesso obrigatório (MAC), uma política do administrador para todo o sistema limita o acesso independentemente da vontade do proprietário. O núcleo aplica o MAC além do DAC. As duas verificações devem permitir o acesso, então um modo de arquivo permissivo não anula uma negação obrigatória.

O modelo de Bell–LaPadula protege a confidencialidade com níveis ordenados e duas regras: não ler acima e não escrever abaixo. Um processo Secreto pode ler dados Confidenciais e escrever em um destino Ultrassecreto. Ele não pode ler dados Ultrassecretos nem escrever dados Confidenciais. Um programa não pode mover informações de Secreto para Confidencial simplesmente lendo-as e reescrevendo-as. O Biba inverte as direções de leitura e escrita para proteger a integridade.

Confine um serviço mesmo quando ele for root

O SELinux rotula arquivos com tipos e executa processos em domínios. A política determina qual domínio pode executar quais operações em cada tipo; o acesso não listado é negado. Um servidor web em httpd_t pode ler páginas rotuladas como httpd_sys_content_t e ser impedido de acessar user_home_t, mesmo que os modos Unix comuns permitam a leitura. ls -Z mostra os rótulos.

No modo impositivo, o SELinux bloqueia e registra violações. No modo permissivo, ele registra sem bloquear. Root em um domínio confinado ainda deve cumprir a política impositiva. UID 0 e acesso irrestrito são, portanto, afirmações diferentes.

O AppArmor confina programas com perfis baseados em caminhos de arquivos e capacidades permitidas. É comumente usado no Ubuntu e no SUSE. SELinux e AppArmor operam por meio de pontos de verificação dos módulos de segurança do Linux (LSM) nas decisões de segurança. O Android combina UIDs específicos por aplicativo com SELinux; sistemas da Apple também usam perfis de isolamento de aplicações.

Atribua funções em vez de direitos individuais

No controle de acesso baseado em papéis (RBAC), permissões são associadas a papéis e usuários são associados a esses papéis. Mudar uma pessoa de função altera suas associações em vez de muitas permissões independentes de objetos.

Suponha que 50 funcionários precisem de 20 permissões cada. A atribuição direta exige 1.000 vínculos entre usuários e permissões. Se cinco papéis tiverem 20 permissões cada e cada funcionário tiver um papel, o gerenciamento exigirá 50 vínculos entre usuários e papéis e 100 vínculos entre papéis e permissões: 150 no total. A economia vem de padrões de função compartilhados, não da exclusão de permissões necessárias.

Grupos do Windows usados como papéis e políticas de sudo baseadas em grupos implementam esse padrão. O DAC é adequado a arquivos gerenciados pelos proprietários, o MAC contém serviços sob regras aplicadas centralmente, e o RBAC organiza atribuições administrativas. Um serviço pode receber os direitos de sua função por meio de um papel enquanto o DAC e o MAC verificam seu acesso efetivo a arquivos.

Uma máquina virtual (VM) oferece a um sistema operacional completo seu próprio computador aparente. Esse sistema operacional é o convidado. O computador físico é o hospedeiro, e o hipervisor, ou monitor de máquina virtual (VMM), aloca tempo real de processador, memória e dispositivos aos convidados.

Preserve o comportamento mantendo o controle

O modelo de Popek e Goldberg, de 1974, identifica três propriedades. Equivalência significa que os programas se comportam como em uma máquina real, exceto pelo tempo e pelos recursos disponíveis. Controle de recursos significa que o hipervisor continua no comando do hardware. Eficiência significa que a maioria das instruções do convidado é executada diretamente no processador.

O hipervisor escalona CPUs virtuais (vCPUs) em núcleos físicos. Uma troca de máquina salva todo o estado de execução de uma VM, incluindo registradores privilegiados e configurações de interrupção, e depois restaura o de outra. Um convidado vê seu próprio estado mesmo quando compartilha um núcleo físico com outros convidados.

O KVM transforma o próprio núcleo Linux em um hipervisor e normalmente é classificado como tipo 1. Um hospedeiro Linux completo continua disponível, o que torna menos clara a distinção simples entre os dois tipos. Para analisar a proteção, identifique qual componente realmente controla a virtualização da CPU e da memória.

Use a abstração de máquina

A consolidação de servidores reúne sistemas pouco utilizados. Doze servidores que usam, em média, 5% de um computador de oito núcleos cada um precisam, juntos, de 60% de um desses computadores. Essa média sugere que a consolidação é possível, mas picos simultâneos, demanda de RAM e de dispositivos ainda exigem uma margem de capacidade.

Um retrato do estado salva o estado de uma VM para restauração posterior. Copiar apenas uma imagem de disco não captura o estado de uma CPU em execução e sua memória. A migração em execução transfere uma VM em funcionamento para outro hospedeiro, copiando a memória e transferindo a execução com uma breve pausa. Essas operações são possíveis porque o estado de máquina do convidado é representado como dados gerenciados pelo hipervisor.

VMs também permitem testar sistemas antigos, separar softwares incompatíveis e executar sistemas operacionais diferentes em hardware compatível. Uma VM pode executar um convidado Windows ao lado de um convidado Linux, cada um com seu próprio núcleo. Instâncias de servidores em nuvem normalmente usam essa fronteira.

Separe virtualização de emulação completa

Um emulador pode interpretar ou traduzir um conjunto de instruções para outro processador, como código ARM em x86. A virtualização por hardware normalmente executa instruções do convidado diretamente em um processador compatível e intervém em eventos sensíveis. Isso explica tanto sua velocidade quanto sua necessidade de suporte da CPU.

Núcleos convidados separados formam uma fronteira útil: assumir o controle de um núcleo convidado não dá controle direto do núcleo hospedeiro. A fronteira ainda depende do funcionamento correto do hipervisor e do código do modelo de dispositivo. Um escape de VM explora essa camada, enquanto um canal lateral pode vazar dados pelo hardware compartilhado sem conceder acesso comum à memória. Escolher uma VM reduz as interfaces expostas a um convidado não confiável; isso não torna o hardware compartilhado infalível.

Um núcleo convidado espera controlar sua máquina. O hipervisor deve preservar essa aparência sem entregar o computador real. A virtualização da CPU permite que instruções comuns do convidado sejam executadas diretamente e intercepta operações que precisam alterar o estado da máquina virtual.

Intercepte e emule o estado virtual

Na interceptação e emulação clássica, os privilégios do núcleo convidado são reduzidos. Sua tentativa de carregar um registrador de tabela de páginas ou instalar uma tabela de armadilhas gera uma armadilha para o hipervisor. O hipervisor atualiza o registrador ou a tabela virtual do convidado e retoma a execução. Ele não permite que o convidado substitua as estruturas de controle reais do hipervisor.

Uma chamada de sistema do convidado pode exigir várias travessias nessa arquitetura. A aplicação convidada gera uma armadilha para o tratador real pertencente ao hipervisor. O hipervisor transfere a execução para o tratador registrado do núcleo convidado com privilégio reduzido. Quando o núcleo convidado retorna, esse retorno privilegiado gera outra armadilha; o hipervisor conclui o retorno real à aplicação convidada.

A condição de Popek e Goldberg para essa técnica é que toda instrução sensível seja privilegiada. Sensível significa que ela altera a configuração da máquina ou se comporta de modo diferente conforme o privilégio. Privilegiada significa que ela gera uma armadilha fora do modo mais privilegiado. Diferenças silenciosas não podem ser emuladas se o hipervisor nunca souber que ocorreram.

Entenda o obstáculo do x86 clássico

A análise de Robin e Irvine, de 2000, identificou 17 instruções x86 sensíveis e não privilegiadas. Por exemplo, POPF pode restaurar o indicador de habilitação de interrupções com privilégio suficiente, mas deixá-lo inalterado silenciosamente com privilégio reduzido. Um convidado com privilégios reduzidos pode acreditar que desativou interrupções, embora nenhuma armadilha tenha informado o hipervisor para atualizar seu estado virtual de interrupção.

Três abordagens resolvem esse problema:

A VMware usou tradução binária em 1999; o Xen usou paravirtualização em 2003. O Intel VT-x chegou em 2005 e o AMD-V em 2006. Aplicações comuns do convidado ainda podem ser executadas diretamente quando o código do núcleo precisa de tradução ou hiperchamadas.

Mantenha o número do anel separado do modo de virtualização

Com Intel VT-x, o hipervisor opera em modo VMX root e um convidado em modo não root. O núcleo convidado pode usar o anel 0 nesse modo. O anel 0 em um convidado não dá controle sobre o hospedeiro físico.

Eventos configurados causam uma saída da máquina virtual, salvando o estado da vCPU em uma estrutura de controle como a VMCS. O hipervisor trata o evento e retoma a execução por uma entrada na máquina virtual. Muitas chamadas de sistema podem permanecer inteiramente dentro do convidado. O ARM usa EL2 para o hipervisor; o RISC-V fornece uma extensão de hipervisor.

Se um convidado executa HLT e esse evento está configurado para causar uma saída, o hipervisor marca sua vCPU como em espera e escalona outro trabalho até chegar uma interrupção virtual. O núcleo físico não precisa ficar ocioso. Saídas e entradas ainda custam tempo, normalmente de centenas a milhares de ciclos, então o agrupamento de operações e as interfaces paravirtuais continuam úteis.

Uma aplicação convidada usa um endereço virtual do convidado. Seu núcleo o traduz para um endereço físico do convidado, que é a visão da RAM pelo convidado. O hipervisor então mapeia esse endereço para um endereço físico do hospedeiro, ou da máquina. Cada convidado pode acreditar que sua RAM começa em zero enquanto usa quadros reais diferentes.

Preserve o deslocamento na página

Use páginas de 4 KiB. O convidado mapeia a página virtual 2 para o quadro 7 do convidado; o hipervisor mapeia o quadro 7 do convidado para o quadro 42 da máquina. Para o endereço 0x2ABC:

1. Divida-o em página 2 e deslocamento 0xABC.
2. Substitua a página 2 pelo quadro 7 do convidado, resultando em 0x7ABC.
3. Substitua o quadro 7 do convidado pelo quadro 42 da máquina, em hexadecimal 0x2A.
4. Mantenha o deslocamento, resultando no endereço da máquina 0x2AABC, ou 174.780 bytes a partir do endereço zero.

Somente o número da página muda. Tratar o endereço físico do convidado como um endereço real da RAM contornaria a decisão de alocação e isolamento do hipervisor.

Compare a tradução por software e por hardware

Tabelas de páginas sombra mapeiam páginas virtuais do convidado diretamente para quadros da máquina. A MMU real usa essas tabelas, construídas pelo hipervisor. O hipervisor protege contra escrita as páginas que contêm tabelas de páginas do convidado e intercepta alterações e trocas dessas tabelas para manter suas tabelas sombra consistentes. Alterações frequentes no espaço de endereçamento do convidado, portanto, causam armadilhas extras.

A paginação aninhada, Intel EPT ou AMD NPT, fornece as duas etapas à MMU. O hardware percorre as tabelas do convidado e as tabelas que traduzem endereços físicos do convidado para endereços da máquina. As atualizações das tabelas de páginas do convidado deixam de exigir todas uma interceptação por software. A TLB armazena em cache a tradução final combinada.

Uma ausência no cache ainda pode ser cara. Com quatro níveis em cada etapa, cada uma das quatro entradas da tabela do convidado precisa de quatro referências à tabela aninhada mais a própria entrada: 20 referências. Traduzir o endereço físico dos dados finais do convidado acrescenta mais quatro, totalizando 24 referências de tradução antes do acesso aos dados. Páginas grandes e caches de percurso de tabelas de páginas reduzem esse trabalho sem cache no pior caso.

Recupere memória com conhecimento limitado do convidado

O supercomprometimento de memória promete mais memória total aos convidados do que o hospedeiro possui. Quatro VMs de 16 GiB totalizam 64 GiB em um hospedeiro de 48 GiB. Isso só funciona enquanto suas necessidades ativas couberem na capacidade; se todas ficarem ocupadas, será necessário recuperar memória ou transferir páginas para a área de troca.

Um driver de balão dentro de um convidado aloca páginas a pedido do hipervisor. O sistema operacional convidado escolhe o que liberar, enquanto o hipervisor recupera os quadros da máquina correspondentes às páginas do balão. Isso reduz a lacuna de informação: o convidado sabe quais dados são importantes, enquanto o hipervisor vê alocações sem conhecer todo o seu significado.

O compartilhamento de páginas, como o KSM do Linux, reúne páginas idênticas em uma cópia somente para leitura e as separa em uma escrita. A troca de páginas pelo hipervisor é outra alternativa, mas pode fazer escolhas ruins por não ter o conhecimento do convidado. Um dispositivo atribuído à VM também precisa de uma IOMMU para traduzir e restringir seus endereços de DMA.

Compartilhar páginas idênticas entre clientes tem um custo de privacidade: o tempo da cópia na escrita pode revelar se outro convidado possui os mesmos dados. Provedores de nuvem normalmente desativam essa forma de compartilhamento entre clientes, embora ela economize memória.

Uma VM precisa de armazenamento, rede e outros dispositivos, além de tempo de CPU e RAM. A interface de dispositivo afeta a compatibilidade, o desempenho e o código que um convidado não confiável pode alcançar. Uma interface rápida e uma interface confiável pequena são escolhas de projeto relacionadas, mas não são a mesma propriedade.

Escolha como o convidado acessa um dispositivo

Um auxiliar como o QEMU pode emular uma placa de rede Intel e1000. O driver comum do convidado escreve em registradores conhecidos; o auxiliar implementa o efeito. Acessos frequentes a registradores podem causar muitas saídas e operações de software.

Um driver virtio, por sua vez, troca requisições por filas em memória compartilhada. Ele pode colocar várias operações na fila e notificar o componente de atendimento uma vez. O vmxnet3 da VMware e os dispositivos VMBus do Hyper-V seguem projetos relacionados, preparados para virtualização. Um driver de dispositivo paravirtual não significa que todo o núcleo convidado precise usar operações de CPU paravirtuais.

Na atribuição direta de dispositivo, o convidado recebe um dispositivo físico ou uma função virtual SR-IOV. A IOMMU limita o DMA à memória da VM. A atribuição direta reduz a mediação por software, mas transferir o estado do dispositivo para outro hospedeiro pode dificultar a migração em execução.

Trate discos virtuais como estado gerenciado

Um disco virtual normalmente é um arquivo no hospedeiro, como qcow2, VMDK ou VHDX, ou um volume de armazenamento. Imagens com cópia na escrita permitem que muitos convidados compartilhem uma base enquanto registram alterações separadas. Retratos do estado podem preservar o estado do disco com baixo custo, e um retrato completo de uma VM em execução também precisa do estado de execução e da memória. Clonagem e migração dependem da capacidade do hipervisor de gerenciar essas representações.

Localize a fronteira que um atacante precisa atravessar

Um núcleo convidado comprometido já controla essa VM, mas alcançar o hospedeiro exige um escape de máquina virtual ou outra falha de fronteira. A falha VENOM, de 2015, afetava o controlador de disquete emulado do QEMU e podia permitir que código do convidado fosse executado no processo QEMU do hospedeiro. Manter a emulação de dispositivos em um processo separado e isolado limita a autoridade exposta por esse erro.

Caches de CPU, preditores de desvio e barramentos de memória compartilhados também criam canais laterais. Spectre e L1TF mostraram que o isolamento não pode ser avaliado apenas pelos mapeamentos de páginas. Medidas de mitigação incluem atualizações do processador e do microcódigo, limpeza do estado relevante entre convidados e evitar a execução simultânea de clientes diferentes em threads de hardware do mesmo núcleo.

A computação confidencial, incluindo AMD SEV-SNP e Intel TDX, protege a memória do convidado contra o hipervisor com chaves de criptografia mantidas pelo hardware e permite atestar o ambiente iniciado. Ela estende a fronteira de confiança contra um hospedeiro ou operador comprometido. Ela não elimina todos os canais laterais nem todas as formas pelas quais um hospedeiro pode interromper o serviço. A segurança da VM ainda depende do hipervisor, das interfaces de dispositivos, do hardware e de sua configuração.

Um contêiner Linux é um conjunto de processos que usa o núcleo do hospedeiro com visões e privilégios restritos. Ele não tem núcleo separado nem computador emulado. Espaços de nomes dão aos processos instâncias privadas de recursos que, de outra forma, seriam globais.

Relacione cada espaço de nomes à sua visão

clone() com opções de espaços de nomes cria um processo filho nos novos espaços de nomes selecionados. unshare() separa o contexto de espaços de nomes, e setns() ingressa em um espaço de nomes existente por meio de um descritor, como um aberto a partir de /proc/1234/ns/net. A reassociação de PID afeta processos filhos posteriores sem mover quem fez a chamada. Para espaços de nomes de tempo, unshare(CLONE_NEWTIME) também prepara um espaço de nomes para processos filhos posteriores; setns() pode mover quem fez a chamada para um espaço de nomes de tempo existente. Espaços de nomes de tempo são criados com unshare().

Assim, unshare --pid --fork --mount-proc bash usa --fork para criar o interpretador de comandos dentro do novo espaço de nomes de PID. Esse interpretador é o PID 1 ali, mesmo que seu PID no hospedeiro seja 48213. O PID 1 adota processos órfãos; se ele terminar, o núcleo encerra os processos restantes do espaço de nomes. Processos em um espaço de nomes ancestral podem ver os descendentes, enquanto processos dentro dele não podem ver os espaços de nomes de PID ancestrais.

Separe arquivos e rede

Um espaço de nomes de montagem fornece uma lista privada de montagens. Um ambiente de execução monta uma árvore de arquivos e a torna a raiz usando pivot_root. Um contêiner pode usar /etc e /usr de outra distribuição Linux enquanto ainda faz chamadas ao núcleo do hospedeiro. chroot sozinho apenas altera o ponto inicial da busca por caminhos; ele não é uma fronteira segura contra um processo privilegiado.

Um novo espaço de nomes de rede tem uma interface de loopback. Um ambiente de execução pode conectá-lo por um par de interfaces veth, com uma extremidade dentro dele e outra conectada a uma ponte no hospedeiro. Pilhas separadas permitem que dois contêineres escutem na porta 80 sem disputar a porta de um mesmo espaço de nomes.

Traduza identidades por meio de um espaço de nomes de usuários

Uma linha em /proc/<pid>/uid_map lista o primeiro ID interno, o primeiro ID externo e o tamanho do intervalo. A linha 0 100000 65536 mapeia os IDs internos 0–65535 para os IDs 100000–165535 do hospedeiro. O UID interno 1000, portanto, é mapeado para 101000 externamente. IDs sem um mapeamento utilizável normalmente são exibidos como o UID de transbordamento 65534.

Root dentro desse espaço de nomes tem capacidades sobre recursos controlados por ele, não autoridade sobre todo o hospedeiro. Carregar um módulo do núcleo ou alterar o relógio real do sistema ainda exige privilégio no espaço de nomes de usuários inicial. Um mapeamento de UID não protege um socket privilegiado do ambiente de execução disponibilizado ao contêiner.

Uma visão privada também não limita o consumo. Um processo com seus próprios espaços de nomes de PID e montagem ainda pode consumir CPU e RAM. Cgroups limitam quantidades, enquanto limites de capacidades e seccomp restringem operações.

Um grupo de controle, ou cgroup, reúne processos para contabilização e controle de recursos. Espaços de nomes determinam sua visão; cgroups controlam quantidades como tempo de CPU, memória e número de tarefas. Processos filhos herdam o grupo do processo pai, e a hierarquia impede que um grupo filho escape dos limites de um ancestral.

Interprete os arquivos do cgroup v2

O cgroup v2 usa uma hierarquia unificada, normalmente em /sys/fs/cgroup. Um grupo pai habilita controladores para seus filhos por meio de cgroup.subtree_control, por exemplo, +cpu +memory +pids. Arquivos individuais em cada grupo filho contêm limites e contadores.

Os controladores incluem cpu, cpuset, memory, io, pids, hugetlb e rdma. Eles controlam tempo de CPU, posicionamento em CPUs e nós de memória, memória comum, entrada e saída de blocos, número de tarefas, páginas enormes e recursos de RDMA. Eventos de desempenho compatíveis com cgroups dão suporte à medição, e cgroup.freeze pausa a execução de um grupo.

Diferencie um limite de CPU de uma parcela

cpu.max contém uma cota e um período em microssegundos. 50000 100000 permite 50 ms de execução de CPU a cada 100 ms, o equivalente à metade de uma CPU. 200000 100000 permite o equivalente ao tempo de duas CPUs, potencialmente distribuído entre núcleos. max 100000 significa ausência de limite de cota. Quando a cota é consumida, o grupo aguarda o próximo período, mesmo que uma CPU esteja ociosa.

cpu.weight define uma parcela relativa durante a competição, de 1 a 10.000, com padrão 100. Para grupos igualmente posicionados e prontos para execução em quatro CPUs, os pesos 100 e 300 dividem o tempo disponível na proporção 1:3: aproximadamente uma CPU e três CPUs. Se o grupo de maior peso ficar ocioso, o outro poderá usar as quatro, a menos que outro limite interfira. Um peso não é uma reserva nem um teto rígido.

Contenha o esgotamento de memória e tarefas

memory.high aplica pressão para recuperar memória e desacelera tarefas acima de seu limiar. memory.max impõe uma fronteira rígida. O núcleo primeiro tenta recuperar memória, incluindo cache e usando a área de troca disponível. Se não conseguir recuperar o suficiente, o tratamento de falta de memória do cgroup encerra um processo elegível dentro do grupo afetado.

Para memory.max de 512M, o limite é de 536.870.912 bytes, ou 512 MiB. Um processo com vazamento pode forçar a recuperação de memória e acabar provocando um encerramento por falta de memória, mas a vítima é selecionada pelo núcleo e não há garantia de que seja esse processo. A fronteira do grupo contém o evento em vez de escolher um processo não relacionado do hospedeiro.

pids.max conta processos e threads. Com um limite de 100, novas criações falham com EAGAIN, contendo o crescimento de tarefas de uma bomba de fork. Um limite de entrada e saída como 8:0 rbps=10485760 em io.max limita as leituras do dispositivo de blocos 8:0 a 10 MiB/s.

Esses arquivos não escondem processos nem nomes de arquivos do hospedeiro. Além disso, /proc/meminfo e ferramentas que o leem podem informar a RAM do hospedeiro em vez de memory.max; o total exibido, por si só, não prova que um cgroup não tem limite. As medições de recursos devem ser lidas na camada que impõe a fronteira.

Uma fronteira útil de contêiner combina visões, controles de recursos e autoridade restrita. Uma árvore de arquivos privada, por si só, não impede chamadas de sistema perigosas, e uma cota de CPU não impede o acesso a um arquivo exposto do hospedeiro. O núcleo do hospedeiro aplica todos esses controles.

Reduza a autoridade do processo

Um ambiente de execução combina espaços de nomes, cgroups e uma imagem de sistema de arquivos que contém programas e bibliotecas. Ele pode fortalecer a fronteira ao:

• Executar a carga de trabalho como não root ou mapear IDs do contêiner por um espaço de nomes de usuários.
• Remover capacidades do Linux, especialmente poderes amplos como CAP_SYS_ADMIN e CAP_SYS_MODULE.
• Aplicar seccomp para restringir chamadas desnecessárias.
• Aplicar uma política SELinux ou AppArmor.
• Tornar o sistema de arquivos raiz somente para leitura quando viável.
• Definir no_new_privs para que a execução setuid não possa elevar privilégios.

Cada controle cobre um caminho diferente. Um sistema de arquivos raiz somente para leitura ainda permite operações de rede autorizadas; um filtro seccomp ainda permite as chamadas de sua lista. O projeto deve corresponder às operações de que a aplicação realmente precisa.

Identifique o risco do núcleo compartilhado

Todos os contêineres comuns compartilham o núcleo do hospedeiro. Um erro no núcleo que possa ser alcançado pode, portanto, comprometer o hospedeiro e outros contêineres. Em uma VM, explorar o núcleo convidado dá controle desse convidado; alcançar o hospedeiro exige uma falha adicional na fronteira do hipervisor ou de dispositivos.

Root dentro de um contêiner exige atenção especial. Sem um espaço de nomes de usuários, ele é UID 0 para o núcleo do hospedeiro, limitado por capacidades, filtros e política obrigatória. O modo privilegiado ou o acesso ao sistema de arquivos raiz do hospedeiro pode remover essas restrições. Um socket do ambiente de execução pertencente a root também é perigoso: seu cliente pode pedir ao ambiente que execute ações privilegiadas. Mapear root do contêiner para um ID sem privilégios no hospedeiro não torna esse socket seguro nem elimina vulnerabilidades do núcleo.

Escolha uma fronteira para a carga de trabalho

Um contêiner Linux precisa de um núcleo Linux. Por isso, plataformas no Windows e no macOS frequentemente fornecem uma VM Linux sob os contêineres Linux. VMs inicializam um sistema operacional e alocam memória para cada núcleo; contêineres iniciam processos comuns e podem acomodar cargas de trabalho com maior densidade.

Reconheça projetos intermediários

O gVisor trata muitas chamadas de sistema de contêineres em um núcleo em espaço de usuário, reduzindo o contato direto com o núcleo do hospedeiro. O Kata Containers dá a cada ambiente isolado, normalmente um pod do Kubernetes, uma VM leve; os contêineres nesse ambiente compartilham seu núcleo convidado. O Firecracker fornece micromáquinas virtuais com um modelo mínimo de dispositivos para plataformas que executam funções ou cargas de trabalho de contêineres, incluindo o AWS Lambda.

Sistemas de nuvem frequentemente colocam contêineres dentro de VMs: uma VM separa clientes enquanto contêineres organizam as aplicações de um cliente. Os núcleos convidados e o núcleo do hospedeiro permanecem distintos, então um escape de contêiner dentro de uma VM não prova, por si só, um escape do hipervisor.