Construir sistemas seguros

Uma aplicação de notas não deve dar à conta que consulta pautas o poder de mudar utilizadores. Se essa conta for roubada, os seus privilégios determinam o que o atacante consegue fazer. Os privilégios são as operações permitidas à conta. Limitá-los reduz as consequências do seu comprometimento. Para arranque verificado, esta página usa apenas a ideia de assinatura para verificar componentes e de resumo para medir software; os detalhes dessas primitivas estão em criptografia.

Princípios de construção

A conta de consulta só precisa de ler a sua pauta durante o semestre: privilégio mínimo pergunta se retiramos a escrita e o acesso depois do prazo; negar por defeito pergunta se um pedido novo é recusado sem regra explícita; mediação completa pergunta se existe algum caminho que contorna a verificação. Os princípios de Saltzer e Schroeder ajudam a avaliar um desenho:

Princípio	Pergunta a fazer
Privilégio mínimo	Cada entidade recebe só as permissões necessárias, pelo tempo necessário?
Negar por defeito	Um pedido só é permitido quando existe uma autorização explícita?
Mediação completa	Cada acesso passa pela verificação relevante?
Simplicidade do mecanismo	O mecanismo é pequeno e compreensível o suficiente para ser revisto?
Desenho aberto	A proteção depende de segredos como chaves, e não de esconder o algoritmo?
Separação de privilégios	Uma operação crítica exige condições independentes?
Mínimo mecanismo comum	Reduzimos recursos partilhados que criam dependências e fugas?
Aceitação psicológica	O caminho seguro é compreensível e utilizável?

Exigir aprovação de dois responsáveis para publicar uma pauta separa a autoridade de decisão. Pedir a mesma palavra-passe duas vezes à mesma pessoa não cria essa separação. Também não é autenticação multifator: essa distingue categorias de prova de identidade, e não responsáveis por uma decisão.

Isolamento limita a comunicação e os recursos acessíveis entre componentes. Um processo separado, uma sandbox ou uma máquina virtual oferece isolamento com hipóteses diferentes. Por exemplo, dois processos com o mesmo ficheiro temporário gravável por todos continuam a comunicar por esse ficheiro. Essa comunicação pode quebrar a separação pretendida.

Memória virtual e fronteira do kernel

Cada processo usa um espaço de endereços virtual. As tabelas de páginas traduzem endereços virtuais em páginas físicas e atribuem permissões. O endereço virtual 0x4000 em A não identifica necessariamente a mesma página física que 0x4000 em B. Partilha explícita de memória pode, contudo, mapear a mesma página nos dois processos.

A separação entre modo utilizador e modo kernel impede o código comum de aceder livremente a memória e operações privilegiadas. Uma chamada de sistema faz uma transição controlada. O kernel tem de validar os pedidos, incluindo ponteiros, tamanhos e autoridade. A transição não torna confiável o argumento recebido.

Em modelos históricos de x86, páginas do kernel podiam estar nas tabelas do processo com acesso reservado ao modo supervisor. Estarem mapeadas não as tornava legíveis pelo processo. Sistemas com KPTI usam tabelas distintas para reduzir certas exposições, incluindo riscos de execução especulativa. A disposição depende da arquitetura e da configuração; não assumes que todo kernel atual está mapeado da mesma forma.

Caso: mesmo endereço, outro objeto

A tem um buffer de 4 KiB em 0x4000; B usa o mesmo endereço virtual para outra alocação. Uma instrução de A que escreve em 0x4000 segue a tradução de A, não a de B, porque cada processo usa a sua tabela de páginas. Só uma partilha configurada, uma operação autorizada ou uma falha numa fronteira de proteção altera essa conclusão. A memória virtual isola traduções e permissões, não a intenção dos programas.

Variantes e limites deste caso

Se existir uma página explicitamente partilhada, ambos os números traduzem para a mesma página física. KPTI, execução especulativa e permissões de página mudam exposições concretas, mas não mudam a regra base: o número virtual só ganha significado através da tabela do processo.

Android: isolamento por aplicação

O Android atribui normalmente um UID a cada aplicação e usa processos e permissões Linux para separar os seus dados. A fronteira também se aplica a código nativo. Nesse modelo, o UID distingue aplicações, SELinux acrescenta controlo obrigatório sobre operações e filtros seccomp restringem que chamadas de sistema cada processo pode pedir.

Permissões pedidas no manifesto e consentimento do utilizador regulam capacidades específicas, mas não são toda a sandbox. Uma aplicação autorizada a usar a câmara não recebe automaticamente acesso aos ficheiros privados de outra. Partilhas explicitamente autorizadas e componentes expostos têm regras próprias. Vulnerabilidades do kernel ou uma configuração privilegiada podem comprometer a fronteira.

Containers, máquinas virtuais e seccomp

Um container Linux típico partilha o kernel do anfitrião. Namespaces separam vistas de recursos, por exemplo cada container vê os seus próprios processos. Cgroups contabilizam e limitam recursos, por exemplo memória e CPU. As Linux capabilities e políticas de acesso limitam autoridade, por exemplo retirar o poder de montar sistemas de ficheiros. Uma máquina virtual tem o seu próprio kernel convidado e comunica com hardware virtual através do hipervisor. Ambas dependem de componentes privilegiados e de configuração correta.

Um hipervisor de tipo 1 executa diretamente sobre o hardware; um de tipo 2 depende de um sistema anfitrião. Esta classificação descreve a organização, não garante ausência de vulnerabilidades ou canais laterais. O isolamento de uma VM continua a depender do hipervisor e dos dispositivos expostos.

Seccomp-BPF permite decidir sobre chamadas de sistema usando o número, arquitetura e argumentos disponíveis ao filtro. Pode devolver erro, terminar o processo ou aplicar outras ações previstas. Não interpreta livremente o conteúdo dos ponteiros fornecidos: uma regra sobre o número da chamada não verifica o texto de um caminho.

Por exemplo, um conversor que não precisa de criar processos pode ter uma política que bloqueia essa chamada. Se uma vulnerabilidade tentar usá-la, o filtro limita esse caminho. Ainda são necessários limites de ficheiros, memória, rede e acesso, porque seccomp reduz superfície exposta do kernel e sozinho não é uma sandbox completa. Um container privilegiado, um volume sensível montado ou acesso ao controlo do runtime pode anular a separação pretendida.

Interposição e isolamento por software

System Call Interposition, ou SCI, medeia chamadas de sistema para observar ou limitar operações. O filtro seccomp é um exemplo. A decisão de negar uma chamada pode limitar efeitos de código comprometido, mas não verifica automaticamente todas as leituras e escritas que esse código faz dentro da sua memória.

Software Fault Isolation, ou SFI, restringe código de um domínio, por exemplo instrumentando acessos e desvios para os manter na região permitida. Atua na execução do código, em vez de depender apenas de filtrar chamadas ao kernel. SCI e SFI podem complementar-se: manter um acesso em determinada região não autoriza abrir qualquer ficheiro, e negar uma chamada não torna válido um acesso fora dos limites de um buffer.

Arranque verificado, medições e TPM

Secure Boot verifica assinaturas de componentes de arranque segundo uma política de confiança, podendo recusar um componente não autorizado. Measured Boot regista medições criptográficas do que arrancou. Um TPM pode proteger chaves e acumular essas medições em registos PCR. Medir não é automaticamente bloquear.

Numa atestação, segue a decisão de um servidor que só aceita determinadas medições:

Passo	Estado ou decisão
Medir	O arranque acumula medições nos PCR do TPM.
Proteger a chave	A chave de atestação fica sujeita à proteção e à política do TPM.
Pedir uma prova	O servidor envia um desafio novo; a resposta autenticada liga as medições a esse desafio.
Decidir	O servidor valida a prova e compara as medições com os estados aceites.

Reutilizar uma resposta antiga não satisfaz o desafio novo. Registar uma medição, por si, também não aplica a política de acesso do servidor. Uma medição diferente pode levar o verificador a negar acesso; uma medição esperada não prova que o sistema nunca será comprometido depois do arranque. A decisão depende da cadeia medida, da confiança nas chaves e da política de aceitação.

Uma chave selada a determinada política de PCR pode ficar indisponível se o arranque mudar. Uma atualização legítima também pode mudar as medições, pelo que o desenho precisa de atualização e recuperação. TPM não é um antivírus nem uma garantia de que qualquer programa assinado é seguro.

Defesa em profundidade

A defesa em profundidade combina controlos com falhas diferentes. Na aplicação, o controlo de acessos restringe a consulta; a cifragem protege uma cópia de disco; as cópias de segurança permitem recuperar uma eliminação. Não são passos obrigatórios de uma única sequência de ataque.

Duas verificações que usam a mesma condição errada não são duas defesas independentes. Da mesma forma, guardar a chave de cifragem junto dos dados, com as mesmas permissões, pode deixar ambos expostos ao mesmo roubo.

Monitor de referência e TCB

Um monitor de referência é o modelo de um mecanismo que decide acessos entre sujeitos e objetos. Tem de mediar os acessos relevantes, resistir a alterações não autorizadas e ser suficientemente simples para permitir análise. O código e componentes de que a proteção depende formam a base de computação confiável, ou TCB.

Suponhamos que a interface esconde o botão “Alterar nota”, mas o servidor aceita POST /notas/42 de qualquer conta. O botão não é um monitor eficaz, porque o atacante envia o pedido diretamente. A verificação pertence ao servidor, junto da operação protegida.

O representante confuso

Um serviço de impressão pode ler ficheiros privados porque precisa de acesso técnico. Segue o pedido: o utilizador indica um caminho que não pode ler; o serviço abre esse caminho com a sua autoridade alargada; o serviço devolve o conteúdo ao utilizador. O serviço confundiu duas autoridades. É o problema do confused deputy, um representante privilegiado que confunde a sua autoridade com a de quem fez o pedido.

O serviço deve verificar a autoridade do requerente sobre o objeto antes de abrir, ou receber uma capacidade limitada ao ficheiro autorizado e usar apenas essa referência. Ter autenticado o utilizador não autoriza todos os seus pedidos.

Falhar de forma segura

Se o servidor de autorização não responde, permitir todos os acessos é uma falha aberta. Negar os acessos protegidos preserva a política de autorização, mas pode reduzir a disponibilidade. O desenho tem de explicitar a propriedade prioritária e uma recuperação segura, em vez de assumir que existe uma resposta universal para qualquer serviço.

Numa resposta de teste, identifica a fronteira de confiança, o componente que decide e a condição verificada. Depois segue um pedido que tenta contornar essa decisão. Para seguir um caso de autoridade que sobrevive à mudança de UID, continua em Set-UID e descritores.