O SELinux torna Redhat mais seguro?
Não consigo me lembrar do número de vezes em que desativei o SELinux porque ele ficava frustrando minha capacidade de colocar as coisas em funcionamento. Muitas vezes não havia nenhuma razão óbvia para que as coisas não estivessem funcionando e eu tive que procurar no Google por quê.
Dado que a maioria dos usuários casuais desabilitará ou enfraquecerá a segurança quando ela aparecer no caminho, com a exclusão de usuários sérios e seguros da Redhat, o SELinux será realmente útil?
PS. Existe alguma ferramenta que ajuda você a registrar, rastrear e gerenciar os problemas do SELinux em todos os aplicativos?
Sim, o Selinux torna o sistema mais seguro. Mas você precisará entender conceitos e ter pelo menos um conhecimento básico sobre selinux e ferramentas de auditoria.
O Selinux está logando para /var/log/audit/audit.log (mas assegura que o auditd esteja rodando), e há várias ferramentas para resolver problemas do selinux. A maneira mais simples de usar é audit2allow
Sim, o SELinux torna a Red Hat (e qualquer outra distribuição Linux que realmente a usa) mais segura, supondo que esteja realmente em uso.
O SELinux implementa o controle de acesso obrigatório . Permissões normais do Unix, ACLs, etc., implementam o controle de acesso discricionário . Os dois se complementam.
Para funcionar, o SELinux requer uma política, definindo quais ações no sistema podem ser permitidas. Embora seja possível criar uma política do sistema inteira a partir do zero, a maioria das distribuições do Linux envia uma política baseada na chamada política de referência . Isto significa, entre outras coisas, que a configuração do SELinux através de distribuições será muito similar. (A maioria das distribuições do Linux disponibiliza a política de referência do SELinux em seus repositórios de pacotes, embora possa não ser instalada por padrão).
O SELinux funciona restringindo usuários e processos a executar somente as ações permitidas a eles na política. Por padrão, a política é negar, portanto, se a política não permitir explicitamente uma ação, isso não acontece. É por isso que você frequentemente se vê em apuros com o SELinux não permitindo algo que esteja tentando fazer.
No lado positivo, isso também impede que façanhas, mesmo exploits de 0 dia, saiam do controle. Por exemplo, se o seu servidor web (Apache) é explorado, o dano é limitado apenas àquelas coisas que o Apache pode acessar. Ele não seria capaz de ler seu arquivo /etc/shadow , por exemplo, mesmo com uma exploração remota remota. Enquanto as permissões Unix (DAC) permitem que o root leia o arquivo, o SELinux (MAC) não permite que o processo comprometido saia do limite.
A grande pegadinha é que deve haver um módulo de política do SELinux carregado para o serviço. Se você instalar um serviço em sua caixa que não inclua um módulo de política do SELinux, ele será executado sem confinamento e poderá fazer o que quiser. O SELinux não se aplicará a ele.
Outra coisa que você deve saber é sobre booleanos . Esses parâmetros ajustáveis são fornecidos pelas políticas do SELinux para personalizá-los para instalações específicas e permitir ou negar acesso com base nas necessidades de configuração local. Por exemplo, você pode dar acesso ao Apache para compartilhamentos do Samba, permitir que o Samba compartilhe diretórios pessoais de usuários e muitas outras coisas potencialmente úteis que são necessárias para algumas configurações, mas não para outras.
O melhor guia para o SELinux que eu vi atualmente é o Red Hat's Guia do Usuário do Linux Aprimorado pela Segurança . Ele ajudará você a começar a trabalhar rapidamente, além de preencher os detalhes do que está acontecendo. Ele também inclui um abrangente guia de solução de problemas que ajuda você a executar seu processo no SELinux.
É útil?
O SELinux protege contra processos (e usuários, se você confinou seus usuários) fazendo coisas inesperadas. Isso limita severamente o dano que uma exploração remota pode fazer. Se você nunca sofreu um comprometimento remoto, você é (1) afortunado e (2) provavelmente novo. Se você tiver trabalhado em um compromisso remoto, você certamente não desejará que isso aconteça novamente.
Não é tão útil em uma configuração home , a menos que você esteja executando serviços voltados para a Internet em casa (e algumas pessoas o fazem). Nesse caso, tudo o que foi dito acima se aplica.
O SELinux pode ser a última coisa entre os seus dados e um invasor com um exploit de 0 dias que realmente quer. Se você pode usá-lo, por que você não o faria?
Acho que o SELinux apenas amplia o sistema de permissões tradicionais, introduzindo configurações estendidas sobre as permissões. Isso torna seu sistema mais seguro? Eu acho que isso depende de como você usa o SELinux em seus aplicativos. Também não sou bom no SELinux, mas configurá-lo precisa de mais conhecimento sobre quais limitações ele pode fornecer a você. Mas também introduz muitos problemas que você precisa investigar manualmente para superar
Existe um pacote que ajuda os usuários a encontrar problemas causados pelo SELinux chamado setroubleshoot. Instale-o, configure-o para ser executado no início. Então, quando você obtiver uma negação do SELinux, ela será registrada em /var/log/messages . Se você estiver logado na GUI, você receberá uma notificação.