Aplicando Landlock no Linux

 (blog.prizrak.me)
1 pontos por GN⁺ 2025-12-01 | 1 comentários | Compartilhar no WhatsApp
  • Landlock é uma API de segurança do Linux que permite que aplicações declarem explicitamente os recursos que podem acessar, para executar sandboxing próprio no nível do kernel
  • É mais simples que o SELinux ou o AppArmor, e permite criar e aplicar políticas em runtime sem privilégios de administrador
  • As políticas são definidas como uma allowlist (lista de permissões) explícita para arquivos, diretórios e portas acessíveis, e permitem aprimoramento de segurança gradual por meio de restrições hierárquicas
  • Há bindings para Rust, Go, Haskell e outros, tornando possível implementar controle de acesso refinado em diferentes ambientes, como aplicativos GUI, servidores e processos de desktop
  • No ecossistema de segurança do Linux, ele é visto como uma ferramenta prática e simples de sandbox sem privilégios e está recebendo destaque como um componente central para reforçar a segurança de desktops no futuro

Visão geral do Landlock

  • O Landlock é uma API que permite que aplicações Linux declarem explicitamente quais recursos podem acessar
    • É semelhante aos conceitos unveil() e pledge() do OpenBSD e segue o princípio de “permitir apenas os recursos necessários e bloquear o restante”
  • Fornece uma camada de defesa fácil de entender e integrar, com foco no desenvolvedor, mais simples do que os mecanismos tradicionais de segurança do Linux
  • O objetivo é tornar os acessos explícitos e incentivar o uso do Landlock

Funcionamento

  • Funciona como um Linux Security Module (LSM) e está disponível a partir do Linux 5.13
  • Ao contrário do SELinux e do AppArmor, aplica uma restrição transitória por processo
    • As políticas são geradas em runtime e aplicadas apenas à thread atual e a processos filhos, desaparecendo quando o processo é encerrado
  • Componentes da política
    1. Handled accesses: categorias de operações a serem limitadas (por exemplo, leitura/gravação do sistema de arquivos)
    2. Access grants: lista explícita de objetos permitidos
  • Exemplo de política
    • /home/user: somente leitura
    • /tmp: leitura/gravação
    • permitir bind na porta 2222
  • Ao chamar landlock_restrict_self(), a thread atual e seus filhos entram em uma área de restrição permanente
    • A restrição é irrevogável e até 16 camadas podem ser empilhadas
    • Camadas inferiores podem reduzir ainda mais o acesso, mas permissões removidas em camadas superiores não podem ser restauradas
  • Funciona de forma não privilegiada (unprivileged), permitindo que aplicativos comuns façam seu próprio sandboxing
  • O versionamento de ABI permite que funcione dentro do suporte do kernel mais antigo
  • Por ser um Stackable LSM, pode ser usado junto com SELinux ou AppArmor

Motivos para usar

  • Adequado para aplicações com padrão de acesso a arquivos previsível
    • Ex.: limitar um servidor web para acessar apenas /var/www/html e /tmp
  • Não requer intervenção de administrador ou configuração global do sistema; a política pode ser definida diretamente no código
  • Pode ser usado sem elevação de privilégios e integrado com facilidade à maioria dos programas
  • Há bindings para Rust, Go e Haskell; também existem vários projetos de wrapper no estilo unveil
  • Ainda não há biblioteca C oficial, mas várias implementações não oficiais podem ser usadas
  • Em exemplo de código em Rust, /usr, /etc e /dev são definidos como somente leitura, enquanto /home e /tmp ficam com leitura/gravação

Estado e necessidade do sandboxing no Linux

  • Com o aumento do uso do Linux, também aumentam os malwares voltados para desktops
  • A segurança relativa do Linux não decorre de segurança estrutural, mas da participação de mercado e das barreiras técnicas existentes
  • Pontos problemáticos de distribuições comuns
    • É possível executar binários não confiáveis
    • É possível executar scripts diretamente da internet
    • Uso de sudo sem senha
    • Aplicativos comuns podem acessar arquivos sensíveis dentro de $HOME
    • Em ambiente X11, a digitação de teclas pode ser monitorada
    • Fazendo bind de portas arbitrárias

Limitações das ferramentas de segurança existentes

  • Containerização (Docker, Podman): adequada para isolamento de serviços, mas não para apps de desktop; casos de isolamento anulado com a opção --privileged também existem
  • Flatpak / Snap: adequados para apps GUI, mas com escopo de permissões excessivo; inadequados para ferramentas CLI
  • Firejail: exige perfil por aplicação e chamada explícita em cada execução

Mecanismos existentes sob o ponto de vista do desenvolvedor

  • seccomp: poderoso, mas a configuração é complexa e o modelo de blacklist é frágil
  • SELinux: poderoso, mas complexo, exige política de administrador e muitos projetos o deixam desativado por padrão
  • AppArmor: mais simples que o SELinux, mas ainda exige perfil de administrador e é desativado em algumas distribuições

Resumo das vantagens do Landlock

  • Sem privilégios, centrado na aplicação, fácil de integrar, negação padrão (deny-by-default)
  • Suporte amplo após o Linux 5.13, com compatibilidade para versões anteriores e futuras
  • Não é perfeito, mas funciona como uma ferramenta independente, simples e sem privilégios para preencher uma lacuna

Aplicabilidade do Landlock

  • Em processos daemon de alto privilégio em execução prolongada, o Landlock pode limitar a área de acesso
  • Leitores de PDF, visualizadores de imagem, navegadores web e processadores de texto podem ser restringidos a acessar apenas arquivos abertos
  • Servidores FTP/HTTP podem ser configurados para acessar apenas arquivos necessários
    • Ex.: mesmo que o nginx esteja rodando como root, se um invasor obtiver shell, não conseguirá acessar arquivos fora da política
  • Com a adoção da proposta de Supervisor, pode-se implementar no desktop Linux um sistema de permissões similar ao Android
    • Ao combinar com GUI e sistema de armazenamento de permissões, torna-se possível uma experiência de usuário mais segura

Recursos em desenvolvimento no Landlock

  • Supervise Mode: decide de forma interativa no espaço do usuário se o acesso é permitido ou negado, semelhante a prompts de permissão estilo Android
  • Socket Restrictions: controle refinado dos tipos de socket e portas que um processo pode usar
  • LANDLOCK_RESTRICT_SELF_TSYNC: propaga a restrição para todas as threads de um processo
  • LANDLOCK_ADD_RULE_QUIET: suprime mensagens de log de auditoria para objetos específicos
  • LANDLOCK_ADD_RULE_NO_INHERIT: impede que permissões de diretórios superiores sejam herdadas por níveis inferiores, refinando o controle do sistema de arquivos

Resumo

  • Landlock é um mecanismo de sandbox simples e sem privilégios com política de negação padrão
  • É fácil de entender e integrar e tem grande potencial para melhorar a segurança em desktops e aplicações Linux
  • Desenvolvedores podem aplicar diretamente o Landlock em suas aplicações para elevar o nível de segurança.

Leituras relacionadas

1 comentários

 
GN⁺ 2025-12-01
Opiniões no Hacker News
  • Eu usei o Landlock para bloquear telemetria indesejada
    Escrevi um programa simples em C para permitir escuta em apenas uma porta específica e bloquear todas as outras conexões de rede
    Usei como referência o sandboxer.c de exemplo e controlei apenas a rede, sem mexer nas restrições de acesso a arquivos
    As conexões bloqueadas aparecem no dmesg, provavelmente por causa do recurso de audit
    Essa ferramenta funciona em modo de usuário sem privilégios e também funciona bem dentro de contêineres sem configuração de firewall
    Ainda assim, não acho que seja adequada para bloquear completamente programas maliciosos
    • Fiquei curioso se você poderia compartilhar o código-fonte
  • O Landlock não é perfeito
    Pelas issue #28 e thread de e-mails relacionada, existe o problema de que regras de sandbox não podem referenciar diretórios que não existem
    Por exemplo, se você adicionar uma regra quando ~/.ssh ainda não existe, o acesso não será bloqueado mesmo que o diretório seja criado depois
    Ou seja, isso pode gerar uma brecha de segurança
  • Estou tentando fazer sandbox de jogos do itch.io com bwrap
    Executar tudo com o mínimo de privilégios é bem complicado
    “Microlandia” não funciona, mas outros jogos em Unity rodam bem
    Espero que surjam mais ferramentas baseadas em Landlock para facilitar esse tipo de tarefa
  • Tenho curiosidade sobre o estado do suporte ao Landlock em runtimes de contêiner
    Parece que os CRIs querem definir sua própria interface, mas inevitavelmente sempre ficam atrás do suporte do kernel
    Não acho que a maioria das pessoas de infraestrutura vá manter políticas de sandbox por aplicativo
    Acho mais realista que os próprios aplicativos usem Landlock
    • Mencionando a issue do runc e a issue da runtime-spec,
      explicam que, se o runtime simplesmente repassar a syscall, surge o problema de ter que confiar que o app vai se bloquear sozinho
    • Acho que o Landlock não foi pensado originalmente para runtimes de contêiner, mas para outro tipo de uso
  • Como desenvolvedor de dispositivos médicos, fico muito contente com essa abordagem
    Internamente, usamos uma API parecida para fazer gestão de processos críticos
    Esse tipo de pesquisa deve ajudar bastante também em setores regulados
  • Achei estranho dizerem que “não existe biblioteca C oficial”
    Se é uma funcionalidade do kernel, eu esperaria justamente uma API em C primeiro, então fico me perguntando por que ela não existe
    • A interface básica do kernel é a syscall (uapi)
      A libc é só uma camada por cima disso, e ainda hoje há muitas syscalls sem wrapper na libc
    • Aqui estão falando de biblioteca C padrão como glibc ou musl
      Você também pode criar os headers por conta própria e chamar via macro _syscallN
    • Não ter uma API C não é um grande problema
      Dá para usar wrappers simples como o landbox,
      e Rust ou Go também podem expor C FFI
      Consultar o exemplo sandboxer.c do kernel já é suficiente
    • A documentação no man7 resume a maior parte do conteúdo
    • Desenvolvedores do kernel não criam diretamente software de userland, por isso não existe uma API C
  • Vale notar que o Landlock restringe apenas sockets TCP, e não bloqueia UDP nem sockets raw
    • Isso parece uma brecha de segurança bem grande. Fico curioso sobre o motivo
    • Sockets raw exigem privilégios, e dá para fazer bloqueio por UID com iptables
      Não é a mesma coisa que Landlock, mas pode ser usado de forma complementar
    • Ainda assim, parece um buraco considerável
    • É uma limitação estranha, mas bom saber disso
  • É interessante que o Landlock tenha adicionado uma nova syscall em vez de usar configuração em /sys
    Provavelmente isso acontece por causa do princípio do não privilégio
    Também fico curioso se dá para bloquear a syscall do Landlock com seccomp
    Se uma política antiga de seccomp não incluir o número do Landlock, isso não poderia gerar um SIGSYS?
    • Outros LSMs também estão migrando aos poucos para uma base em syscalls
      APIs baseadas em sistema de arquivos têm muitos footguns, e para controle de acesso baseado em dirfd a syscall é mais adequada
      Filtros seccomp bem escritos retornam -ENOSYS, de forma que isso simplesmente pareça “não suportado”
    • Dá para restringir syscalls do Landlock com seccomp, mas a utilidade prática é baixa
      Isso porque o Landlock só restringe ainda mais permissões já existentes, em vez de conceder novas permissões
  • Estou começando agora a me interessar por segurança no Linux
    Estou me preparando para sair do Mac e migrar totalmente para Linux, e queria entender como o Landlock ajuda na defesa contra malware
    Por exemplo, eu gostaria de criar um ambiente que negasse automaticamente acesso a ~/.ssh
    Também queria saber se isso pode ser usado para criar um launcher de aplicativos
    • O modelo de ameaça do Landlock não é o malware em si, mas sim vulnerabilidades de execução de código em aplicativos legítimos
      A ideia é que o próprio app limite permissões desnecessárias para que um invasor não consiga tomar conta do sistema
    • Para bloquear acesso a algo como ~/.ssh, você precisa de um modelo MAC como AppArmor ou SELinux
      O Landlock é útil quando o próprio app, ou seus processos-filho, se restringem
      Por exemplo, quando o npm limita scripts de pós-instalação apenas ao diretório de build
      É uma API usada diretamente por desenvolvedores de aplicativos, como o pledge do OpenBSD
      Mas, como o ecossistema Linux é fragmentado, a adoção deve ser lenta
      Enquanto isso, o mais realista é usar em forma de wrapper ou launcher
    • O gerenciador de pacotes teria que definir políticas para scripts de build, ou o usuário teria que usar wrappers manualmente
      No fim, isso só funciona bem quando o programa conhece suas próprias permissões
    • É praticamente o mesmo conceito de sandboxing no macOS e no iOS
      O aplicativo define em whitelist, no início da execução, apenas os recursos de que precisa e bloqueia o restante
      Não é para defesa contra programas maliciosos, mas para proteger o próprio processo
  • Achei engraçado esse papo de “não existe biblioteca C oficial”
    Já existe syscall na biblioteca padrão; será que realmente faz sentido precisar de uma biblioteca separada?
    A documentação do man7 também existe
    Fico na dúvida se o que querem é apenas uma camada de abstração
    • A libc cuida de detalhes como gerenciamento de números de syscall e efeitos colaterais,
      então é surpreendente que a glibc ainda não ofereça a interface do Landlock
      Provavelmente isso tem relação com questões de compatibilidade fora do Linux