Saltar para o conteúdo 
Seccomp Linux limita as aplicações exatamente às chamadas de sistema de que realmente necessitam, reduzindo assim significativamente a superfície de ataque do kernel. Utilizo este mecanismo de forma específica para colocar contentores, microsserviços e serviços sensíveis numa Sandbox bloquear, sem impedir o funcionamento das suas funções essenciais.
Pontos centrais
Resumo os aspetos mais importantes para uma visão geral rápida e destaco a forma como utilizo o Seccomp na prática. Isto proporciona uma introdução clara às políticas, aos filtros e à proteção da carga de trabalho. Estes pontos servem-me de fio condutor para o planeamento, a operação e a verificação. Ajudam a priorizar riscos e a escolher predefinições adequadas. Tendo estes pontos-chave em mente, a Segurança compreensível e controlável.
- Modo de filtragem: Os perfis BPF de granularidade fina permitem apenas as chamadas de sistema necessárias.
- Superfície de ataque: A redução do número de caminhos de acesso ao kernel diminui o risco de exploração.
- Contentor: Os perfis predefinidos bloqueiam de forma fiável as chamadas de risco.
- Kubernetes: O seccompProfile e o seccompDefault uniformizam a proteção.
- Fluxo de trabalho: Analisar, definir o perfil, endurecer, testar, implementar.
Analiso cada carga de trabalho, defino um perfil adequado e verifico o seu impacto em funcionamento. É assim que se desenvolve um sistema robusto Linha de base-Proteção que poderá ser posteriormente alargada de forma específica.
Seccomp em poucas palavras: Modo de Computação Segura
Seccomp significa „Secure Computing Mode“ e limita Chamadas ao sistema de um processo a um conjunto claramente definido. Aplico o filtro nos pontos em que as aplicações interagem com o kernel, por exemplo, ao abrir ficheiros, sockets ou ao criar outros processos. A ideia é simples: permitir o que é necessário e impedir o que não é permitido através de um código de erro ou de um comando «kill». Quem compreende a interação com o kernel consegue criar rapidamente perfis sólidos; um bom ponto de partida é o artigo Compreender as chamadas de sistema. É assim que se cria uma eficaz Sandbox, o que dificulta as fugas e bloqueia percursos indesejados do kernel.
Por que é que o Seccomp Linux reduz a superfície de ataque
Cada chamada adicional ao sistema aumenta potencialmente a Superfície de ataque. Reduzo essa área ao autorizar apenas as chamadas de sistema que a aplicação utiliza comprovadamente. Desta forma, muitas cadeias de exploração perdem o acesso a funções críticas do kernel. Mesmo quando o código é executado no processo, um atacante depara-se frequentemente com portas fechadas. É assim que impeço o acesso a subsistemas sensíveis, tais como ptrace, BPF ou determinadas interfaces de depuração.
Lista de autorizações em vez de lista de bloqueios: a estratégia certa
Em ambientes produtivos, aposto em Lista de permissões: A ação padrão é „proibir“, e apenas é permitido um conjunto de chamadas ao sistema cuidadosamente selecionado. Muitos ambientes de execução fornecem, por motivos de compatibilidade, perfis de listas de bloqueio que bloqueiam apenas as chamadas particularmente arriscadas. Para serviços sensíveis, aperto o cerco e permito apenas o que a análise de tempo de execução realmente revela. Isto reduz as surpresas em caso de alterações no kernel e desloca o controlo de „O que é perigoso?“ para „O que é necessário?“. Para cargas de trabalho genéricas, uma lista de bloqueio sólida pode ser um bom ponto de partida, mas no caso de gateways, fluxos de pagamento ou serviços de autenticação, vale a pena dar o salto para uma política de lista de permissão com exceções explícitas.
Modos e lógica de filtragem: estrita até BPF
O Seccomp dispõe de um modo rigoroso, que permite apenas as operações «read», «write», «exit» e «sigreturn», e do modo altamente flexível Modo de filtragem através do BPF. Na prática, utilizo quase sempre filtros, uma vez que isso me permite analisar detalhadamente as chamadas de sistema e os seus argumentos. O kernel verifica cada chamada em relação ao programa definido e decide se a permite, se devolve um erro ou se encerra o processo. Assim, posso bloquear variantes específicas de uma chamada de sistema, como, por exemplo, flags específicas do `clone` ou do `unshare`. Esta granularidade permite Políticas simples e eficaz ao mesmo tempo.
Campanhas de devolução e nível de controlo
Controlo o comportamento em caso de infrações de forma específica através de ações: permitir, erros definidos (na maioria das vezes EPERM ou EACCES) devolver, por meio de TRAP disparar um sinal, com TRACE Habilitar a depuração ou encerrar o processo/thread de forma consistente. Muitas vezes, basta apenas devolver um erro, o que melhora a tolerância a erros; no entanto, para percursos particularmente delicados, recorro a ações de encerramento forçado. Quando necessito de diagnóstico, recorro ao registo do kernel ou a ações com registo para restringir gradualmente o perfil em ambientes de teste, sem perturbar desnecessariamente o funcionamento.
Sandboxing e proteção por contentores na prática
Os ambientes de execução de contentores oferecem soluções comprovadas Predefinição-Perfis que bloqueiam chamadas de sistema arriscadas. Parto dessa base e restrinjo ainda mais as funções mount, unshare, bpf, ptrace, bem como keyctl e perf_event_open. As aplicações que processam entradas não confiáveis beneficiam-se duplamente: menos interface com o kernel e um cenário de erros mais claro em caso de violações. Até mesmo os navegadores da Web e as ferramentas de sandbox baseiam-se nesta separação entre o acesso necessário e o acesso perigoso. Desta forma, o sistema de tempo de execução permanece mais fácil de gerir e previsível.
Notificação no espaço do utilizador: exceções controladas
Para exceções raras, mas legítimas, utilizo o Notificador do Espaço do Utilizador-Abordagem: Um processo de monitorização recebe pedidos relativos a chamadas de sistema bloqueadas e pode aprová-los ou rejeitá-los de forma seletiva. Desta forma, reproduzo padrões de broker, por exemplo, para permitir apenas determinadas montar- Permitir operações em diretórios definidos. Isto reduz a necessidade de incluir exceções gerais na política e, ainda assim, mantém a flexibilidade das operações. O importante aqui é uma governação clara: que comandos são permitidos, como são auditados e como posso evitar que o próprio notificador se torne um ponto único de falha?
Seccomp no Kubernetes e no OpenShift
No Kubernetes, defino no manifesto do pod, através do SecurityContext, qual o perfil que está ativo. O seccompDefault no nó garante que as cargas de trabalho que não tenham uma especificação própria recebam diretamente um Padrão-Perfil recebido. O OpenShift e o Podman também integram esta funcionalidade, incluindo a transferência através da opção –security-opt. Posso disponibilizar os perfis de forma centralizada e aplicá-los através de anotações ou ligações de campos. Desta forma, estabeleço regras claras em todos os Namespaces fora.
Conceção de políticas para equipas e plataformas
Estruturo os perfis de acordo com Classes de carga de trabalho em vez de por equipas: front-ends web, workers, clientes de bases de dados, pipelines de dados. Cada classe recebe um perfil testado, ao qual apenas acrescento o mínimo necessário para casos especiais. No Kubernetes, utilizo uma política de admissão para garantir que os pods tenham, no mínimo, RuntimeDefault utilizar, enquanto os namespaces particularmente sensíveis exigem uma Localhost-Forçar o perfil. Para situações de depuração ou incidentes, existe um procedimento de exceção bem definido, com prazo de validade limitado e restrições adicionais à rede e às capacidades, para que o diagnóstico continue a ser possível sem reduzir o nível de segurança de forma geral.
Criação de perfis: fluxo de trabalho, desde a análise até à implementação
Começo por fazer uma análise do tempo de execução e observo quais Chamadas ao sistema que a aplicação utiliza em funcionamento normal. Em seguida, elaboro um perfil inicial que permite exatamente essas chamadas e exclui percursos pouco frequentes. Depois, aprofundo ainda mais o perfil, eliminando ou restringindo chamadas pouco frequentes ou de risco. Uma fase de teste identifica lacunas e revela se faltam funcionalidades ou se os códigos de erro são adequados. Só depois é que implemento a Política na produção e atribuo uma versão a cada alteração.
Aspectos arquitetónicos e relacionados com o ABI
As chamadas de sistema variam consoante a arquitetura e a geração do kernel. Tenho o cuidado de garantir que os perfis Multi-Arch abrangem de forma exaustiva (por exemplo, x86_64 e arm64) e que as variantes mais recentes, como openat2 ou se as chamadas de sistema time64 são tidas em conta. Em contentores com sistemas base mais antigos, verifico se existem caminhos legados (por exemplo, através de socketcall ou determinadas chamadas IPC). Quem libseccomp ou que utilize o Runtime para a geração, beneficia de mapeamentos estáveis entre nomes de símbolos e números de chamadas de sistema – evito deliberadamente utilizar números fixos, para garantir a portabilidade. Importante: os filtros são hereditário e apenas monótono passível de agravamento; o que já foi proibido permanece proibido, mesmo após execve.
Gestão de atualizações e compatibilidade
As atualizações das bibliotecas e do kernel introduzem novas chamadas de sistema ou alteram os padrões de chamada. Por isso, pretendo realizar Ensaios de fumo após as atualizações e mantenho um ambiente de teste disponível que, em caso de dúvida, pode ser utilizado com LOG-ações. Assim, consigo ver quais são os novos pedidos antes de bloquear a produção. Além disso, documento deliberadamente as diferenças entre as imagens (por exemplo, contentores baseados em musl vs. glibc), uma vez que estas podem utilizar diferentes caminhos para aceder à API do kernel. Para os rollbacks, é fundamental que haja uma versão clara dos perfis; em caso de incidente, mudo temporariamente para uma política menos rigorosa, com um prazo de validade curto e uma monitorização rigorosa.
Identificar padrões de erros: registo e triagem
As chamadas de sistema bloqueadas têm de ser localizáveis; caso contrário, ficamos às cegas no Escuro. Ativo o registo no tempo de execução e analiso métricas que revelam picos e valores atípicos. As mensagens com EPERM ou EACCES indicam frequentemente regras demasiado restritas. Atribuo os encerramentos inesperados ao componente afetado e verifico os sinalizadores ou argumentos correspondentes. Em seguida, ajusto a Filtros Defina o valor mínimo e volte a testar.
Manual de resolução de problemas
- Reproduzir: repetir exatamente o mesmo input/tráfego e correlacionar os registos.
- Identificar: registar a chamada de sistema em questão com os respetivos argumentos (por exemplo, através do registo de execução ou da saída de auditoria).
- Taxa: Será que é necessário utilizar esta função? Existe alguma alternativa menos arriscada (por exemplo, «openat» em vez de «open», ou opções mais específicas)?
- Personalizar: permitir o mínimo, idealmente com filtros de argumentos; manter a ação padrão como «estrita».
- Proteger: para exceções delicadas, reforçar adicionalmente a redução de capacidades, o sistema de ficheiros só de leitura ou os namespaces.
- Novos testes e telemetria: após a correção, realizar testes específicos, monitorizar as métricas e configurar alertas.
Comparação com o SELinux, o AppArmor e as capacidades
O Seccomp atua na interface entre a aplicação e o kernel, enquanto o SELinux e o AppArmor regulam principalmente o acesso a objetos. As capacidades controlam as operações privilegiadas, que eu também reduzo significativamente. Juntamente com Espaços de nomes e cgroups Surge assim um conceito de proteção em várias camadas. Separo os recursos, elimino privilégios desnecessários e limito os caminhos do kernel através de Seccomp. Esta combinação mantém as cargas de trabalho bem controladas e fáceis de gerir.
Desempenho e sobrecarga
Um perfil Seccomp bem definido causa apenas um impacto mínimo Despesas gerais: O kernel verifica um pequeno programa BPF por cada chamada ao sistema. Na prática, isto é praticamente impercetível em cargas de trabalho habituais da Web e de serviços. Podem tornar-se críticos os percursos de alta frequência e com uso intensivo de chamadas ao sistema (por exemplo, processamento de pacotes, processos com uso intensivo de IPC). Por isso, mantenho o número de regras reduzido, utilizo filtros de argumentos em vez de longas listas e testo os caminhos mais frequentes com benchmarks. Se um perfil causar um abrandamento mensurável, verifico primeiro se existem duplicados, correspondências imprecisas e se determinadas chamadas raras podem ser transferidas para um processo separado.
Boas práticas para predefinições seguras
Começo com o perfil predefinido do Runtime e vou ajustando-o consoante Carga de trabalho. Os serviços de elevada sensibilidade, como gateways ou serviços de autenticação, estão sujeitos a regras particularmente rigorosas. Integro as alterações aos perfis no CI/CD e testo-as automaticamente. Além disso, recomendo uma forte redução de capacidades, sistemas de ficheiros de leitura única e a política «NoNewPrivs». Pode encontrar um guia sobre mecanismos abrangentes de proteção de anfitriões em Reforço do kernel, que se complementa bem com o Seccomp.
Endurecimento avançado: o que verifico adicionalmente
Para além dos suspeitos do costume (montar, despartilhar, bpf, ptrace, keyctl, perf_event_open) analiso os seguintes pedidos e, consoante o contexto, restrinjo-os significativamente ou bloqueio-os por completo:
- setns: impede a passagem para outros espaços de nomes.
- process_vm_readv/process_vm_writev: impede o acesso direto à memória de outros processos.
- kexec_load e reiniciar: proteger contra tentativas de reinício ou substituição do kernel.
- swapon/swapoff e init_module/finit_module: limitam os mecanismos de carregamento do sistema e dos módulos.
- clone3 com opções de risco (por exemplo, namespaces): restringir de forma granular através de argumentos.
- io_uring_setup: consoante a carga de trabalho, permitir ou restringir rigorosamente, uma vez que se trata de uma interface poderosa.
A orientação a seguir é: tanto quanto for necessário, o mínimo possível – e é preferível uma exceção pequena e documentada do que uma regra padrão demasiado aberta.
Integração no CI/CD e no Teams
Trato os perfis Seccomp como Código: criar versões, rever, testar. As tarefas do pipeline verificam se os perfis correspondem à imagem e se ocorrem bloqueios. Os testes de fumaça com dados de teste detetam alterações de comportamento mais rapidamente do que os cliques manuais. Os programadores recebem um pequeno manual que explica como funciona o registo de logs e onde podem ajustar as assinaturas. Assim, o Segurança diretamente no fluxo de desenvolvimento e mantém-se atualizado.
Brevemente resumido
O Seccomp limita a Chamadas ao sistema limitar uma aplicação ao estritamente necessário, eliminando assim muitas vias de ataque. Começo com uma configuração padrão robusta, avalio o comportamento real e, em seguida, vou restringindo passo a passo. As plataformas de contentores, como o Kubernetes ou o OpenShift, poupam-me muito trabalho de base quando defino o seccompDefault e distribuo os perfis de forma centralizada. Em combinação com Capabilities, SELinux/AppArmor, bem como Namespaces e Cgroups, cria-se uma proteção múltipla eficaz. Quem seguir esta abordagem de forma consistente reduz o risco de explorações do kernel e, ao mesmo tempo, mantém as cargas de trabalho bem controlável.
