🥇Sistemas de seguridade Linux

Unha das razóns do enorme éxito do sistema operativo Linux en dispositivos e servidores móbiles integrados é o grao relativamente alto de seguridade do núcleo, servizos e aplicacións relacionados. Pero se bótalle unha ollada máis atenta á arquitectura do núcleo de Linux, entón é imposible atopar nel un cadrado responsable da seguridade como tal. Onde se agocha o subsistema de seguridade de Linux e en que consiste?

Antecedentes sobre os módulos de seguridade de Linux e SELinux

Security Enhanced Linux é un conxunto de regras e mecanismos de acceso baseados en modelos de acceso obrigatorios e baseados en roles para protexer os sistemas Linux de potenciais ameazas e corrixir as deficiencias do Control de acceso discrecional (DAC), o sistema de seguridade tradicional de Unix. O proxecto orixinouse nas entrañas da Axencia de Seguridade Nacional dos Estados Unidos e foi desenvolvido directamente polos contratistas Secure Computing Corporation e MITRE, así como por varios laboratorios de investigación.

Módulos de seguridade de Linux

Linus Torvalds aportou unha serie de notas sobre novos desenvolvementos da NSA para que puidesen incluírse na rama principal do núcleo de Linux. Describiu un ambiente común, cun conxunto de interceptores para xestionar operacións sobre obxectos e un conxunto dalgúns campos de protección nas estruturas de datos do núcleo para almacenar os atributos correspondentes. Este ambiente pode ser usado por módulos do núcleo cargables para implementar calquera modelo de seguridade desexado. LSM entrou completamente no núcleo Linux v2.6 en 2003.

O marco LSM inclúe campos de garda nas estruturas de datos e chamadas de funcións de interceptación en puntos críticos do código do núcleo para xestionalos e realizar o control de acceso. Tamén engade funcionalidade para rexistrar módulos de seguridade. A interface /sys/kernel/security/lsm contén unha lista de módulos activos no sistema. Os ganchos LSM almacénanse en listas que se chaman na orde especificada en CONFIG_LSM. No ficheiro de cabeceira include/linux/lsm_hooks.h inclúese documentación detallada do gancho.

O subsistema LSM permitiu completar a integración total de SELinux da mesma versión do núcleo estable de Linux v2.6. Literalmente inmediatamente, SELinux converteuse no estándar de facto para un ambiente Linux seguro e pasou a formar parte das distribucións máis populares: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.

Glosario SELinux

Identidade - O usuario de SELinux non é o mesmo que o id de usuario de Unix/Linux habitual, poden coexistir no mesmo sistema, pero son completamente diferentes en esencia. Cada conta estándar de Linux pode corresponder a unha ou máis en SELinux. A identidade de SELinux forma parte do contexto de seguridade global que determina a que dominios podes e non podes unir.
dominios - En SELinux, o dominio é o contexto de execución do suxeito, é dicir, o proceso. O dominio define directamente o acceso que ten un proceso. Un dominio é basicamente unha lista do que poden facer os procesos ou que accións pode facer un proceso con diferentes tipos. Algúns exemplos de dominios son sysadm_t para a administración do sistema e user_t, que é un dominio de usuario normal sen privilexios. O sistema init execútase no dominio init_t e o proceso nomeado execútase no dominio named_t.
Papeis - Algo que serve de intermediario entre dominios e usuarios de SELinux. Os roles definen a que dominios pode pertencer un usuario e a que tipos de obxectos pode acceder. Tal mecanismo de control de acceso evita a ameaza dun ataque de escalada de privilexios. Os roles están escritos no modelo de seguridade de control de acceso baseado en roles (RBAC) usado en SELinux.
Tipos — Escriba o atributo da lista de aplicación que se asigna a un obxecto e determina quen terá acceso a el. Similar a definir un dominio, agás que o dominio aplícase ao proceso, mentres que o tipo aplícase a obxectos como directorios, ficheiros, sockets, etc.
Suxeitos e obxectos - Os procesos son suxeitos e execútanse nun contexto determinado, ou dominio de seguridade. Os recursos do sistema operativo: ficheiros, directorios, sockets, etc., son obxectos aos que se lles asigna un determinado tipo, é dicir, un nivel de segredo.
Políticas de SELinux - SELinux usa unha variedade de políticas para protexer o sistema. A política de SELinux define o acceso dos usuarios aos roles, roles aos dominios e dominios aos tipos. Primeiro, o usuario está autorizado para obter un rol, despois o rol está autorizado para acceder a dominios. Finalmente, un dominio só pode ter acceso a certos tipos de obxectos.

LSM e a arquitectura SELinux

A pesar do nome, os LSM non son xeralmente módulos de Linux cargables. Non obstante, como SELinux, está directamente integrado no núcleo. Calquera cambio no código fonte de LSM require unha nova compilación do núcleo. A opción correspondente debe estar activada na configuración do núcleo, se non, o código LSM non se activará despois do arranque. Pero mesmo neste caso, pódese activar a opción do cargador de arranque do SO.

Pila de cheques LSM

LSM está equipado con ganchos nas funcións básicas do núcleo que poden ser relevantes para as comprobacións. Unha das principais características de LSM é que están baseados en pilas. Así, as comprobacións estándar aínda se realizan e cada capa LSM só engade controis e controis adicionais. Isto significa que a prohibición non se pode revertir. Isto móstrase na figura, se o resultado das comprobacións rutineiras DAC é un fallo, entón nin sequera chegará aos ganchos LSM.

SELinux adoptou a arquitectura de seguridade Flask do sistema operativo de investigación de Fluke, concretamente o principio de mínimos privilexios. A esencia deste concepto, como o seu nome indica, é concederlle ao usuario ou tramitar só aqueles dereitos que sexan necesarios para a realización das accións previstas. Este principio implícase mediante a escritura de acceso forzado, polo que o control de acceso de SELinux baséase no modelo do dominio => tipo.

A través da escritura de acceso forzado, SELinux ten capacidades de control de acceso moito maiores que o modelo tradicional DAC usado nos sistemas operativos Unix/Linux. Por exemplo, pode limitar o número de porto de rede que lle ocorrerá ao servidor ftp, permitir escribir e cambiar ficheiros nun cartafol determinado, pero non eliminalos.

Os principais compoñentes de SELinux son:

Servidor de aplicación de políticas - O principal mecanismo de organización do control de acceso.
Base de datos de políticas de seguridade do sistema.
Interacción co oínte de eventos LSM.
Selinuxfs - Pseudo-FS, igual que /proc e montado en /sys/fs/selinux. Poboado dinámicamente polo núcleo de Linux no tempo de execución e contén ficheiros que conteñen información de estado de SELinux.
Acceso á caché vectorial - Mecanismo auxiliar para mellorar o rendemento.

Como funciona SELinux

Todo isto funciona do seguinte xeito.

Un determinado suxeito, en termos de SELinux, realiza unha acción permitida sobre un obxecto despois dunha comprobación de DAC, como se mostra na imaxe superior. Esta solicitude para realizar unha operación vai ao interceptor de eventos LSM.
A partir de aí, a solicitude, xunto co contexto de seguridade do suxeito e do obxecto, pásase ao módulo SELinux Abstraction and Hook Logic responsable de interactuar co LSM.
O servidor de aplicación de políticas é a autoridade de decisión sobre o acceso do suxeito ao obxecto e recibe datos de SELinux AnHL.
Para tomar unha decisión sobre o acceso, ou prohibición, o servidor de aplicación de políticas refírese ao subsistema de caché das regras de caché de vectores de acceso (AVC) máis utilizadas.
Se a solución para a regra correspondente non se atopa na caché, entón a solicitude pasará á base de datos da política de seguridade.
O resultado da busca da base de datos e AVC devólvese ao servidor de aplicación de políticas.
Se a política atopada é coherente coa acción solicitada, a operación está permitida. En caso contrario, a operación está prohibida.

Xestionar a configuración de SELinux

SELinux funciona nun dos tres modos:

Aplicación: cumprimento estrito das políticas de seguridade.
Permiso - Permítese a violación das restricións; faise unha nota correspondente no diario.
Desactivado: as políticas de seguridade non están en vigor.

Podes ver en que modo está SELinux co seguinte comando.

[admin@server ~]$ getenforce
Permissive

Cambiar o modo antes de reiniciar, por exemplo, axustándoo a aplicación ou 1. O parámetro permisivo corresponde ao código numérico 0.

[admin@server ~]$ setenfoce enforcing
[admin@server ~]$ setenfoce 1 #то же самое

Tamén podes cambiar o modo editando o ficheiro:

[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=obxectivo

A diferenza con setenfoce é que cando se inicia o sistema operativo, o modo SELinux establecerase de acordo co valor do parámetro SELINUX no ficheiro de configuración. Ademais, a aplicación de <=> cambios desactivados só ten efecto a través da edición do ficheiro /etc/selinux/config e despois dun reinicio.

Ver informe de estado resumido:

[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 ver os atributos de SELinux, algunhas utilidades de stock usan a opción -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

En comparación coa saída normal de ls -l, hai varios campos adicionais no seguinte formato:

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

O último campo denota algo así como unha clasificación de seguridade e consiste nunha combinación de dous elementos:

s0 - significación, tamén rexistrada como intervalo de nivel baixo-nivel alto
c0, c1... c1023 é a categoría.

Cambiando a configuración de acceso

Use semodule para cargar, engadir e eliminar 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 equipo inicio de sesión semanal asocia un usuario de SELinux cun usuario do sistema operativo, o segundo enumérao. Finalmente, o último comando co interruptor -r elimina a asignación dos usuarios de SELinux ás contas do SO. Na sección anterior atópase unha explicación da sintaxe para os valores do intervalo MLS/MCS.

[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
Equipo usuario semanage usado para xestionar as asignacións entre usuarios e roles de 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 engadir unha entrada de asignación de roles personalizada;
-l lista de usuarios e roles coincidentes;
-d elimina a entrada de asignación de roles personalizada;
-R lista de roles adscritos ao usuario;

Ficheiros, portos e valores booleanos

Cada módulo SELinux ofrece un conxunto de regras de marcado de ficheiros, pero tamén pode engadir as súas propias regras se é necesario. Por exemplo, queremos que o servidor web teña dereitos de acceso ao cartafol /srv/www.

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

O primeiro comando rexistra novas regras de marcado e o segundo restablece, ou mellor dito, expón os tipos de ficheiros de acordo coas regras actuais.

Así mesmo, os portos TCP/UDP están marcados de tal xeito que só poden escoitar neles os servizos axeitados. Por exemplo, para que un servidor web escoite no porto 8080, cómpre executar un comando.

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

Un número significativo de módulos SELinux teñen parámetros que poden tomar valores booleanos. A lista completa destas opcións pódese ver con getsebool -a. Os valores booleanos pódense cambiar 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

Practicum, accede á interface web de Pgadmin

Considere un exemplo da práctica, instalamos pgadmin7.6-web en RHEL 4 para administrar a base de datos PostgreSQL. Pasamos un pequeno misión coa configuración de pg_hba.conf, postgresql.conf e config_local.py, estableza os dereitos para os cartafoles, instalou os módulos de Python que faltan de pip. Todo está listo, lanzamos e recibimos 500 Erro interno do servidor.

Comezamos cos típicos sospeitosos, comprobando /var/log/httpd/error_log. Hai algunhas entradas interesantes alí.

[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 punto, a maioría dos administradores de Linux terán a forte tentación de executar setencorce 0, e ese será o final. Francamente, fixen iso a primeira vez. Por suposto, esta tamén é unha saída, pero lonxe do mellor.

A pesar dos deseños engorrosos, SELinux pode ser fácil de usar. Só ten que instalar o paquete de solución de problemas e ver o rexistro do sistema.

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

Teña en conta que o servizo auditd debe reiniciarse deste xeito e non usar systemctl, a pesar da presenza de systemd no SO. No rexistro do sistema indicarase non só o feito de bloquear, senón tamén o motivo e forma de superar a prohibición.

Executamos estes comandos:

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

Comprobamos o acceso á páxina web pgadmin4-web, todo funciona.

Fonte: www.habr.com

Sistemas de seguridade Linux