🥇Sistemas de segurança Linux

Uma das razões para o tremendo sucesso do sistema operacional Linux em dispositivos e servidores móveis incorporados é o alto grau de segurança do kernel, serviços e aplicativos relacionados. Mas se Olhe mais de perto à arquitetura do kernel Linux, então é impossível encontrar nele um quadrado responsável pela segurança como tal. Onde está escondido o subsistema de segurança do Linux e em que consiste?

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

Security Enhanced Linux é um conjunto de regras e mecanismos de acesso baseados em modelos de acesso obrigatórios e baseados em funções para proteger os sistemas Linux de ameaças potenciais e corrigir as deficiências 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 e foi desenvolvido diretamente principalmente pelos empreiteiros Secure Computing Corporation e MITRE, bem como por vários laboratórios de pesquisa.

Módulos de segurança do Linux

Linus Torvalds fez vários comentários sobre os novos desenvolvimentos da NSA para que pudessem ser incluídos no kernel principal do Linux. Ele descreveu um ambiente geral, com um conjunto de interceptores para controlar operações com objetos e um conjunto de certos campos de proteção em estruturas de dados do kernel para armazenar os atributos correspondentes. Este ambiente pode então ser usado por módulos carregáveis do kernel para implementar qualquer modelo de segurança desejado. O LSM entrou totalmente no kernel Linux v2.6 em 2003.

A estrutura LSM inclui campos de proteção em estruturas de dados e chamadas para funções de interceptação em pontos críticos do código do kernel para manipulá-los e realizar controle de acesso. 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 chamadas na ordem especificada em CONFIG_LSM. A documentação detalhada sobre ganchos está incluída no arquivo de cabeçalho include/linux/lsm_hooks.h.

O subsistema LSM possibilitou completar a integração total do SELinux com a mesma versão do kernel Linux estável v2.6. Quase imediatamente, o SELinux se tornou o padrão de fato para um ambiente Linux seguro e foi incluído nas distribuições mais populares: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.

Glossário SELinux

Identidade — O usuário SELinux não é o mesmo que o ID de usuário usual do Unix/Linux; eles podem coexistir no mesmo sistema, mas são completamente diferentes em essência. Cada conta padrão do Linux pode corresponder a uma ou mais no SELinux. A identidade SELinux faz parte do contexto geral de segurança, que determina quais domínios você pode ou não ingressar.
domínios - No SELinux, um domínio é o contexto de execução de um assunto, ou seja, um processo. O domínio determina diretamente o acesso que um processo possui. Um domínio é basicamente uma lista do que os processos podem fazer ou o que um processo pode fazer com diferentes tipos. Alguns exemplos de domínios são sysadm_t para administração do sistema e user_t que é um domínio de usuário normal sem privilégios. O sistema init é executado no domínio init_t e o processo nomeado é executado no domínio nomeado_t.
Papéis — O que serve como intermediário entre domínios e usuários SELinux. As funções determinam a quais domínios um usuário pode pertencer e a quais tipos de objetos ele pode acessar. Este mecanismo de controle de acesso evita a ameaça de ataques de escalonamento de privilégios. As funções são escritas no modelo de segurança Role Based Access Control (RBAC) usado no SELinux.
tipos — Um atributo de lista de Aplicação de Tipo atribuído a um objeto e que determina quem pode acessá-lo. Semelhante à definição de domínio, exceto que o domínio se aplica a um processo e o tipo se aplica a objetos como diretórios, arquivos, soquetes, etc.
Sujeitos e objetos - Os processos são sujeitos e executados em um contexto específico ou domínio de segurança. Recursos do sistema operacional: arquivos, diretórios, soquetes, etc., são objetos aos quais é atribuído um determinado tipo, ou seja, um nível de privacidade.
Políticas SELinux — O SELinux usa uma variedade de políticas para proteger o sistema. A política SELinux define o acesso de usuários a funções, funções a domínios e domínios a tipos. Primeiro, o usuário está autorizado a obter uma função e, em seguida, a função está autorizada a acessar domínios. Finalmente, um domínio só pode ter acesso a determinados tipos de objetos.

LSM e a arquitetura SELinux

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

Pilha de verificação LSM

O LSM está equipado com ganchos nas principais funções do kernel que podem ser relevantes para verificações. Uma das principais características dos LSMs é que eles são empilhados. Assim, as verificações padrão ainda são executadas e cada camada do LSM apenas adiciona controles e controles adicionais. Isso significa que a proibição não pode ser revertida. Isso é mostrado na figura; se o resultado das verificações de rotina do DAC for uma falha, o problema nem chegará aos ganchos do LSM.

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

Graças à digitação de acesso forçado, o SELinux possui capacidades de controle de acesso muito maiores do que o modelo DAC tradicional usado em sistemas operacionais Unix/Linux. Por exemplo, você pode limitar o número da porta de rede à qual o servidor FTP se conectará, permitir gravar e alterar arquivos em uma determinada pasta, mas não excluí-los.

Os principais componentes do SELinux são:

Servidor de aplicação de políticas — 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 contendo arquivos contendo informações de status do SELinux.
Acessar cache de vetores — Um mecanismo auxiliar para aumentar a produtividade.

Como funciona o SELinux

Tudo funciona assim.

Um determinado sujeito, nos termos do SELinux, executa uma ação permitida em um objeto após uma verificação do DAC, conforme mostrado na imagem superior. Esta solicitação para realizar uma operação vai para o interceptor de eventos LSM.
A partir daí, a solicitação, juntamente com o contexto de segurança do sujeito e do objeto, é passada para o módulo SELinux Abstraction and Hook Logic, responsável por interagir com o LSM.
A autoridade de tomada de decisão sobre o acesso de um sujeito a um objeto é o Policy Enforcement Server e recebe dados do SELinux AnHL.
Para tomar decisões sobre acesso ou negação, o Policy Enforcement Server recorre ao subsistema de cache do Access Vector Cache (AVC) para obter as regras mais utilizadas.
Se uma solução para a regra correspondente não for encontrada no cache, a solicitação será repassada ao banco de dados de políticas de segurança.
O resultado da pesquisa do banco de dados e do AVC é retornado ao Policy Enforcement Server.
Se a política encontrada corresponder à ação solicitada, a operação será permitida. Caso contrário, a operação é proibida.

Gerenciando configurações do SELinux

SELinux opera em um dos três modos:

Aplicação - Adesão estrita às políticas de segurança.
Permissivo - É permitida a violação de restrições, sendo feita nota correspondente no diário.
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, definindo-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=alvo

A diferença com o setenfoce é que quando o sistema operacional inicializar, o modo SELinux será definido de acordo com o valor do parâmetro SELINUX no arquivo de configuração. Além disso, as alterações na aplicação de <=> desabilitada só terão efeito editando o 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
Para visualizar os atributos do SELinux, alguns utilitários padrão usam o parâmetro -Z.

[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

Comparado com a saída normal de ls -l, existem vários campos adicionais no seguinte formato:

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

O último campo denota algo como uma classificação de segurança e consiste em uma combinação de dois elementos:

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

Alterando a configuração de acesso

Use semodule para carregar, adicionar e remover módulos SELinux.

[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 - удалить модуль

Primeiro time login da semana conecta o usuário SELinux ao usuário do sistema operacional, o segundo exibe uma lista. Finalmente, o último comando com a opção -r remove o mapeamento de usuários SELinux para contas do sistema operacional. Uma explicação da sintaxe dos valores do intervalo MLS/MCS está 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
Equipe usuário semanage usado para gerenciar mapeamentos entre 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 adicionar entrada de mapeamento de função personalizada;
-l lista de usuários e funções correspondentes;
-d exclui entrada de mapeamento de função de usuário;
-R lista de funções anexadas ao usuário;

Arquivos, portas e valores booleanos

Cada módulo SELinux fornece um conjunto de regras de 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 de forma que apenas os serviços apropriados possam ouvi-las. 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 desses parâmetros pode ser vista usando getsebool -a. Você pode alterar os valores booleanos usando 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, obtenha acesso à interface Pgadmin-web

Vejamos um exemplo prático: instalamos o pgadmin7.6-web no RHEL 4 para administrar o banco de dados PostgreSQL. Caminhamos um pouco busca com as configurações de pg_hba.conf, postgresql.conf e config_local.py, defina as permissões de pasta, instale os módulos Python ausentes do pip. Está tudo pronto, lançamos e recebemos 500 erro do servidor interno.

Começamos com os suspeitos típicos, verificando /var/log/httpd/error_log. Existem algumas entradas interessantes lá.

[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.

Neste ponto, a maioria dos administradores Linux ficará fortemente tentada a executar setencorce 0, e isso será o fim. Francamente, fiz exatamente isso da primeira vez. É claro que esta também é uma saída, mas está longe de ser a melhor.

Apesar dos designs complicados, o SELinux pode ser fácil de usar. Basta instalar o pacote setroubleshoot e visualizar o log do sistema.

[admin@server ~]$ yum install setroubleshoot [admin@server ~]$ journalctl -b -0 [admin@server ~]$ service restart auditd

Observe que o serviço auditd deve ser reiniciado desta forma, e não usando systemctl, apesar da presença do systemd no sistema operacional. No log do sistema será indicado não apenas o fato do bloqueio, mas também o motivo e maneira de superar a proibição.

Executamos estes comandos:

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

Verificamos o acesso à página pgadmin4-web, tudo funciona.

Fonte: habr.com

Sistemas de segurança Linux