Razões para desativar / ativar o SELinux

Na linha desta pergunta sobre StackOverflow e a multidão completamente diferente que temos aqui, pergunto-me: quais são seus motivos para desativar o SELinux (supondo que a maioria das pessoas ainda o faça)? Deseja mantê-lo ativado? Que anomalias você experimentou ao deixar o SELinux ativado? Além da Oracle, que outros fornecedores apresentam problemas para oferecer suporte a sistemas com o SELinux ativado?

Pergunta bônus: Alguém conseguiu fazer o Oracle rodar no RHEL5 com o SELinux para aplicar o modo de destino? Quero dizer, estrito seria incrível, mas ainda não é possível remotamente, então vamos ficar com o alvo primeiro ;-)

O RedHat ativa o SELinux por padrão, porque é mais seguro. Quase todo fornecedor que usa produtos derivados do Redhat desativa o SELinux porque não quer gastar tempo (e, portanto, dinheiro) para descobrir por que a coisa não funciona. O pessoal do Redhat / Fedora dedicou uma quantidade enorme de tempo e esforço, tornando o SELinux mais uma opção viável na empresa, mas muitas outras organizações realmente não se importam com a sua segurança. (Eles se preocupam com a segurança e a reputação de segurança do produto, o que é uma coisa totalmente diferente.)

Se você pode fazê-lo funcionar, vá em frente. Se você não puder, não espere muita assistência dos fornecedores por aí. Você provavelmente pode obter ajuda dos caras do Redhat / Fedora, das listas de discussão selinux e do canal #selinux no freenode. Mas de empresas como a Oracle - bem, o SELinux não leva em consideração o plano de negócios deles.

Normalmente, é melhor executar o SELinux no Permissivo do que desativá-lo completamente. Você pode verificar (via audit2why) depois de um tempo para ver que tipos de violações seriam negadas durante seu uso regular e criar políticas personalizadas via audit2allowse essas 'violações' forem falso-positivas para sua configuração.

Eu descobri que o comportamento do SELinux em sistemas não derivados do Fedora é significativamente mais sensível do que o que você obtém com um sistema típico do Fedora / RHEL por padrão.

Se você ainda não o viu, pode encontrar o Guia do Usuário do Fedora SELinux educacional.

Razões para:

• Maior nível de segurança através do controle de acesso obrigatório
• Você precisa de um motivo além do nível de segurança mais alto? :-)

Razões contra:

• Difícil de entender
• Difícil de gerenciar
• Difícil de solucionar problemas

Dito isto, se você está considerando o SELinux, recomendo o livro SELinux by Example .

Eu trabalhei para uma empresa que tinha o SELinux ativado, no modo de imposição, em todos os sistemas. A chave para nós foi entender e usar o programa audit2allow, que pode ser usado para criar novas regras de contexto.

Primeiro, geramos um modelo com audit2allow e depois usamos um script para construí-lo, assim:

export NAME="my_serviced"
sudo audit2allow -m "${NAME}" -i /var/log/audit/audit.log > ${NAME}.te
sudo setup_semodule ${NAME}

O script setup_semodule:

#!/bin/sh

# Where to store selinux related files
SOURCE=/etc/selinux/local
BUILD=/etc/selinux/local
NAME=$1

/usr/bin/checkmodule -M -m -o ${BUILD}/${NAME}.mod ${SOURCE}/${NAME}.te
/usr/bin/semodule_package -o ${BUILD}/${NAME}.pp -m ${BUILD}/${NAME}.mod
/usr/sbin/semodule -i ${BUILD}/${NAME}.pp

/bin/rm ${BUILD}/${NAME}.mod ${BUILD}/${NAME}.pp

Isso cria o módulo a partir do modelo (arquivo .te), gera um pacote e carrega o módulo.

Usamos o Puppet em nosso sistema de gerenciamento de configurações e escrevemos uma configuração para o Puppet para gerenciar tudo isso.

Módulo de bonecos SELinux:

• http://github.com/sansnoc/puppet/tree/master/selinux

O motivo para desativá-lo é porque pode ser difícil depurar.

No entanto, não o desligamos agora. Quase sempre o mantemos funcionando. Ocasionalmente, desativo-o para verificar rapidamente se o SElinux é um problema ou não.

É muito mais fácil depurar agora, especialmente se você se familiarizar com o audit2allow. Você realmente não precisa entender isso com o audit2allow, mas algumas vezes pode acabar abrindo o thins mais amplo do que você pensa com o audit2allow. Dito isto, alguns SELinux são melhores que nenhum.

Não sou especialista em SELinux e só o uso há alguns anos. Ainda não entendo o básico, mas sei o suficiente para executar aplicativos, por aqueles incluídos na distribuição e nas coisas aleatórias compiladas da 'net'.

A principal coisa que eu tive que usar são o ls -lZ(contexto SELinux show), audit2allow, chcon, semodule, getenforce, setenforcee booleans. Com essas ferramentas, consegui obter todos os aplicativos necessários para executar no SELinux.

Acho que um dos grandes problemas com a depuração de problemas no SELinux é simplesmente lembrar de procurar problemas no SELinux quando tenho outros problemas inexplicáveis. Geralmente, levo um pouco de tempo para dizer "h! Verifique o SELinux !!".

De acordo com a página de manual do bind, o SELinux é muito mais seguro do que executar o bind em uma prisão chroot. Muitas outras pessoas que têm muito mais pistas do que eu também recomendo, então eu as cego agora. E suspeito, apesar do problema ocasional, provavelmente vale a pena fazer.

Desativei o SELinux para AppArmor , achei muito mais amigável e fácil de manter do que o SELinux.

Não há motivo para desligá-lo quando você pode executá-lo no modo Permissivo. Ele não interferirá no aplicativo em execução e ainda fornecerá um registro de segurança útil. A única exceção é sobre os contextos do usuário: se você estiver mudando entre usuários diferentes vivendo dentro de outra instância do linux em execução em um chroot, poderá haver problemas.

O SE Linux não é tão irremediavelmente hostil como costumava ser, pelo menos não está em distros comercialmente suportadas, como o RHEL5. Na maioria das vezes, você pode deixá-lo ligado e tudo ficará bem com qualquer coisa fornecida pelo RedHat. Com qualquer outra coisa, pode ser variável. O problema é que o serviço profissional trabalha para que os aplicativos funcionem com o SE Linux habilitado é um bom fluxo de receita para empresas como RedHat e Oracle, portanto elas não têm incentivo para fazer tudo funcionar bem.