Sistemas de segurança Linux

Uma das razões para o tremendo sucesso do sistema operacional Linux em servidores e dispositivos móveis integrados é o alto grau de segurança do kernel, serviços e aplicativos relacionados. Mas se você olhar atentamente para a arquitetura do kernel Linux, você não encontrará uma caixa responsável pela segurança, como tal. Onde está escondido o subsistema de segurança do Linux e em que consiste?



Histórico dos módulos de segurança do Linux e SELinux



Security Enhanced Linux é um conjunto de regras e um mecanismo de acesso baseado em modelos de acesso obrigatórios e baseados em funções para proteger os sistemas Linux de ameaças potenciais e corrigir as falhas do Controle de Acesso Discricionário (DAC), o sistema de segurança Unix tradicional. O projeto teve origem nas entranhas da Agência de Segurança Nacional dos EUA, principalmente as empreiteiras Secure Computing Corporation e MITER, bem como vários laboratórios de pesquisa, que estiveram diretamente envolvidos no desenvolvimento.





Módulos de Segurança Linux



Linus Torvalds fez uma série de comentários sobre os novos desenvolvimentos da NSA para que eles possam ser incluídos no kernel Linux upstream. Ele descreveu um ambiente geral, com um conjunto de interceptores para gerenciar operações com objetos e um conjunto de alguns campos de proteção nas estruturas de dados do kernel para armazenar os atributos correspondentes. Este ambiente pode então ser usado por módulos de kernel carregáveis ​​para implementar qualquer modelo de segurança desejado. O LSM foi totalmente incorporado ao kernel do Linux v2.6 em 2003.



A estrutura do LSM inclui campos de proteção em estruturas de dados e chamadas para interceptar funções em pontos críticos no código do kernel para gerenciá-los e executar controle de acesso. Ele também adiciona funcionalidade para registrar módulos de segurança. A interface / sys / kernel / security / lsm contém uma lista de módulos ativos no sistema. Os ganchos LSM são armazenados em listas, que são chamadas na ordem especificada em CONFIG_LSM. A documentação detalhada do gancho está incluída no arquivo de cabeçalho include / linux / lsm_hooks.h.



O subsistema LSM permitiu a integração completa do SELinux do mesmo kernel Linux estável v2.6. Quase imediatamente, o SELinux se tornou o padrão de fato para ambientes Linux seguros e se tornou parte das distribuições mais populares: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.



Glossário SELinux



  • — SELinux , Unix/Linux user id, , . Linux SELinux. SELinux , , — .
  • — SELinux , . . . , . — , . : sysadm_t , user_t, . init init_t, named named_t.
  • — , SELinux. , . . Role Based Access Control (RBAC), SELinux.
  • — Type Enforcement, , . , , , , , , . .
  • — , . : , , ., , , — .
  • SELinux — SELinux . SELinux , — — . , . .


LSM SELinux



Apesar do nome, os LSMs geralmente não são módulos carregáveis ​​do Linux. No entanto, assim como o SELinux, ele é integrado diretamente ao kernel. Qualquer mudança no código-fonte do LSM requer uma nova compilação do kernel. A opção correspondente deve ser habilitada nas configurações do kernel, caso contrário, o código LSM não será ativado após a inicialização. Mesmo assim, ele pode ser habilitado com a opção bootloader do sistema operacional.





LSM check stack O



LSM é equipado com ganchos em funções centrais que podem ser relevantes para verificações. Uma das principais características dos LSMs é que eles são empilhados. Portanto, as verificações padrão ainda são realizadas e cada camada LSM apenas adiciona controles e controles adicionais. Isso significa que o banimento não pode ser revertido. Isso é mostrado na figura, se o resultado das verificações de rotina do DAC for uma falha, então ele nem mesmo alcançará os ganchos do LSM.



O SELinux adotou a arquitetura de segurança Flask do sistema operacional de pesquisa Fluke, em particular o princípio do menor privilégio. A essência desse conceito, como o nome indica, é conceder a um usuário ou processo apenas os direitos necessários para realizar as ações pretendidas. Este princípio é implementado usando digitação forçada de acesso, portanto, o controle de admissão do SELinux é baseado no modelo domínio => tipo.



Devido à digitação forçada de acesso, o SELinux tem recursos de controle de acesso muito mais significativos do que o modelo DAC tradicional usado no sistema operacional Unix / Linux. Por exemplo, você pode restringir o número da porta de rede que acontecerá com o servidor ftp, permitir a gravação e alteração de arquivos em uma pasta específica, mas não excluí-los.



Os principais componentes do SELinux são:



  • Policy Enforcement Server - O principal mecanismo para organizar o controle de acesso.
  • Banco de dados de políticas de segurança do sistema.
  • Interação com o interceptor de eventos LSM.
  • Selinuxfs - Pseudo-FS, igual a / proc e montado em / sys / fs / selinux. Preenchido dinamicamente pelo kernel Linux em tempo de execução e contém arquivos contendo informações de status do SELinux.
  • Access Vector Cache - um auxiliar de desempenho.




Como o SELinux funciona



Tudo isso funciona da seguinte maneira.



  1. Um determinado sujeito, nos termos do SELinux, executa uma ação permitida em um objeto após uma verificação DAC, conforme mostrado na imagem superior. Esta solicitação para realizar a operação vai para o interceptor de eventos LSM.
  2. A partir daí, a solicitação, junto com o contexto de segurança do sujeito e do objeto, é passada para o módulo SELinux Abstraction e Hook Logic responsável por interagir com o LSM.
  3. O Policy Enforcement Server é a instância para decidir sobre o acesso do sujeito ao objeto, e os dados do SELinux AnHL chegam a ele.
  4. Para tomar uma decisão sobre acesso ou negação, o Policy Enforcement Server consulta o subsistema de cache das regras de cache de vetor de acesso (AVC) mais comumente usadas.
  5. Se uma solução para a regra correspondente não for encontrada no cache, a solicitação será enviada ao banco de dados da política de segurança.
  6. O resultado da pesquisa do DB e AVC é retornado ao Policy Enforcement Server.
  7. Se a política encontrada corresponder à ação solicitada, a operação será permitida. Caso contrário, a operação é proibida.


Gerenciando as configurações do SELinux



O SELinux opera em um dos três modos:



  • Fiscalização - Cumprimento estrito das políticas de segurança.
  • Permissivo - a violação das restrições é permitida, a marca correspondente é feita no log.
  • Desativado - as políticas de segurança não estão em vigor.


Você pode ver em que modo o SELinux está com o seguinte comando.



[admin@server ~]$ getenforce
Permissive


Alterar o modo antes de reinicializar, por exemplo, defina-o como obrigatório ou 1. O parâmetro permissivo corresponde ao código numérico 0.



[admin@server ~]$ setenfoce enforcing
[admin@server ~]$ setenfoce 1 #  


Você também pode alterar o modo editando o arquivo:



[admin@server ~]$ cat /etc/selinux/config


# 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 = targete



A diferença com setenfoce é que quando o sistema operacional inicializa, o modo SELinux será definido de acordo com o valor do parâmetro SELINUX do arquivo de configuração. Além disso, as mudanças para forçar <=> desativado têm efeito apenas através da edição do arquivo / etc / selinux / config e após uma reinicialização.



Veja um breve relatório de status:



[admin@server ~]$ sestatus


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


Alguns dos utilitários nativos usam o parâmetro -Z para visualizar os atributos do SELinux.



[admin@server ~]$ ls -lZ /var/log/httpd/
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20200920
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20200927
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20201004
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20201011
[admin@server ~]$ ps -u apache -Z
LABEL                             PID TTY          TIME CMD
system_u:system_r:httpd_t:s0     2914 ?        00:00:04 httpd
system_u:system_r:httpd_t:s0     2915 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2916 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2917 ?        00:00:00 httpd
...
system_u:system_r:httpd_t:s0     2918 ?        00:00:00 httpd


Em comparação com a saída ls -l usual, existem vários campos adicionais no seguinte formato:



<user>:<role>:<type>:<level>



O último campo denota algo como um selo de sigilo e consiste em uma combinação de dois elementos:



  • s0 - significância, também escrita como intervalo de baixo nível-alto
  • c0, c1… c1023 - categoria.


Mudança de configuração de acesso



Use o semodule para carregar módulos SELinux, adicione e remova-os.



[admin@server ~]$ semodule -l |wc -l #  
408
[admin@server ~]$ semodule -e abrt #enable -  
[admin@server ~]$ semodule -d accountsd #disable -  
[admin@server ~]$ semodule -r avahi #remove -  


O primeiro comando, semanage login, vincula o usuário SELinux ao usuário do sistema operacional, o segundo exibe a lista. Finalmente, o último comando com a opção -r remove o mapeamento dos usuários do SELinux para as contas do sistema operacional. Uma explicação da sintaxe para os valores do intervalo MLS / MCS é encontrada na seção anterior.



[admin@server ~]$ semanage login -a -s user_u karol
[admin@server ~]$ semanage login -l


Login Name SELinux User MLS/MCS Range Service

__default__ unconfined_u s0-s0:c0.c1023 *

root unconfined_u s0-s0:c0.c1023 *

system_u system_u s0-s0:c0.c1023 *

[admin@server ~]$ semanage login -d karol



O comando semanage user é usado para gerenciar os mapeamentos entre os usuários e funções do SELinux.



[admin@server ~]$ semanage user -l
                Labeling   MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range             SELinux Roles
guest_u         user       s0         s0                    guest_r
staff_u         staff      s0         s0-s0:c0.c1023        staff_r sysadm_r
...
user_u          user       s0         s0                    user_r
xguest_u        user       s0         s0                    xguest_r
[admin@server ~]$ semanage user -a -R 'staff_r user_r'
[admin@server ~]$ semanage user -d test_u


Parâmetros de comando:



  • -a adiciona uma entrada de mapeamento de função customizada;
  • -l lista de correspondência entre usuários e funções;
  • -d remove a entrada de mapeamento de função definida pelo usuário;
  • -R lista de funções atribuídas ao usuário;


Arquivos, portas e booleanos



Cada módulo SELinux fornece um conjunto de regras para marcação de arquivos, mas você também pode adicionar suas próprias regras, se necessário. Por exemplo, queremos que o servidor web tenha direitos de acesso à pasta / srv / www.



[admin@server ~]$ semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?
[admin@server ~]$ restorecon -R /srv/www/


O primeiro comando registra novas regras de marcação e o segundo redefine, ou melhor, define os tipos de arquivo de acordo com as regras atuais.



Da mesma forma, as portas TCP / UDP são marcadas para que apenas os serviços correspondentes possam escutar nelas. Por exemplo, para que o servidor web escute na porta 8080, você precisa executar o comando.



[admin@server ~]$ semanage port -m -t http_port_t -p tcp 8080


Um número significativo de módulos SELinux possui parâmetros que podem assumir valores booleanos. A lista completa de tais parâmetros pode ser vista com getsebool -a. Os valores booleanos podem ser alterados com setsebool.



[admin@server ~]$ getsebool httpd_enable_cgi
httpd_enable_cgi --> on
[admin@server ~]$ setsebool -P httpd_enable_cgi off
[admin@server ~]$ getsebool httpd_enable_cgi
httpd_enable_homedirs --> off


Workshop, acesse a interface Pgadmin-web



Considere um exemplo da prática, instalamos no RHEL 7.6 pgadmin4-web para administração de banco de dados PostgreSQL. Passamos por uma pequena missão com a configuração de pg_hba.conf, postgresql.conf e config_local.py, definimos os direitos para pastas, instalamos módulos Python ausentes do pip. Tudo está pronto, execute-o e obtenha 500 erro interno do servidor .







Começando com os suspeitos típicos, verificando / var / log / httpd / error_log. Existem algumas entradas interessantes lá. Nesse ponto, a maioria dos administradores Linux ficará tentada a executar setencorce 0 e pronto. Francamente, a primeira vez que fiz isso. É claro que essa também é uma saída, mas está longe de ser a melhor.



[timestamp] [core:notice] [pid 23689] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0

...

[timestamp] [wsgi:error] [pid 23690] [Errno 13] Permission denied: '/var/lib/pgadmin'

[timestamp] [wsgi:error] [pid 23690]

[timestamp] [wsgi:error] [pid 23690] HINT : You may need to manually set the permissions on

[timestamp] [wsgi:error] [pid 23690] /var/lib/pgadmin to allow apache to write to it.








Apesar de seu design pesado, o SELinux pode ser amigável. Basta instalar o pacote setroubleshoot e visualizar o log do sistema. Observe que o serviço auditd deve ser reiniciado desta forma, e não usando systemctl, apesar da presença de systemd no sistema operacional. O log do sistema indicará não apenas o fato do bloqueio, mas também o motivo e a forma de superar o bloqueio . Executamos os seguintes comandos: Verificamos o acesso à página web do pgadmin4-web, tudo funciona.



[admin@server ~]$ yum install setroubleshoot

[admin@server ~]$ journalctl -b -0

[admin@server ~]$ service restart auditd
















[admin@server ~]$ setsebool -P httpd_can_network_connect 1

[admin@server ~]$ setsebool -P httpd_can_network_connect_db 1















All Articles