Razões para desabilitar / habilitar o SELinux

35

Na linha desta pergunta no StackOverflow e a multidão completamente diferente que temos aqui , Eu me pergunto: quais são os seus motivos para desativar o SELinux (supondo que a maioria das pessoas ainda o faça)? Você gostaria de mantê-lo ativado? Quais anomalias você experimentou ao deixar o SELinux ligado? Além da Oracle, o que outros fornecedores dão problemas para suportar sistemas com o SELinux ativado?

Pergunta de bônus: Alguém conseguiu executar o Oracle no RHEL5 com o SELinux ao impor o modo de destino? Quero dizer, estrito seria incrível, mas eu não é mesmo remotamente possível ainda, então vamos ficar focados primeiro; -)

    
por wzzrd 24.06.2009 / 08:26

7 respostas

25

O RedHat ativa o SELinux por padrão porque é mais seguro. Quase todos os fornecedores que usam produtos derivados do Redhat desativam o SELinux porque eles não querem ter tempo (e, portanto, dinheiro) para descobrir por que a coisa não funciona. As pessoas do Redhat / Fedora colocaram uma enorme quantidade de tempo e esforço fazendo do SELinux uma opção mais viável na Enterprise, mas muitas outras organizações não se importam com a segurança do seu . (Eles se preocupam com a segurança deles e com a reputação de segurança de seus produtos, o que é uma coisa totalmente diferente).

Se você conseguir fazer isso funcionar, vá em frente. Se você não pode, então não espere muita ajuda dos fornecedores lá fora. Provavelmente você pode obter ajuda dos caras do Redhat / Fedora, das listas de discussão do selinux e do canal #selinux no freenode. Mas de empresas como a Oracle - bem, o SELinux não leva em consideração seu plano de negócios.

    
por 24.06.2009 / 10:44
20

Normalmente, é melhor você executar o SELinux em Permissive em vez de desabilitá-lo completamente. Você pode verificar (via audit2why ) depois de um tempo para ver que tipos de violações teriam sido negados durante seu uso regular e criar políticas personalizadas por meio de audit2allow se essas 'violações' forem falsos positivos 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, poderá encontrar o Usuário do Fedora SELinux Guia educacional.

    
por 24.06.2009 / 15:50
15

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 mais alto de segurança? : -)

Razões contra:

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

Dito isto, se você está pensando em SELinux, eu recomendo o livro SELinux por exemplo .

Eu trabalhei para uma empresa que tinha o SELinux ativado, em modo de execuçã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 usamos um script para criá-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 constrói o módulo a partir do modelo (arquivo .te), gera um pacote e, em seguida, carrega o módulo.

Usamos o Puppet para nosso sistema de gerenciamento de configuração e escrevemos a configuração do Puppet para gerenciar tudo isso.

SELinux Puppet Module:

por 26.06.2009 / 22:22
10

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

No entanto, não a desativamos agora. Nós quase sempre continuamos correndo. 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 você pode, algumas vezes, acabar abrindo mais do que você pensa com o audit2allow. Tendo dito que algum SELinux é melhor que nenhum.

Não sou de forma alguma um especialista em SELinux e só o utilizo há alguns anos. Eu ainda não entendo o básico, mas sei o suficiente para colocar os aplicativos em funcionamento, incluindo os que estão incluídos na distribuição e coisas aleatórias compiladas da 'net'.

A principal coisa que eu tive que usar é o ls -lZ (contexto show selinux), audit2allow , chcon , semodule , getenforce , setenforce e booleanos. Com essas ferramentas, consegui obter todos os aplicativos necessários para a execução no SELinux.

Eu acho que um dos grandes problemas com a depuração de problemas do SELinux, é simplesmente remeber para checar os problemas do SELinux quando eu tiver outros problemas inexplicáveis. Geralmente me leva um pouco para ir "h! Check SELinux !!".

De acordo com a man page do bind, o SELinux é muito mais seguro do que rodar bind em uma jaula chroot. Um monte de outras pessoas que têm muito mais pistas do que eu também recomendo, então eu corro cegamente agora. E suspeito, apesar do problema ocasional, provavelmente vale a pena.

    
por 24.06.2009 / 13:33
2

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

    
por 24.06.2009 / 10:21
1

Não há motivo para desativá-lo quando você pode executá-lo no modo Permissivo. Ele não interferirá no aplicativo em execução e ainda fornecerá registros de segurança úteis. A única exceção é sobre os contextos do usuário: se você está mudando entre diferentes usuários que vivem dentro de outra instância do Linux em execução em um chroot, você pode ter problemas.

    
por 26.06.2009 / 21:58
0

O SE Linux não é tão desesperadamente hostil quanto costumava ser, pelo menos não em distribuições comercialmente suportadas como o RHEL5. Para a maior parte, 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 trabalho de serviço profissional para obter aplicativos trabalhando com o SE Linux ativado é um bom fluxo de receita para empresas como RedHat e Oracle, então eles não têm incentivo para fazer tudo funcionar bem.

    
por 24.06.2009 / 09:15