Introdução ao SELinux - Parte 1: Conceitos Básicos
Introdução
Security Enhanced Linux ou SELinux é um mecanismo avançado de controle de acesso integrado na maioria das distribuições Linux modernas. Foi desenvolvido inicialmente pela Agência de Segurança Nacional dos EUA para proteger os sistemas de computador contra invasões e adulterações maliciosas. Com o tempo, o SELinux foi lançado em domínio público e várias distribuições o incorporaram em seu código.
Muitos administradores de sistemas consideram o SELinux um território um pouco desconhecido. O tópico pode parecer assustador e às vezes bastante confuso. No entanto, um sistema SELinux configurado corretamente pode reduzir muito os riscos de segurança, e saber um pouco sobre isso pode ajudá-lo a solucionar mensagens de erro relacionadas ao acesso. Neste tutorial vamos aprender sobre os conceitos por trás do SELinux - seus pacotes, comandos e arquivos de configuração - e as mensagens de erro que ele registra quando o acesso é negado. Também veremos alguns exemplos práticos de colocar o SELinux em ação.
Ambiente:
Para este laboratório foi utilizado 1 host, denominado de server01, com utilização do Apache para as devidas liberações.
Descrição dos servidores:
Server01:
Sistema Operacional : CentOS 7
Hostname : server01.fedorabr.lab
IP : 192.168.122.150/24
Neste tutorial, estaremos executando os comandos como o usuário root, a menos que seja indicado o contrário. Se você não tiver acesso à conta root e usar outra conta com privilégios sudo, precisará preceder os comandos com “sudo -” digitando seu password.
Por que o SELinux
Antes de começarmos, vamos entender alguns conceitos.
O SELinux implementa o que é conhecido como MAC (Mandatory Access Control / Controle de Acesso Obrigatório). Isto é implementado em cima do que já está presente em todas as distribuições Linux, o DAC (Discretionary Access Contro / Controle de Acesso Discricionáriol).
Para entender o DAC, vamos primeiro considerar como a segurança tradicional de arquivos do Linux funciona.
Em um modelo de segurança tradicional, temos três entidades: Usuário, Grupo e Outros (u, g, o) que podem ter uma combinação de permissões de Leitura, Gravação e Execução (r,w,x) em um arquivo ou diretório. Se o usuário “chico” criar um arquivo em seu diretório pessoal, esse usuário terá acesso de leitura/gravação a ele e, assim, o grupo “chico”. Uma "outra" entidade possivelmente não terá acesso a ela. No bloco de código a seguir, podemos considerar o conteúdo hipotético do diretório inicial de “chico”.
Você não precisa configurar este usuário “chico” - nós estaremos configurando muitos usuários mais tarde no tutorial.
Executando um comando como este:
[root@server01 ~]# ls -l /home/chico/
pode mostrar a saída como o seguinte:
total 0 -rw-r--r--. 1 root root 0 Mai 3 13:06 arquivo
Agora jo pode alterar esse acesso. chico pode conceder (e restringir) o acesso a este arquivo para outros usuários e grupos ou alterar o proprietário do arquivo. Essas ações podem deixar arquivos críticos expostos a contas que não precisam desse acesso. chico também pode restringir para ser mais seguro, mas isso é discricionário: não há como o administrador do sistema aplicá-lo a cada arquivo no sistema.
Considere outro caso: quando um processo Linux é executado, ele pode ser executado como o usuário root ou outra conta com privilégios de superusuário. Isso significa que se um hacker toma o controle do aplicativo, ele pode usar esse aplicativo para obter acesso a qualquer recurso que a conta do usuário tenha acesso. Para processos em execução como usuário root, basicamente isso significa acesso a tudo no servidor Linux.
Pense em um cenário em que você deseja impedir que os usuários executem scripts de shell de seus diretórios iniciais. Isso pode acontecer quando você tem desenvolvedores trabalhando em um sistema de produção. Você gostaria que eles visualizassem arquivos de log, mas você não quer que eles usem su ou sudo para comandos, e você não quer que eles executem quaisquer scripts de seus diretórios pessoais. Como você faz isso?
O SELinux é uma maneira de ajustar esses requisitos de controle de acesso. Com o SELinux, você pode definir o que um usuário ou processo pode fazer. Ele confina cada processo a seu próprio domínio para que o processo possa interagir apenas com determinados tipos de arquivos e outros processos dos domínios permitidos. Isso impede que um hacker sequestre qualquer processo para obter acesso ao sistema.
Configurando um sistema de teste
Para nos ajudar a aprender os conceitos, construiremos um servidor de teste executando tanto um servidor web quanto um servidor SFTP. Vamos começar com uma instalação simples do CentOS 7 com o mínimo de pacotes instalados e instalar os daemons Apache e vsftp nesse servidor. No entanto, não iremos configurar nenhum desses aplicativos.
Também criaremos algumas contas de usuário de teste no nosso servidor. Usaremos essas contas em lugares diferentes ao longo do tutorial.
Finalmente, instalaremos os pacotes relacionados ao SELinux necessários. Isso é para garantir que possamos trabalhar com os comandos mais recentes do SELinux.
Instalando os serviços Apache e SFTP
Primeiro, vamos efetuar login no servidor como usuário root e executar o seguinte comando para instalar o Apache:
[root@server01 ~]# yum install httpd
A saída mostrará o pacote que está sendo baixado e pedirá permissão para instalar:
Dependências resolvidas ============================================================================================================================================================================== Package Arq. Versão Repo Tam. ============================================================================================================================================================================== Instalando: httpd x86_64 2.4.6-89.el7.centos updates 2.7 M Atualizando para as dependências: httpd-tools x86_64 2.4.6-89.el7.centos updates 90 k Resumo da transação ============================================================================================================================================================================== Instalar 1 Package Upgrade ( 1 Dependent package) Tamanho total do download: 2.8 M Is this ok [y/d/N]: y Downloading packages: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. (1/2): httpd-tools-2.4.6-89.el7.centos.x86_64.rpm | 90 kB 00:00:00 (2/2): httpd-2.4.6-89.el7.centos.x86_64.rpm | 2.7 MB 00:00:00 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Total 5.5 MB/s | 2.8 MB 00:00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Atualizando : httpd-tools-2.4.6-89.el7.centos.x86_64 1/3 Instalando : httpd-2.4.6-89.el7.centos.x86_64 2/3 Limpeza : httpd-tools-2.4.6-88.el7.centos.x86_64 3/3 Verifying : httpd-tools-2.4.6-89.el7.centos.x86_64 1/3 Verifying : httpd-2.4.6-89.el7.centos.x86_64 2/3 Verifying : httpd-tools-2.4.6-88.el7.centos.x86_64 3/3 Instalados: httpd.x86_64 0:2.4.6-89.el7.centos Dependência(s) atualizada(s): httpd-tools.x86_64 0:2.4.6-89.el7.centos Concluído!
Inicie o daemon manualmente e deixe configurado para iniciarlizar juntamento com o SO:
[root@server01 ~]# systemctl start httpd [root@server01 ~]# systemctl enable httpd Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
A execução do systemctl status httpd.service o comando mostrará que o serviço está agora em execução:
[root@server01 ~]# systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Active: active (running) since Sex 2019-05-17 16:15:38 -03; 1min 13s ago
Docs: man:httpd(8)
man:apachectl(8)
Main PID: 4090 (httpd)
Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec"
CGroup: /system.slice/httpd.service
├─4090 /usr/sbin/httpd -DFOREGROUND
├─4091 /usr/sbin/httpd -DFOREGROUND
├─4092 /usr/sbin/httpd -DFOREGROUND
├─4093 /usr/sbin/httpd -DFOREGROUND
├─4094 /usr/sbin/httpd -DFOREGROUND
└─4095 /usr/sbin/httpd -DFOREGROUND
Mai 17 16:15:37 server01.fedorabr.lab systemd[1]: Starting The Apache HTTP Server...
Mai 17 16:15:38 server01.fedorabr.lab systemd[1]: Started The Apache HTTP Server.
...
…
Em seguida, instalaremos o vsftp:
[root@server01 ~]# yum install -y vsftpd
A saída deve ser semelhante ao seguinte:
Plugins carregados: fastestmirror Loading mirror speeds from cached hostfile * base: centos.ufes.br * extras: centos.ufes.br * updates: centos.ufes.br Resolvendo dependências --> Executando verificação da transação ---> O pacote vsftpd.x86_64 0:3.0.2-25.el7 será instalado --> Resolução de dependências finalizada Dependências resolvidas ============================================================================================================================================================================== Package Arq. Versão Repo Tam. ============================================================================================================================================================================== Instalando: vsftpd x86_64 3.0.2-25.el7 base 171 k Resumo da transação ============================================================================================================================================================================== Instalar 1 Package Tamanho total do download: 171 k Tamanho depois de instalado: 353 k Downloading packages: vsftpd-3.0.2-25.el7.x86_64.rpm | 171 kB 00:00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Instalando : vsftpd-3.0.2-25.el7.x86_64 1/1 Verifying : vsftpd-3.0.2-25.el7.x86_64 1/1 Instalados: vsftpd.x86_64 0:3.0.2-25.el7 Concluído!
Em seguida, usaremos o systemctl start vsftpd.service para iniciar o daemon vsftpd e enable para habilitar na inicialização do SO. A saída deve mostrar algo como o seguinte:
[root@server01 ~]# systemctl start vsftpd.service
[root@server01 ~]# systemctl enable vsftpd.service Created symlink from /etc/systemd/system/multi-user.target.wants/vsftpd.service to /usr/lib/systemd/system/vsftpd.service.
[root@server01 ~]# systemctl status vsftpd.service
● vsftpd.service - Vsftpd ftp daemon
Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; disabled; vendor preset: disabled)
Active: active (running) since Sex 2019-05-17 16:21:11 -03; 5s ago
Process: 4153 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exited, status=0/SUCCESS)
Main PID: 4154 (vsftpd)
CGroup: /system.slice/vsftpd.service
└─4154 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
Mai 17 16:21:11 server01.fedorabr.lab systemd[1]: Starting Vsftpd ftp daemon...
Mai 17 16:21:11 server01.fedorabr.lab systemd[1]: Started Vsftpd ftp daemon.
Instalando Pacotes SELinux
Vários pacotes são usados no SELinux. Alguns são instalados por padrão. Aqui está uma lista de distribuições baseadas no Red Hat:
policycoreutils (fornece utilitários para gerenciar o SELinux)
policycoreutils-python (fornece utilitários para gerenciar o SELinux)
selinux-policy (fornece a política de referência do SELinux)
selinux-policy-targeted (fornece diretiva segmentada do SELinux)
libselinux-utils (fornece algumas ferramentas para gerenciar o SELinux)
setroubleshoot-server (fornece ferramentas para decifrar mensagens de log de auditoria)
setools (fornece ferramentas para monitoramento de log de auditoria, política de consulta e gerenciamento de contexto de arquivo)
setools-console (fornece ferramentas para monitoramento de log de auditoria, política de consulta e gerenciamento de contexto de arquivo)
mcstrans (ferramentas para traduzir diferentes níveis para um formato fácil de entender)
Alguns deles já estão instalados. Para verificar quais pacotes do SELinux estão instalados no seu sistema CentOS 7, você pode executar alguns comandos como o abaixo (com diferentes termos de pesquisa após grep) como o usuário root:
[root@server01 ~]# rpm -qa | grep selinux
A saída deve ser algo como isto:
selinux-policy-targeted-3.13.1-229.el7_6.9.noarch libselinux-python-2.5-14.1.el7.x86_64 libselinux-utils-2.5-14.1.el7.x86_64 libselinux-2.5-14.1.el7.x86_64 selinux-policy-3.13.1-229.el7_6.9.noarch
Você pode ir em frente e instalar todos os pacotes com o comando abaixo (yum apenas atualizará qualquer um que você já tenha), ou apenas aqueles que você achar que faltam no seu sistema:
yum install policycoreutils policycoreutils-python selinux-policy selinux-policy-targeted libselinux-utils setroubleshoot-server setools setools-console mcstrans
Agora devemos ter um sistema carregado com todos os pacotes do SELinux. Também temos servidores Apache e SFTP em execução com suas configurações padrão. Também temos quatro contas de usuário regulares prontas para serem testadas, além da conta raiz .
Modos SELinux
É hora de começar a brincar com o SELinux, então vamos começar com os modos SELinux. A qualquer momento, o SELinux pode estar em qualquer um dos três modos possíveis:
- Enforcing
- Permissive
- Disabled
No modo enforcing, o SELinux reforçará sua política no sistema Linux e garantirá que todas as tentativas de acesso não autorizadas por usuários e processos sejam negadas. As negações de acesso também são gravadas em arquivos de log relevantes. Nós falaremos sobre as políticas do SELinux e os registros de auditoria mais tarde.
O modo permissive é como um estado semi-ativado. O SELinux não aplica sua política no modo permissivo, portanto, nenhum acesso é negado. No entanto, qualquer violação de política ainda é registrada nos logs de auditoria. É uma ótima maneira de testar o SELinux antes de aplicá-lo.
O modo disabled é auto-explicativo - o sistema não será executado com segurança aprimorada.
Verificando os modos e status do SELinux
Podemos executar o getenforce comando para verificar o atual modo SELinux.
[root@server01 ~]# getenforce
O SELinux deve estar atualmente no modo inforcing, então a saída ficará assim:
enforcing
Nós também podemos executar o sestatus comando:
[root@server01 ~]# sestatus
Quando o SELinux está habilitado, a saída mostrará:
SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 31
Arquivo de Configuração do SELinux
O arquivo de configuração principal do SELinux é o /etc/selinux/config. Podemos executar o seguinte comando para visualizar seu conteúdo:
[root@server01 ~]# cat /etc/selinux/config
A saída será algo como isto:
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of three values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted
Existem duas diretivas neste arquivo. A diretiva SELINUX dita o modo SELinux e pode ter três valores possíveis como discutimos anteriormente.
A diretiva SELINUXTYPE determina a diretiva que será usada. O valor padrão é targeted. Com uma política direcionada, o SELinux permite personalizar e ajustar as permissões de controle de acesso. O outro valor possível é "MLS" (segurança multinível), um modo avançado de proteção. Também com o MLS, você precisa instalar um pacote adicional.
Ativando e Desativando o SELinux
Ativar o SELinux é bastante simples; mas, ao contrário de desativá-lo, deve ser feito em um processo de duas etapas. Assumimos que o SELinux está atualmente desativado e que você instalou todos os pacotes do SELinux da seção anterior.
Como primeiro passo, precisamos editar o /etc/selinux/config arquivo para alterar a diretiva SELINUX para o modo permissivo.
[root@server01 ~]# vim /etc/sysconfig/selinux
... SELINUX=permissive ...
Definir o status como permissivo primeiro é necessário porque cada arquivo no sistema precisa ter seu contexto rotulado antes que o SELinux possa ser aplicado. A menos que todos os arquivos sejam adequadamente rotulados, os processos em execução em domínios confinados podem falhar porque não podem acessar arquivos com os contextos corretos. Isso pode fazer com que o processo de inicialização falhe ou inicie com erros. Introduziremos contextos e domínios mais adiante no tutorial.
Agora, emita uma reinicialização do sistema:
[root@server01 ~]# reboot
O processo de reinicialização verá todos os arquivos no servidor rotulados com um contexto SELinux. Como o sistema está sendo executado no modo permissivo, os erros do SELinux e as negações de acesso serão reportados, mas não parará nada.
Faça o login no seu servidor novamente como root . Em seguida, procure a string "SELinux está impedindo" do conteúdo do arquivo /var/log/messages.
[root@server01 ~]# cat /var/log/messages | grep "SELinux is preventing"
Se não houver erros relatados, podemos passar com segurança para a próxima etapa. No entanto, ainda seria uma boa idéia procurar texto contendo "SELinux" no arquivo /var/log/messages. Em nosso sistema, nós executamos o seguinte comando:
[root@server01 ~]# cat /var/log/messages | grep "SELinux"
Isso mostrou algumas mensagens relacionadas ao Kernel:
May 17 16:02:58 server01 kernel: SELinux: Initializing. May 17 16:03:02 server01 kernel: SELinux: Class bpf not defined in policy. May 17 16:03:02 server01 kernel: SELinux: the above unknown classes and permissions will be allowed May 17 16:03:02 server01 systemd[1]: Successfully loaded SELinux policy in 167.634ms. May 17 16:26:56 server01 kernel: SELinux: Class bpf not defined in policy. May 17 16:26:56 server01 kernel: SELinux: the above unknown classes and permissions will be allowed
Na segunda fase, precisamos editar o arquivo de configuração para alterar a directiva SELINUX para inforcing para aplicação no arquivo /etc/sysconfig/selinux:
... SELINUX=enforcing …
Em seguida, reinicie o servidor novamente.
[root@server01 ~]# reboot
Quando o servidor estiver on-line novamente, podemos executar o comando sestatus para verificar o status do SELinux. Agora deve mostrar mais detalhes sobre o servidor:
SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: error (Success) Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 31
Verificando os modos e status do SELinux (novamente)
Podemos executar o comando getenforce para verificar o atual modo SELinux.
[root@server01 ~]# getenforce
Se o nosso sistema estiver executando no modo enforcing, a saída ficará assim:
Enforcing
A saída será diferente se o SELinux estiver desativado:
Disabled
Podemos também executar o comando sestatus para obter uma imagem melhor.
[root@server01 ~]# sestatus
Se o SELinux não estiver desativado, a saída mostrará seu status atual, seu modo atual, o modo definido no arquivo de configuração e o tipo de política.
SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 28
Quando o SELinux está desativado, a saída mostrará:
SELinux status: disabled
Também podemos alternar temporariamente entre os modos enforcing e permissive usando o comando setenforce. (Note que não podemos correr setenforce quando o SELinux está desativado.)
Primeiro mude o modo SELinux para permissivo em nosso sistema CentOS 7:
setenforce permissive
A execução do comando sestatus agora mostra que o modo atual é diferente do modo definido no arquivo de configuração:
SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 31
Volte a aplicar :
setenforce enforcing
Política de SELinux
No coração do mecanismo de segurança do SELinux está sua política . Uma política é o que o nome implica: um conjunto de regras que definem os direitos de segurança e acesso para tudo no sistema. E quando dizemos tudo , queremos dizer usuários, funções, processos e arquivos. A política define como cada uma dessas entidades está relacionada entre si.
Alguma terminologia básica
Para entender a política, temos que aprender alguma terminologia básica. Nós entraremos nos detalhes mais tarde, mas aqui está uma breve introdução. Uma política do SELinux define o acesso do usuário a funções, acesso a funções a domínios e acesso ao domínio a tipos.
**Users **
O SELinux tem um conjunto de usuários pré-construídos. Toda conta de usuário regular do Linux é mapeada para um ou mais usuários do SELinux.
No Linux, um usuário executa um processo. Isso pode ser tão simples quanto o usuário chico abrindo um documento no editor vi (será a conta de chico executando o processo vi) ou uma conta de serviço executando o daemon httpd. No mundo do SELinux, um processo (um daemon ou um programa em execução) é chamado de subject.
Roles
Uma função é como um gateway que fica entre um usuário e um processo. Uma função define quais usuários podem acessar esse processo. As funções não são como grupos, mas mais como filtros: um usuário pode entrar ou assumir uma função a qualquer momento, desde que a função conceda isso. A definição de uma função na política do SELinux define quais usuários têm acesso a essa função. Também define a quais domínios de processo a função em si tem acesso. As funções entram em ação porque parte do SELinux implementa o que é conhecido como RBAC ( Role Based Access Control ).
Subjects e Objects
Um assunto é um processo e pode potencialmente afetar um objeto .
Um objeto no SELinux é qualquer coisa que possa ser usada. Isso pode ser um arquivo, um diretório, uma porta, um soquete TCP, o cursor ou talvez um servidor X. As ações que um sujeito pode executar em um objeto são as permissões do sujeito .
Domains para Subjects
Um domínio é o contexto dentro do qual um sujeito (processo) do SELinux pode ser executado. Esse contexto é como um invólucro em torno do assunto. Diz ao processo o que pode e não pode fazer. Por exemplo, o domínio definirá quais arquivos, diretórios, links, dispositivos ou portas estão acessíveis ao assunto.
Types para Objects
Um tipo é o contexto para o contexto de um arquivo que estipula o propósito do arquivo. Por exemplo, o contexto de um arquivo pode ditar que é uma página da Web ou que o arquivo pertence ao diretório /etc ou que o proprietário do arquivo é um usuário específico do SELinux. O contexto de um arquivo é chamado seu tipo na linguagem do SELinux.
Então, qual é a política do SELinux?
A política do SELinux define o acesso do usuário a funções, acesso a funções a domínios e acesso ao domínio a tipos. Primeiro, o usuário precisa estar autorizado a entrar em uma função e, em seguida, a função precisa ser autorizada para acessar o domínio. O domínio, por sua vez, é restrito para acessar apenas determinados tipos de arquivos.
A política em si é um monte de regras que dizem que os possíveis usuários podem assumir apenas funções de fulano, e essas funções serão autorizadas a acessar apenas domínios fulanos. Os domínios, por sua vez, podem acessar apenas os tipos de arquivos do tipo "so-and-so".
Dica de terminologia: O último bit, em que um processo em execução em um determinado domínio pode executar apenas determinadas operações em determinados tipos de objetos, é chamado de aplicação de tipo (TE).
Voltando ao tópico das políticas, as implementações de políticas do SELinux também são geralmente segmentadas por padrão. Se você se lembrar do arquivo de configuração do SELinux que vimos antes, a diretiva SELINUXTYPE está configurada para ser targeted. O que isto significa é que, por padrão, o SELinux irá restringir apenas certos processos no sistema (ou seja, apenas determinados processos são direcionados). Os que não são segmentados serão executados em domínios não delimitados.
A alternativa é um modelo de negação por padrão, em que todo acesso é negado, a menos que seja aprovado pela política. Seria uma implementação muito segura, mas isso também significa que os desenvolvedores precisam antecipar cada permissão possível que cada processo pode precisar em cada objeto possível. O comportamento padrão vê o SELinux preocupado apenas com determinados processos.
Comportamento da Política do SELinux
A política do SELinux não é algo que substitua a segurança tradicional do DAC. Se uma regra do DAC proibir o acesso de um usuário a um arquivo, as regras de política do SELinux não serão avaliadas porque a primeira linha de defesa já bloqueou o acesso. As decisões de segurança do SELinux entram em ação após a segurança do DAC ter sido avaliada.
Quando um sistema habilitado para o SELinux é iniciado, a política é carregada na memória. A política do SELinux vem em formato modular, muito parecida com os módulos do kernel carregados no momento da inicialização. E assim como os módulos do kernel, eles podem ser adicionados dinamicamente e removidos da memória no tempo de execução. O repositório de políticas usado pelo SELinux rastreia os módulos que foram carregados. O comando sestatus mostra o nome do armazenamento de políticas. O comando semodule -l lista os módulos de política do SELinux atualmente carregados na memória.
Para ter uma ideia disso, vamos executar o comando semodule:
[root@server01 ~]# semodule -l | less
A saída será algo como isto:
aiccu 1.1.0 aide 1.7.1 ajaxterm 1.0.0 alsa 1.12.2 amanda 1.15.0 amtu 1.3.0 anaconda 1.7.0 antivirus 1.0.0 apache 2.7.2 apcupsd 1.9.0 apm 1.12.0 application 1.2.0 arpwatch 1.11.0 asterisk 1.12.1 auditadm 2.2.0 authconfig 1.0.0 authlogin 2.5.1 automount 1.14.1 avahi 1.14.1 awstats 1.5.0 bacula 1.2.0 base (null) ... ...
semodule pode ser usado para várias outras tarefas, como instalar, remover, recarregar, atualizar, ativar e desativar módulos de política do SELinux.
Até agora você provavelmente estaria interessado em saber onde os arquivos do módulo estão localizados. A maioria das distribuições modernas inclui versões binárias dos módulos como parte dos pacotes do SELinux. Os arquivos de políticas possuem uma extensão .pp. Para o CentOS 7, podemos executar o seguinte comando:
[root@server01 ~]# ls -l /etc/selinux/targeted/modules/active/modules/
A listagem mostra vários arquivos com a extensão .pp. Se você olhar de perto, eles estarão relacionados a diferentes aplicativos:
... -rw-r--r--. 1 root root 10692 Aug 20 11:41 anaconda.pp -rw-r--r--. 1 root root 11680 Aug 20 11:41 antivirus.pp -rw-r--r--. 1 root root 24190 Aug 20 11:41 apache.pp -rw-r--r--. 1 root root 11043 Aug 20 11:41 apcupsd.pp ...
Os aruivos .pp não são legíveis por humanos.
A maneira como a modularização do SELinux funciona é que, quando o sistema inicializa, os módulos de política são combinados no que é conhecido como política ativa . Esta política é então carregada na memória. A versão binária combinada dessa política carregada pode ser encontrada no diretório /etc/selinux/targeted/policy.
[root@server01 ~]# ls -l /etc/selinux/targeted/policy/
mostrará a política ativa.
total 3768 -rw-r--r--. 1 root root 3857954 Mai 17 16:26 policy.31
Alterando as configurações booleanas do SELinux
Embora você não possa ler os arquivos do módulo de política, há uma maneira simples de ajustar suas configurações. Isso é feito através do SELinux booleans .
Para ver como funciona, vamos executar o comando semanage boolean -l.
[root@server01 ~]# semanage boolean -l | less
Isso mostra os diferentes switches que podem ser ativados ou desativados, o que eles fazem e seus status atuais:
ftpd_use_cifs (desativado,desativado) Allow ftpd to use cifs privoxy_connect_any (ativado,ativado) Allow privoxy to connect any smartmon_3ware (desativado,desativado) Allow smartmon to 3ware mpd_enable_homedirs (desativado,desativado) Allow mpd to enable homedirs xdm_sysadm_login (desativado,desativado) Allow xdm to sysadm login xen_use_nfs (desativado,desativado) Allow xen to use nfs mozilla_read_content (desativado,desativado) Allow mozilla to read content ssh_chroot_rw_homedirs (desativado,desativado) Allow ssh to chroot rw homedirs mount_anyfile (ativado,ativado) Allow mount to anyfile cron_userdomain_transition (ativado,ativado) Allow cron to userdomain transition xdm_write_home (desativado,desativado) Allow xdm to write home openvpn_can_network_connect (ativado,ativado) Allow openvpn to can network connect xserver_execmem (desativado,desativado) Allow xserver to execmem minidlna_read_generic_user_content (desativado,desativado) Allow minidlna to read generic user content authlogin_nsswitch_use_ldap (desativado,desativado) Allow authlogin to nsswitch use ldap gluster_anon_write (desativado,desativado) Allow gluster to anon write piranha_lvs_can_network_connect (desativado,desativado) Allow piranha to lvs can network connect ... ...
Podemos ver que a primeira opção permite que o daemon FTP acesse os diretórios iniciais dos usuários. A configuração está desativada no momento.
Para alterar qualquer uma das configurações, podemos usar o comando setsebool. Como exemplo, vamos considerar o acesso de gravação FTP anônimo:
[root@server01 ~]# getsebool ftpd_anon_write
Isso nos mostra que o interruptor está desligado no momento:
ftpd_anon_write --> off
Em seguida, alteramos o booleano para ativá-lo:
[root@server01 ~]# getsebool ftpd_anon_write on
Verificar o valor novamente deve mostrar a alteração:
ftpd_anon_write --> on
Booleanos alterados não são permanentes. Eles revertem para seus valores antigos após uma reinicialização. Para tornar as coisas permanentes, podemos usar o comutador -P com o comando setsebool.
Conclusão
Na primeira parte deste tutorial, tentamos entender alguns conceitos básicos sobre o SELinux. Vimos como o SELinux pode proteger um sistema, como podemos ativá-lo e em que modos ele pode ser executado. Também abordamos o tópico da política do SELinux. Em seguida, aprenderemos como usar o SELinux para restringir o acesso a arquivos e processos .
Até a próxima
Fim da primeira parte...
Link para a parte 2: Introdução ao SELinux: Arquivos e Processos
Comentários
-
Ficou excelente Chico, deu p/ entender legal.
Vlw pela documentação e parabéns.0 -
Muito bom Parabéns , SELinux não é um bicho de 7 cabeças
0 -
Digite seu comentário> @ChicoFedora disse:
Introdução
**Security Enhanced Linux **ou SELinux é um mecanismo avançado de controle de acesso integrado na maioria das distribuições Linux modernas. Foi desenvolvido inicialmente pela Agência de Segurança Nacional dos EUA para proteger os sistemas de computador contra invasões e adulterações maliciosas. Com o tempo, o SELinux foi lançado em domínio público e várias distribuições o incorporaram em seu código.
Muitos administradores de sistemas consideram o SELinux um território um pouco desconhecido. O tópico pode parecer assustador e às vezes bastante confuso. No entanto, um sistema SELinux configurado corretamente pode reduzir muito os riscos de segurança, e saber um pouco sobre isso pode ajudá-lo a solucionar mensagens de erro relacionadas ao acesso. Neste tutorial vamos aprender sobre os conceitos por trás do SELinux - seus pacotes, comandos e arquivos de configuração - e as mensagens de erro que ele registra quando o acesso é negado. Também veremos alguns exemplos práticos de colocar o SELinux em ação.
Ambiente:
Para este laboratório foi utilizado 1 host, denominado de server01, com utilização do Apache para as devidas liberações.Descrição dos servidores:
Server01:
Sistema Operacional : CentOS 7
Hostname : server01.fedorabr.lab
IP : 192.168.122.150/24Neste tutorial, estaremos executando os comandos como o usuário root, a menos que seja indicado o contrário. Se você não tiver acesso à conta root e usar outra conta com privilégios sudo, precisará preceder os comandos com “sudo -” digitando seu password.
Por que o SELinux
Antes de começarmos, vamos entender alguns conceitos.
O SELinux implementa o que é conhecido como MAC (Mandatory Access Control / Controle de Acesso Obrigatório). Isto é implementado em cima do que já está presente em todas as distribuições Linux, o DAC (Discretionary Access Contro / Controle de Acesso Discricionáriol).
Para entender o DAC, vamos primeiro considerar como a segurança tradicional de arquivos do Linux funciona.
Em um modelo de segurança tradicional, temos três entidades: Usuário, Grupo e Outros (u, g, o) que podem ter uma combinação de permissões de Leitura, Gravação e Execução (r,w,x) em um arquivo ou diretório. Se o usuário “chico” criar um arquivo em seu diretório pessoal, esse usuário terá acesso de leitura/gravação a ele e, assim, o grupo “chico”. Uma "outra" entidade possivelmente não terá acesso a ela. No bloco de código a seguir, podemos considerar o conteúdo hipotético do diretório inicial de “chico”.
Você não precisa configurar este usuário “chico” - nós estaremos configurando muitos usuários mais tarde no tutorial.
Executando um comando como este:
[root@server01 ~]# ls -l /home/chico/
pode mostrar a saída como o seguinte:
total 0 -rw-r--r--. 1 root root 0 Mai 3 13:06 arquivo
Agora jo pode alterar esse acesso. chico pode conceder (e restringir) o acesso a este arquivo para outros usuários e grupos ou alterar o proprietário do arquivo. Essas ações podem deixar arquivos críticos expostos a contas que não precisam desse acesso. chico também pode restringir para ser mais seguro, mas isso é discricionário: não há como o administrador do sistema aplicá-lo a cada arquivo no sistema.
Considere outro caso: quando um processo Linux é executado, ele pode ser executado como o usuário root ou outra conta com privilégios de superusuário. Isso significa que se um hacker toma o controle do aplicativo, ele pode usar esse aplicativo para obter acesso a qualquer recurso que a conta do usuário tenha acesso. Para processos em execução como usuário root, basicamente isso significa acesso a tudo no servidor Linux.
Pense em um cenário em que você deseja impedir que os usuários executem scripts de shell de seus diretórios iniciais. Isso pode acontecer quando você tem desenvolvedores trabalhando em um sistema de produção. Você gostaria que eles visualizassem arquivos de log, mas você não quer que eles usem su ou sudo para comandos, e você não quer que eles executem quaisquer scripts de seus diretórios pessoais. Como você faz isso?
O SELinux é uma maneira de ajustar esses requisitos de controle de acesso. Com o SELinux, você pode definir o que um usuário ou processo pode fazer. Ele confina cada processo a seu próprio domínio para que o processo possa interagir apenas com determinados tipos de arquivos e outros processos dos domínios permitidos. Isso impede que um hacker sequestre qualquer processo para obter acesso ao sistema.
Configurando um sistema de teste
Para nos ajudar a aprender os conceitos, construiremos um servidor de teste executando tanto um servidor web quanto um servidor SFTP. Vamos começar com uma instalação simples do CentOS 7 com o mínimo de pacotes instalados e instalar os daemons Apache e vsftp nesse servidor. No entanto, não iremos configurar nenhum desses aplicativos.
Também criaremos algumas contas de usuário de teste no nosso servidor. Usaremos essas contas em lugares diferentes ao longo do tutorial.
Finalmente, instalaremos os pacotes relacionados ao SELinux necessários. Isso é para garantir que possamos trabalhar com os comandos mais recentes do SELinux.
Instalando os serviços Apache e SFTP
Primeiro, vamos efetuar login no servidor como usuário root e executar o seguinte comando para instalar o Apache:
[root@server01 ~]# yum install httpd
A saída mostrará o pacote que está sendo baixado e pedirá permissão para instalar:
Dependências resolvidas ============================================================================================================================================================================== Package Arq. Versão Repo Tam. ============================================================================================================================================================================== Instalando: httpd x86_64 2.4.6-89.el7.centos updates 2.7 M Atualizando para as dependências: httpd-tools x86_64 2.4.6-89.el7.centos updates 90 k Resumo da transação ============================================================================================================================================================================== Instalar 1 Package Upgrade ( 1 Dependent package) Tamanho total do download: 2.8 M Is this ok [y/d/N]: y Downloading packages: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. (1/2): httpd-tools-2.4.6-89.el7.centos.x86_64.rpm | 90 kB 00:00:00 (2/2): httpd-2.4.6-89.el7.centos.x86_64.rpm | 2.7 MB 00:00:00 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Total 5.5 MB/s | 2.8 MB 00:00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Atualizando : httpd-tools-2.4.6-89.el7.centos.x86_64 1/3 Instalando : httpd-2.4.6-89.el7.centos.x86_64 2/3 Limpeza : httpd-tools-2.4.6-88.el7.centos.x86_64 3/3 Verifying : httpd-tools-2.4.6-89.el7.centos.x86_64 1/3 Verifying : httpd-2.4.6-89.el7.centos.x86_64 2/3 Verifying : httpd-tools-2.4.6-88.el7.centos.x86_64 3/3 Instalados: httpd.x86_64 0:2.4.6-89.el7.centos Dependência(s) atualizada(s): httpd-tools.x86_64 0:2.4.6-89.el7.centos Concluído!
Inicie o daemon manualmente e deixe configurado para iniciarlizar juntamento com o SO:
[root@server01 ~]# systemctl start httpd [root@server01 ~]# systemctl enable httpd Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
A execução do systemctl status httpd.service o comando mostrará que o serviço está agora em execução:
[root@server01 ~]# systemctl status httpd ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Active: active (running) since Sex 2019-05-17 16:15:38 -03; 1min 13s ago Docs: man:httpd(8) man:apachectl(8) Main PID: 4090 (httpd) Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec" CGroup: /system.slice/httpd.service ├─4090 /usr/sbin/httpd -DFOREGROUND ├─4091 /usr/sbin/httpd -DFOREGROUND ├─4092 /usr/sbin/httpd -DFOREGROUND ├─4093 /usr/sbin/httpd -DFOREGROUND ├─4094 /usr/sbin/httpd -DFOREGROUND └─4095 /usr/sbin/httpd -DFOREGROUND Mai 17 16:15:37 server01.fedorabr.lab systemd[1]: Starting The Apache HTTP Server... Mai 17 16:15:38 server01.fedorabr.lab systemd[1]: Started The Apache HTTP Server. ... …Em seguida, instalaremos o vsftp:
[root@server01 ~]# yum install -y vsftpd
A saída deve ser semelhante ao seguinte:
Plugins carregados: fastestmirror Loading mirror speeds from cached hostfile * base: centos.ufes.br * extras: centos.ufes.br * updates: centos.ufes.br Resolvendo dependências --> Executando verificação da transação ---> O pacote vsftpd.x86_64 0:3.0.2-25.el7 será instalado --> Resolução de dependências finalizada Dependências resolvidas ============================================================================================================================================================================== Package Arq. Versão Repo Tam. ============================================================================================================================================================================== Instalando: vsftpd x86_64 3.0.2-25.el7 base 171 k Resumo da transação ============================================================================================================================================================================== Instalar 1 Package Tamanho total do download: 171 k Tamanho depois de instalado: 353 k Downloading packages: vsftpd-3.0.2-25.el7.x86_64.rpm | 171 kB 00:00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Instalando : vsftpd-3.0.2-25.el7.x86_64 1/1 Verifying : vsftpd-3.0.2-25.el7.x86_64 1/1 Instalados: vsftpd.x86_64 0:3.0.2-25.el7 Concluído!
Em seguida, usaremos o systemctl start vsftpd.service para iniciar o daemon vsftpd e enable para habilitar na inicialização do SO. A saída deve mostrar algo como o seguinte:
[root@server01 ~]# systemctl start vsftpd.service
[root@server01 ~]# systemctl enable vsftpd.service Created symlink from /etc/systemd/system/multi-user.target.wants/vsftpd.service to /usr/lib/systemd/system/vsftpd.service.
[root@server01 ~]# systemctl status vsftpd.service ● vsftpd.service - Vsftpd ftp daemon Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; disabled; vendor preset: disabled) Active: active (running) since Sex 2019-05-17 16:21:11 -03; 5s ago Process: 4153 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exited, status=0/SUCCESS) Main PID: 4154 (vsftpd) CGroup: /system.slice/vsftpd.service └─4154 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf Mai 17 16:21:11 server01.fedorabr.lab systemd[1]: Starting Vsftpd ftp daemon... Mai 17 16:21:11 server01.fedorabr.lab systemd[1]: Started Vsftpd ftp daemon.Instalando Pacotes SELinux
Vários pacotes são usados no SELinux. Alguns são instalados por padrão. Aqui está uma lista de distribuições baseadas no Red Hat:
policycoreutils (fornece utilitários para gerenciar o SELinux)
policycoreutils-python (fornece utilitários para gerenciar o SELinux)
selinux-policy (fornece a política de referência do SELinux)
selinux-policy-targeted (fornece diretiva segmentada do SELinux)
libselinux-utils (fornece algumas ferramentas para gerenciar o SELinux)
setroubleshoot-server (fornece ferramentas para decifrar mensagens de log de auditoria)
setools (fornece ferramentas para monitoramento de log de auditoria, política de consulta e gerenciamento de contexto de arquivo)
setools-console (fornece ferramentas para monitoramento de log de auditoria, política de consulta e gerenciamento de contexto de arquivo)
mcstrans (ferramentas para traduzir diferentes níveis para um formato fácil de entender)
Alguns deles já estão instalados. Para verificar quais pacotes do SELinux estão instalados no seu sistema CentOS 7, você pode executar alguns comandos como o abaixo (com diferentes termos de pesquisa após grep) como o usuário root:
[root@server01 ~]# rpm -qa | grep selinux
A saída deve ser algo como isto:
selinux-policy-targeted-3.13.1-229.el7_6.9.noarch libselinux-python-2.5-14.1.el7.x86_64 libselinux-utils-2.5-14.1.el7.x86_64 libselinux-2.5-14.1.el7.x86_64 selinux-policy-3.13.1-229.el7_6.9.noarch
Você pode ir em frente e instalar todos os pacotes com o comando abaixo (yum apenas atualizará qualquer um que você já tenha), ou apenas aqueles que você achar que faltam no seu sistema:
yum install policycoreutils policycoreutils-python selinux-policy selinux-policy-targeted libselinux-utils setroubleshoot-server setools setools-console mcstrans
Agora devemos ter um sistema carregado com todos os pacotes do SELinux. Também temos servidores Apache e SFTP em execução com suas configurações padrão. Também temos quatro contas de usuário regulares prontas para serem testadas, além da conta raiz .
Modos SELinux
É hora de começar a brincar com o SELinux, então vamos começar com os modos SELinux. A qualquer momento, o SELinux pode estar em qualquer um dos três modos possíveis:
- Enforcing
- Permissive
- Disabled
No modo enforcing, o SELinux reforçará sua política no sistema Linux e garantirá que todas as tentativas de acesso não autorizadas por usuários e processos sejam negadas. As negações de acesso também são gravadas em arquivos de log relevantes. Nós falaremos sobre as políticas do SELinux e os registros de auditoria mais tarde.
O modo permissive é como um estado semi-ativado. O SELinux não aplica sua política no modo permissivo, portanto, nenhum acesso é negado. No entanto, qualquer violação de política ainda é registrada nos logs de auditoria. É uma ótima maneira de testar o SELinux antes de aplicá-lo.
O modo disabled é auto-explicativo - o sistema não será executado com segurança aprimorada.
Verificando os modos e status do SELinux
Podemos executar o getenforce comando para verificar o atual modo SELinux.
[root@server01 ~]# getenforce
O SELinux deve estar atualmente no modo inforcing, então a saída ficará assim:
enforcing
Nós também podemos executar o sestatus comando:
[root@server01 ~]# sestatus
Quando o SELinux está habilitado, a saída mostrará:
SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 31
Arquivo de Configuração do SELinux
O arquivo de configuração principal do SELinux é o /etc/selinux/config. Podemos executar o seguinte comando para visualizar seu conteúdo:
[root@server01 ~]# cat /etc/selinux/config
A saída será algo como isto:
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of three values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted
Existem duas diretivas neste arquivo. A diretiva SELINUX dita o modo SELinux e pode ter três valores possíveis como discutimos anteriormente.
A diretiva SELINUXTYPE determina a diretiva que será usada. O valor padrão é targeted. Com uma política direcionada, o SELinux permite personalizar e ajustar as permissões de controle de acesso. O outro valor possível é "MLS" (segurança multinível), um modo avançado de proteção. Também com o MLS, você precisa instalar um pacote adicional.
Ativando e Desativando o SELinux
Ativar o SELinux é bastante simples; mas, ao contrário de desativá-lo, deve ser feito em um processo de duas etapas. Assumimos que o SELinux está atualmente desativado e que você instalou todos os pacotes do SELinux da seção anterior.
Como primeiro passo, precisamos editar o /etc/selinux/config arquivo para alterar a diretiva SELINUX para o modo permissivo.
[root@server01 ~]# vim /etc/sysconfig/selinux
... SELINUX=permissive ...
Definir o status como permissivo primeiro é necessário porque cada arquivo no sistema precisa ter seu contexto rotulado antes que o SELinux possa ser aplicado. A menos que todos os arquivos sejam adequadamente rotulados, os processos em execução em domínios confinados podem falhar porque não podem acessar arquivos com os contextos corretos. Isso pode fazer com que o processo de inicialização falhe ou inicie com erros. Introduziremos contextos e domínios mais adiante no tutorial.
Agora, emita uma reinicialização do sistema:
[root@server01 ~]# reboot
O processo de reinicialização verá todos os arquivos no servidor rotulados com um contexto SELinux. Como o sistema está sendo executado no modo permissivo, os erros do SELinux e as negações de acesso serão reportados, mas não parará nada.
Faça o login no seu servidor novamente como root . Em seguida, procure a string "SELinux está impedindo" do conteúdo do arquivo /var/log/messages.
[root@server01 ~]# cat /var/log/messages | grep "SELinux is preventing"
Se não houver erros relatados, podemos passar com segurança para a próxima etapa. No entanto, ainda seria uma boa idéia procurar texto contendo "SELinux" no arquivo /var/log/messages. Em nosso sistema, nós executamos o seguinte comando:
[root@server01 ~]# cat /var/log/messages | grep "SELinux"
Isso mostrou algumas mensagens relacionadas ao Kernel:
May 17 16:02:58 server01 kernel: SELinux: Initializing. May 17 16:03:02 server01 kernel: SELinux: Class bpf not defined in policy. May 17 16:03:02 server01 kernel: SELinux: the above unknown classes and permissions will be allowed May 17 16:03:02 server01 systemd[1]: Successfully loaded SELinux policy in 167.634ms. May 17 16:26:56 server01 kernel: SELinux: Class bpf not defined in policy. May 17 16:26:56 server01 kernel: SELinux: the above unknown classes and permissions will be allowed
Na segunda fase, precisamos editar o arquivo de configuração para alterar a directiva SELINUX para inforcing para aplicação no arquivo /etc/sysconfig/selinux:
... SELINUX=enforcing …
Em seguida, reinicie o servidor novamente.
[root@server01 ~]# reboot
Quando o servidor estiver on-line novamente, podemos executar o comando sestatus para verificar o status do SELinux. Agora deve mostrar mais detalhes sobre o servidor:
SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: error (Success) Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 31
Verificando os modos e status do SELinux (novamente)
Podemos executar o comando getenforce para verificar o atual modo SELinux.
[root@server01 ~]# getenforce
Se o nosso sistema estiver executando no modo enforcing, a saída ficará assim:
Enforcing
A saída será diferente se o SELinux estiver desativado:
Disabled
Podemos também executar o comando sestatus para obter uma imagem melhor.
[root@server01 ~]# sestatus
Se o SELinux não estiver desativado, a saída mostrará seu status atual, seu modo atual, o modo definido no arquivo de configuração e o tipo de política.
SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 28
Quando o SELinux está desativado, a saída mostrará:
SELinux status: disabled
Também podemos alternar temporariamente entre os modos enforcing e permissive usando o comando setenforce. (Note que não podemos correr setenforce quando o SELinux está desativado.)
Primeiro mude o modo SELinux para permissivo em nosso sistema CentOS 7:
setenforce permissive
A execução do comando sestatus agora mostra que o modo atual é diferente do modo definido no arquivo de configuração:
SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 31
Volte a aplicar :
setenforce enforcing
Política de SELinux
No coração do mecanismo de segurança do SELinux está sua política . Uma política é o que o nome implica: um conjunto de regras que definem os direitos de segurança e acesso para tudo no sistema. E quando dizemos tudo , queremos dizer usuários, funções, processos e arquivos. A política define como cada uma dessas entidades está relacionada entre si.
Alguma terminologia básica
Para entender a política, temos que aprender alguma terminologia básica. Nós entraremos nos detalhes mais tarde, mas aqui está uma breve introdução. Uma política do SELinux define o acesso do usuário a funções, acesso a funções a domínios e acesso ao domínio a tipos.
**Users **
O SELinux tem um conjunto de usuários pré-construídos. Toda conta de usuário regular do Linux é mapeada para um ou mais usuários do SELinux.
No Linux, um usuário executa um processo. Isso pode ser tão simples quanto o usuário chico abrindo um documento no editor vi (será a conta de chico executando o processo vi) ou uma conta de serviço executando o daemon httpd. No mundo do SELinux, um processo (um daemon ou um programa em execução) é chamado de subject.Roles
Uma função é como um gateway que fica entre um usuário e um processo. Uma função define quais usuários podem acessar esse processo. As funções não são como grupos, mas mais como filtros: um usuário pode entrar ou assumir uma função a qualquer momento, desde que a função conceda isso. A definição de uma função na política do SELinux define quais usuários têm acesso a essa função. Também define a quais domínios de processo a função em si tem acesso. As funções entram em ação porque parte do SELinux implementa o que é conhecido como RBAC ( Role Based Access Control ).
Subjects e Objects
Um assunto é um processo e pode potencialmente afetar um objeto .
Um objeto no SELinux é qualquer coisa que possa ser usada. Isso pode ser um arquivo, um diretório, uma porta, um soquete TCP, o cursor ou talvez um servidor X. As ações que um sujeito pode executar em um objeto são as permissões do sujeito .Domains para Subjects
Um domínio é o contexto dentro do qual um sujeito (processo) do SELinux pode ser executado. Esse contexto é como um invólucro em torno do assunto. Diz ao processo o que pode e não pode fazer. Por exemplo, o domínio definirá quais arquivos, diretórios, links, dispositivos ou portas estão acessíveis ao assunto.
Types para Objects
Um tipo é o contexto para o contexto de um arquivo que estipula o propósito do arquivo. Por exemplo, o contexto de um arquivo pode ditar que é uma página da Web ou que o arquivo pertence ao diretório /etc ou que o proprietário do arquivo é um usuário específico do SELinux. O contexto de um arquivo é chamado seu tipo na linguagem do SELinux.
Então, qual é a política do SELinux?
A política do SELinux define o acesso do usuário a funções, acesso a funções a domínios e acesso ao domínio a tipos. Primeiro, o usuário precisa estar autorizado a entrar em uma função e, em seguida, a função precisa ser autorizada para acessar o domínio. O domínio, por sua vez, é restrito para acessar apenas determinados tipos de arquivos.
A política em si é um monte de regras que dizem que os possíveis usuários podem assumir apenas funções de fulano, e essas funções serão autorizadas a acessar apenas domínios fulanos. Os domínios, por sua vez, podem acessar apenas os tipos de arquivos do tipo "so-and-so".
Dica de terminologia: O último bit, em que um processo em execução em um determinado domínio pode executar apenas determinadas operações em determinados tipos de objetos, é chamado de aplicação de tipo (TE).
Voltando ao tópico das políticas, as implementações de políticas do SELinux também são geralmente segmentadas por padrão. Se você se lembrar do arquivo de configuração do SELinux que vimos antes, a diretiva SELINUXTYPE está configurada para ser targeted. O que isto significa é que, por padrão, o SELinux irá restringir apenas certos processos no sistema (ou seja, apenas determinados processos são direcionados). Os que não são segmentados serão executados em domínios não delimitados.
A alternativa é um modelo de negação por padrão, em que todo acesso é negado, a menos que seja aprovado pela política. Seria uma implementação muito segura, mas isso também significa que os desenvolvedores precisam antecipar cada permissão possível que cada processo pode precisar em cada objeto possível. O comportamento padrão vê o SELinux preocupado apenas com determinados processos.
Comportamento da Política do SELinux
A política do SELinux não é algo que substitua a segurança tradicional do DAC. Se uma regra do DAC proibir o acesso de um usuário a um arquivo, as regras de política do SELinux não serão avaliadas porque a primeira linha de defesa já bloqueou o acesso. As decisões de segurança do SELinux entram em ação após a segurança do DAC ter sido avaliada.
Quando um sistema habilitado para o SELinux é iniciado, a política é carregada na memória. A política do SELinux vem em formato modular, muito parecida com os módulos do kernel carregados no momento da inicialização. E assim como os módulos do kernel, eles podem ser adicionados dinamicamente e removidos da memória no tempo de execução. O repositório de políticas usado pelo SELinux rastreia os módulos que foram carregados. O comando sestatus mostra o nome do armazenamento de políticas. O comando semodule -l lista os módulos de política do SELinux atualmente carregados na memória.
Para ter uma ideia disso, vamos executar o comando semodule:
[root@server01 ~]# semodule -l | less
A saída será algo como isto:
aiccu 1.1.0 aide 1.7.1 ajaxterm 1.0.0 alsa 1.12.2 amanda 1.15.0 amtu 1.3.0 anaconda 1.7.0 antivirus 1.0.0 apache 2.7.2 apcupsd 1.9.0 apm 1.12.0 application 1.2.0 arpwatch 1.11.0 asterisk 1.12.1 auditadm 2.2.0 authconfig 1.0.0 authlogin 2.5.1 automount 1.14.1 avahi 1.14.1 awstats 1.5.0 bacula 1.2.0 base (null) ... ...
semodule pode ser usado para várias outras tarefas, como instalar, remover, recarregar, atualizar, ativar e desativar módulos de política do SELinux.
Até agora você provavelmente estaria interessado em saber onde os arquivos do módulo estão localizados. A maioria das distribuições modernas inclui versões binárias dos módulos como parte dos pacotes do SELinux. Os arquivos de políticas possuem uma extensão .pp. Para o CentOS 7, podemos executar o seguinte comando:
[root@server01 ~]# ls -l /etc/selinux/targeted/modules/active/modules/
A listagem mostra vários arquivos com a extensão .pp. Se você olhar de perto, eles estarão relacionados a diferentes aplicativos:
... -rw-r--r--. 1 root root 10692 Aug 20 11:41 anaconda.pp -rw-r--r--. 1 root root 11680 Aug 20 11:41 antivirus.pp -rw-r--r--. 1 root root 24190 Aug 20 11:41 apache.pp -rw-r--r--. 1 root root 11043 Aug 20 11:41 apcupsd.pp ...
Os aruivos .pp não são legíveis por humanos.
A maneira como a modularização do SELinux funciona é que, quando o sistema inicializa, os módulos de política são combinados no que é conhecido como política ativa . Esta política é então carregada na memória. A versão binária combinada dessa política carregada pode ser encontrada no diretório /etc/selinux/targeted/policy.
[root@server01 ~]# ls -l /etc/selinux/targeted/policy/
mostrará a política ativa.
total 3768 -rw-r--r--. 1 root root 3857954 Mai 17 16:26 policy.31
Alterando as configurações booleanas do SELinux
Embora você não possa ler os arquivos do módulo de política, há uma maneira simples de ajustar suas configurações. Isso é feito através do SELinux booleans .
Para ver como funciona, vamos executar o comando semanage boolean -l.
[root@server01 ~]# semanage boolean -l | less
Isso mostra os diferentes switches que podem ser ativados ou desativados, o que eles fazem e seus status atuais:
ftpd_use_cifs (desativado,desativado) Allow ftpd to use cifs privoxy_connect_any (ativado,ativado) Allow privoxy to connect any smartmon_3ware (desativado,desativado) Allow smartmon to 3ware mpd_enable_homedirs (desativado,desativado) Allow mpd to enable homedirs xdm_sysadm_login (desativado,desativado) Allow xdm to sysadm login xen_use_nfs (desativado,desativado) Allow xen to use nfs mozilla_read_content (desativado,desativado) Allow mozilla to read content ssh_chroot_rw_homedirs (desativado,desativado) Allow ssh to chroot rw homedirs mount_anyfile (ativado,ativado) Allow mount to anyfile cron_userdomain_transition (ativado,ativado) Allow cron to userdomain transition xdm_write_home (desativado,desativado) Allow xdm to write home openvpn_can_network_connect (ativado,ativado) Allow openvpn to can network connect xserver_execmem (desativado,desativado) Allow xserver to execmem minidlna_read_generic_user_content (desativado,desativado) Allow minidlna to read generic user content authlogin_nsswitch_use_ldap (desativado,desativado) Allow authlogin to nsswitch use ldap gluster_anon_write (desativado,desativado) Allow gluster to anon write piranha_lvs_can_network_connect (desativado,desativado) Allow piranha to lvs can network connect ... ...
Podemos ver que a primeira opção permite que o daemon FTP acesse os diretórios iniciais dos usuários. A configuração está desativada no momento.
Para alterar qualquer uma das configurações, podemos usar o comando setsebool. Como exemplo, vamos considerar o acesso de gravação FTP anônimo:
[root@server01 ~]# getsebool ftpd_anon_write
Isso nos mostra que o interruptor está desligado no momento:
ftpd_anon_write --> off
Em seguida, alteramos o booleano para ativá-lo:
[root@server01 ~]# getsebool ftpd_anon_write on
Verificar o valor novamente deve mostrar a alteração:
ftpd_anon_write --> on
Booleanos alterados não são permanentes. Eles revertem para seus valores antigos após uma reinicialização. Para tornar as coisas permanentes, podemos usar o comutador -P com o comando setsebool.
Conclusão
Na primeira parte deste tutorial, tentamos entender alguns conceitos básicos sobre o SELinux. Vimos como o SELinux pode proteger um sistema, como podemos ativá-lo e em que modos ele pode ser executado. Também abordamos o tópico da política do SELinux. Em seguida, aprenderemos como usar o SELinux para restringir o acesso a arquivos e processos .
Até a próximaFim da primeira parte...
Parabenizamos o @ChicoFedora pelo excelente material.
0 -
Muito bom ótima postagem parabens
0
Salas de discussão
- 721 Todas as salas de discussão
- 5 Eventos
- 402 Fedora
- 7 CoreOS
- 137 Spins
- 11 CINNAMON
- 28 GNOME
- 63 KDE
- 10 LXDE
- 4 LXQT
- 13 MATE
- SOAS
- 3 XFCE
- 13 Server
- 84 Workstation
- 33 SilverBlue
- Atomic
- 3 Labs
- ARM®
- 3 Segurança
- 7 Servidores
- 222 Tutoriais
- 6 Críticas e Sugestões
- 16 Novidades e anuncios
- 5 CentOS
- 18 Games
- 31 Hardware
- 8 Linguagens de programação