1. Preâmbulo
O Linux Aprimorado em Segurança (SELinux) é um módulo do kernel Linux e um subsistema de segurança do Linux.
O SELinux foi desenvolvido principalmente pela NSA. Kernels Linux 2.6 e superiores já integram módulos SELinux.
SELinux é muito complexo e tem muita coisa conceitual difícil de aprender. Muitos administradores de sistemas Linux desativaram o SELinux porque acham problemático.
Se você dominar o SELinux e usá-lo corretamente, acho que todo o sistema pode basicamente chegar ao ponto de ser "indestrutível" (sempre lembre-se de que não existe segurança absoluta).
Dominar os conceitos básicos do SELinux, bem como métodos simples de configuração, é um curso obrigatório para todo administrador de sistemas Linux.
Este artigo é baseado no CentOS 7.4.1708.
Este artigo é puramente um compartilhamento e troca de experiências de aprendizado pessoal, erros são inevitáveis, apenas para referência! Se encontrar algum erro, por favor aponte, muito obrigado!
2. O papel do SELinux e o mecanismo de gerenciamento de permissões
2.1 O papel do SELinux
A principal função do SELinux é minimizar os recursos que podem ser acessados pelos processos de serviço no sistema (o princípio do privilégio mínimo).
Imagine que, se um serviço de rede rodando como root tem uma vulnerabilidade 0day, hackers podem explorar essa vulnerabilidade para fazer o que quiserem no seu servidor como root. Não é assustador?
A SELinux está aqui para resolver esse problema.
2.2 DAC
Em um sistema operacional que não utiliza o SELinux, o fator que determina se um recurso pode ser acessado é se o recurso possui as permissões do usuário correspondente (ler, escrever, executar).
Desde que o processo que acessa esse recurso atenda às condições acima, ele pode ser acessado.
O problema mais fatal é que os usuários root não estão sujeitos a nenhuma regulamentação, e quaisquer recursos no sistema podem ser acessados sem restrições.
O principal corpo desse mecanismo de gerenciamento de permissões é o usuário, também conhecido como controle de acesso autônomo (DAC).
2.3 MAC
Em um sistema operacional que utiliza SELinux, os fatores que determinam se um recurso pode ser acessado não são apenas os fatores acima, mas também se cada tipo de processo tem acesso a um determinado tipo de recurso.
Dessa forma, mesmo que um processo esteja rodando como root, é necessário determinar o tipo de processo e os tipos de recursos que podem ser acessados antes de decidir se permite o acesso a um recurso. O espaço ativo do processo também pode ser comprimido ao mínimo.
Mesmo um processo de serviço rodando como root geralmente só tem acesso aos recursos que precisa. Mesmo que um programa seja vulnerável, o escopo do impacto é limitado aos recursos que ele tem acesso. A segurança é muito aumentada.
O principal corpo desse mecanismo de gerenciamento de permissões é o processo, também conhecido como controle de acesso obrigatório (MAC).
O MAC é subdividido de duas maneiras: uma chamada de modo de Segurança de Categoria (MCS) e a outra chamada de modo Multi-Level Security (MLS).
As seguintes ações estão no modo MCS.
2.4 Comparação entre DAC e MAC
Aqui está uma imagem para ilustrar.
Como você pode ver, no modo DAC, desde que o diretório correspondente tenha as permissões do usuário correspondente, ele pode ser acessado. No modo MAC, também é limitado pela variedade de diretórios que os processos podem acessar.
3. Conceitos básicos do SELinux
3.1 Sujeito
Pode ser completamente equiparado a um processo.
Nota: Para facilitar a compreensão, salvo indicação em contrário, o processo é considerado o principal órgão abaixo.
3.2 Objetivo
Recursos acessados pelo diretor. Pode ser arquivos, diretórios, portas, dispositivos, etc.
Nota: Para facilitar a compreensão, salvo especificação em contrário, os seguintes documentos ou diretórios são considerados objetos.
3.3 Política e Regra
Geralmente há um grande número de arquivos e processos no sistema e, para economizar tempo e sobrecarga, geralmente regulamos seletivamente apenas certos processos.
E quais processos precisam ser regulados e como controlá-los são determinados pela política.
Existem várias regras em uma apólice. Algumas regras podem ser ativadas ou desativadas conforme necessário (doravante chamadas de regras booleanas).
As regras são modulares e extensíveis. Ao instalar um novo aplicativo, o aplicativo pode adicionar regras adicionando novos módulos. Os usuários também podem adicionar ou subtrair regras manualmente.
No sistema CentOS 7, existem três conjuntos de políticas, a saber:
1. direcionado: Controla a maioria dos processos de serviço de rede. Essa é a política usada pelo sistema por padrão (todas as abaixo são usadas).
2. Mínimo: Com base no alvo, apenas processos selecionados de serviço de rede são regulados. Geralmente não.
3. MLS: Proteção de segurança multinível. Regule todos os processos. Essa é a política mais rígida, e a configuração é muito difícil. Geralmente, não é usado a menos que haja exigências extremamente altas de segurança.
As políticas podem ser definidas em /etc/selinux/config.
3.4 Contexto de Segurança
O contexto de segurança está no cerne do SELinux.
Contexto de segurança, divido em "contexto de segurança de processos" e "contexto de segurança documental".
Um Contexto de Segurança de Processos normalmente corresponde a múltiplos Contextos de Segurança de Documentos.
Somente quando o contexto de segurança dos dois corresponde é que um processo pode acessar o arquivo. A correspondência deles é determinada pelas regras da apólice.
O contexto de segurança do arquivo é determinado pelo local onde o arquivo foi criado e pelo processo que o criou. E o sistema tem um conjunto de valores padrão, e os usuários também podem definir esses valores.
É importante notar que simplesmente mover arquivos não muda o contexto de segurança dos seus arquivos.
A estrutura e o significado do contexto de segurança
O contexto de segurança possui quatro campos, separados por dois pontos. Formas como: system_u:object_r:admin_home_t:s0.
3.5 Modo de Funcionamento SELinux
O SELinux possui três modos de operação, a saber:
1. aplicando: Modo imposto. Violações das regras do SELinux serão bloqueadas e registradas nos logs.
2. Permissivo: modo tolerância. As violações das regras SELinux só são registradas nos logs. Geralmente para depuração.
3. desativado: Desligue o SELinux.
O modo de funcionamento do SELinux pode ser configurado em /etc/selinux/config.
Se quiser mudar de deficiente para fiscalização ou permissivo, precisará reiniciar o sistema. E vice-versa.
Modos de aplicação e permissivo podem ser rapidamente trocados com o comando Setenforce 1|0.
É importante notar que, se o sistema estiver rodando com o SELinux desligado por um tempo, a primeira reinicialização após o SELinux ser ativada pode ser mais lenta. Porque o sistema precisa criar um contexto seguro para os arquivos no disco (eu disse que reiniciei por cerca de 10 minutos e achei que estava morto...... ）。
Os logs do SELinux precisam ser registrados com a ajuda do auditd.service, por favor, não o desabilite.
3.6 Fluxo de Trabalho SELinux
Aqui está uma citação de uma foto, sem muita explicação.
Nota: O texto de segurança acima refere-se ao contexto de segurança.
4. Operações básicas do SELinux
4.1 Consultar o contexto de segurança de um arquivo ou diretório
Uso básico de comandos
ls -z
Exemplos de uso
Consulte o contexto de segurança de /etc/hosts.
ls -Z /etc/hosts
Resultados da execução
-r-r--r--. raiz raiz system_u:object_r:net_conf_t:s0 /etc/hosts
4.2 Consultar o contexto de segurança do processo
Uso básico de comandos
ps auxZ | grep -v grep | grep
Exemplos de uso
Consulte o contexto de segurança dos processos relacionados ao Nginx.
ps auxZ | grep -v grep | Grep Nginx
Resultados da execução
system_u:system_r:httpd_t:s0 raiz 7997 0,0 0,0 122784 2156 ? Ss 14:31 0:00 nginx: processo mestre /usr/sbin/nginx
system_u:system_r:httpd_t:s0 nginx 7998 0.0 0.0 125332 7560 ? S 14:31 0:00 nginx: processo do trabalhador
4.3 Modificar manualmente o contexto de segurança de um arquivo ou diretório
Uso básico de comandos
CHCON [...]
Função opção -u Modificar o campo usuário do contexto de segurança -r Modificar o campo de função do contexto de segurança -t Modificar o campo tipo do contexto de segurança -l Modificar o campo de nível do contexto de segurança --reference Modificar o contexto de segurança consistente com o arquivo ou diretório especificado -R Operação recursiva -h Modificar o contexto de segurança do soft link (modificar o arquivo correspondente do soft link sem essa opção)
Exemplos de uso
Modificar o contexto de segurança do teste para aaa_u:bbb_r:ccc_t:s0.
chcon -u aaa_u -r bbb_r -t teste ccc_t
4.4 Reverter o contexto de segurança de um arquivo ou diretório para seu valor padrão
Uso básico de comandos
RestoreCon [Opções] [...]
Função de Opção - Procedimento de Operação de Impressão V - Operação Recursiva R
Exemplos de uso
Depois de adicionar alguns arquivos web ao diretório do seu servidor Nginx, defina o contexto de segurança correto para esses novos arquivos.
restorecon -R /usr/share/nginx/html/
4.5 Consultar regras booleanas e seu status no sistema
Uso básico de comandos
getsebool -a
Como o comando consulta todas as regras ou apenas uma, geralmente ele consulta todas as regras primeiro e depois filtra com grep.
Exemplos de uso
Consulte regras booleanas relacionadas a httpd.
getsebool -a | grep httpd
Resultados da execução
httpd_anon_write --> desliga
httpd_builtin_scripting --> em frente
httpd_can_check_spam --> desliga
httpd_can_connect_ftp --> desliga
#以下省略
4.6 Mudando uma regra booleana
Uso básico de comandos
setsebool [opção]
Função de opção -P reiniciar ainda está em vigor
Exemplos de uso
Ligue httpd_anon_write regras.
setsebool - P httpd_anon_write ligado
4.7 Adicionar um Contexto de Segurança Padrão para um Diretório
Uso básico de comandos
semanage fcontext -a -t "(/.*)?"
Nota: O contexto de segurança padrão de um diretório ou arquivo pode ser visualizado usando o comando semanage fcontext -l em conjunto com o filtro grep.
Exemplos de uso
Depois de adicionar um novo diretório de site /usr/share/nginx/html2 ao Nginx, você precisa definir o mesmo contexto de segurança padrão do diretório original.
semanage fcontext -a -t httpd_sys_content_t "/usr/share/nginx/html2(/.*)?"
4.8 Adicionar portas permitidas por certos tipos de processos
Uso básico de comandos
Porta SEMANAGE -A -T -P
Nota: Os números de porta permitidos para vários tipos de serviço podem ser visualizados usando o comando semanage port -l com filtragem grep.
Exemplos de uso
Para o Nginx, você precisa usar a porta 10080 para serviços HTTP.
Porta SEMANAGE -A -T http_port_t -P TCP 10080
5. Análise e resolução de erros do SELinux
5.1 Entendendo os Logs SELinux
Quando o SELinux está habilitado, algum comportamento normal de muitos serviços é considerado uma violação (tanto no título quanto nos erros abaixo).
Neste momento, precisamos usar os registros de violação do SELinux para analisá-las e resolvê-las.
Os registros de violações do SELinux são salvos em /var/log/audit/audit.log.
/var/log/audit/audit.log 的内容大概是这样的。
type=LOGIN msg=audit(1507898701.391:515): pid=8523 uid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 old-auid=4294967295 auid=0 tty=(nenhum) old-ses=4294967295 ses=25 res=1
Tipo=USER_START MSG=Audit(1507898701.421:516): PID=8523 UID=0 AuID=0 SES=25 Subj=system_u:system_r:crond_t:S0-S0:C0.C1023 MSG='op=PAM:session_open doatores=pam_loginuid.pam_ keyinit,pam_limits,pam_systemd acct="root" exe="/usr/sbin/crond" nome do host=? addr=? terminal=cron res=sucesso'
...
O arquivo tem muito conteúdo e está misturado com muitos logs de auditoria do sistema que não têm nada a ver com erros do SELinux. Vamos usar o utilitário sealert para ajudar na análise (se o prompt não encontrar o comando, instale o pacote setroubleshoot).
5.2 Analisar erros com o sealert
Uso básico de comandos
SeAlert -a /var/log/audit/audit.log
Após executar o comando, o sistema precisa dedicar algum tempo para analisar as violações nos logs e fornecer um relatório de análise. |
Publicado em 05/07/2019 11:25:50
|
|
|
|
Senhorio|
Publicado em 22/07/2021 17:17:58
|
