Mudança na forma de distribuição do código-fonte do RHEL pela Red Hat
- Em junho de 2023, a Red Hat tomou a controversa decisão de mudar a forma de distribuição do código-fonte por trás do Red Hat Enterprise Linux (RHEL)
- Essa decisão levantou muitas dúvidas sobre a viabilidade futura dos rebuilds downstream do RHEL, como Rocky Linux, AlmaLinux e Oracle Linux
- Depois disso, cada distribuição fez anúncios para acalmar a comunidade
- Em muitas comunidades de código aberto, a decisão da Red Hat foi interpretada como a influência de uma empresa gananciosa
- As pessoas dizem que estão migrando para o Debian, ou que já migraram, em busca de refúgio
A importância e a dificuldade da segurança
- Segurança é difícil, entediante, desagradável, e exige muito esforço para ser feita corretamente
- O Debian não faz esforço suficiente para proteger seus usuários
A adoção do SELinux pela Red Hat e o fornecimento de políticas padrão
- A Red Hat adotou o uso do SELinux há muito tempo e foi além de simplesmente ativar o recurso no kernel
- Ela fez o trabalho pesado de criar políticas SELinux padrão para a distribuição
- Essas políticas são fornecidas ativadas por padrão no RHEL e ajudam a proteger os daemons e servidores mais usados entre os vários daemons e servidores executados por padrão no RHEL
- Apache, nginx, MariaDB, PostgreSQL, OpenSSH e outros são protegidos pelas políticas SELinux fornecidas na distribuição RHEL
Aplicação de políticas SELinux a contêineres
- A proteção se estende até os contêineres
- Os contêineres estão se tornando cada vez mais a forma preferida pelos desenvolvedores para distribuir software
- É um equívoco achar que executar algo em um contêiner é inerentemente seguro
- O contêiner em si não resolve problemas de segurança; ele resolve problemas de distribuição de software
- Em distribuições baseadas na Red Hat, é possível usar o podman, uma alternativa ao Docker que oferece a vantagem de executar contêineres sem daemon e de forma totalmente rootless
- A Red Hat vai além e aplica políticas SELinux padrão robustas que isolam os contêineres do sistema operacional hospedeiro e de outros contêineres
- Aplicar políticas SELinux a contêineres fornece uma proteção reforçada que ajuda a mitigar o risco de vulnerabilidades futuras ainda desconhecidas
O esforço da Red Hat para fornecer políticas SELinux padrão
- A Red Hat sabia que, se não fizesse esse trabalho nessas políticas padrão, os usuários não adotariam a tecnologia e milhões de servidores permaneceriam vulneráveis
- O SELinux é difícil, e sua linguagem de políticas e suas ferramentas são complexas, obscuras e tão atraentes quanto preencher uma declaração de imposto
- No entanto, graças ao trabalho feito pela Red Hat, o uso do SELinux no RHEL é em grande parte transparente e oferece benefícios reais de segurança aos usuários
A abordagem do Debian com AppArmor
- O Debian é um pilar da comunidade de código aberto, conhecido por sua estabilidade e por sua ampla biblioteca de software
- No entanto, sua estrutura de segurança padrão ainda tem muito espaço para melhorar
- A decisão de ativar o AppArmor por padrão a partir do Debian 10 é um passo positivo para melhorar a segurança, mas é insuficiente por ter sido implementada apenas pela metade em todo o sistema
- A dependência do Debian em relação ao AppArmor e sua configuração padrão mostram que há problemas sistêmicos em sua abordagem de segurança
- O AppArmor pode oferecer segurança robusta quando configurado corretamente, mas a configuração padrão do Debian não aproveita esse potencial
Problemas do AppArmor no Debian
- Perfis padrão limitados: o Debian vem com um conjunto mínimo de perfis AppArmor, deixando muitos serviços importantes sem proteção
- Postura reativa em vez de proativa: o modelo de segurança do Debian frequentemente depende de que os usuários implementem políticas mais rígidas, em vez de fornecer configurações seguras por padrão
- Aplicação inconsistente: ao contrário do SELinux nos sistemas Red Hat, o AppArmor no Debian é aplicado apenas parcialmente, o que cria possíveis lacunas de segurança
- Falta de recursos: como projeto orientado pela comunidade, o Debian não dispõe dos recursos necessários para desenvolver e manter políticas de segurança abrangentes semelhantes às oferecidas pela Red Hat
Execução de cargas de trabalho em contêineres com Docker no Debian
- É muito comum executar cargas de trabalho em contêineres com Docker no Debian
- O Docker gera e carrega automaticamente um perfil AppArmor padrão para contêineres chamado
docker-default
- Infelizmente, esse não é um perfil muito robusto em termos de segurança e é permissivo demais
- Esse perfil oferece algum nível de proteção, mas deixa exposta uma superfície de ataque significativa
Diferenças fundamentais entre AppArmor e SELinux
- A diferença fundamental entre AppArmor e SELinux está na abordagem de cada um ao controle de acesso obrigatório (MAC)
- O AppArmor opera com um modelo baseado em caminhos, enquanto o SELinux usa um sistema de aplicação por tipos muito mais complexo
- Essas diferenças ficam especialmente evidentes em ambientes de contêineres
- O SELinux aplica tipos a todos os objetos do sistema (arquivos, processos, portas etc.)
- Quando um contêiner é iniciado em um sistema RHEL com suporte a SELinux, ele recebe imediatamente o tipo
container_t, um mecanismo rigoroso de controle de acesso
- O tipo
container_t bloqueia efetivamente o contêiner, impedindo que ele interaja com objetos que não estejam explicitamente rotulados para uso por contêineres
- O SELinux não para na aplicação por tipos e leva o isolamento de contêineres um passo adiante usando rótulos de segurança multicategoria (MCS)
- Esses rótulos funcionam como uma camada adicional de separação que mantém o isolamento até mesmo entre contêineres do mesmo tipo (
container_t)
- Cada contêiner recebe um rótulo MCS exclusivo, criando um sandbox privado dentro do ambiente mais amplo de
container_t
A abordagem do AppArmor
- O AppArmor não se preocupa com tipos nem categorias e se concentra em restringir as capacidades de programas específicos com base em perfis predefinidos
- Esses perfis especificam quais arquivos o programa pode acessar e quais ações ele pode executar
- Essa abordagem é mais simples de implementar e entender, mas não é tão granular nem tão consistente em todo o sistema quanto a aplicação por tipos do SELinux
- As distribuições Linux mais populares não distribuem, por padrão, perfis AppArmor abrangentes para todos os daemons comuns voltados à rede
Impacto real
- Em um ambiente com SELinux, um contêiner comprometido enfrenta obstáculos significativos para acessar ou afetar o sistema hospedeiro ou outros contêineres, graças à barreira dupla da aplicação por tipos e dos rótulos MCS
- O SELinux oferece isolamento mais forte, mas isso vem ao custo de maior complexidade e potencial sobrecarga de desempenho
- O AppArmor oferece um modelo de segurança mais simples e acessível, que ainda pode ser muito eficaz quando configurado corretamente
- A Red Hat fez esforço para tornar o uso de SELinux com contêineres algo fluido e fácil
- No fim, a escolha entre Debian e Red Hat não é simplesmente uma escolha entre influência corporativa e desenvolvimento guiado pela comunidade
- É também uma escolha entre um sistema que presume o melhor e um sistema que se prepara para o pior
- No mundo altamente conectado de hoje, infelizmente, o pessimismo é essencial
A opinião do GN⁺
- A mudança na política de distribuição do código-fonte do RHEL pela Red Hat é controversa, mas do ponto de vista da segurança pode ser uma decisão razoável
- Em distribuições Linux corporativas, oferecer recursos fortes de segurança como o SELinux é essencial
- No entanto, a mudança de política da Red Hat pode ter impacto negativo no ecossistema de código aberto, e o papel de distribuições baseadas na comunidade como o Debian deve se tornar ainda mais importante
- O Debian é conhecido como uma distribuição amigável e flexível, mas precisa reforçar seus recursos de segurança padrão
- O AppArmor não é tão poderoso quanto o SELinux, mas, se configurado adequadamente, pode ser uma solução de segurança eficaz
- No longo prazo, pode ser necessário desenvolver uma nova estrutura de segurança que combine as vantagens do SELinux e do AppArmor
- A segurança de contêineres é uma questão muito importante na era cloud native, então todas as distribuições precisam dedicar mais esforços a essa área
2 comentários
É verdade que o AppArmor é menos rigoroso que o SELinux..
Mas é difícil dizer que isso o torna vulnerável em termos de segurança.
O SELinux é tão rigoroso que, ao configurar um servidor, quase sempre acabam desativando o SELinux.
E, no desktop, segurança não é a principal preocupação do SELinux.
São necessárias restrições e procedimentos adequados de solicitação de autenticação do ponto de vista da UI e da experiência do usuário, e isso é uma questão diferente do isolamento de recursos como no SELinux.
Por isso, a segurança em desktop, seja na linha do Red Hat ou na linha do Debian, funciona com base no polkit (PolicyKit), que é padronizado pelo freedesktop.
Opinião do Hacker News