Proxecto Openwall liberación do módulo do núcleo (Linux Kernel Runtime Guard), deseñado para detectar e bloquear ataques e violacións da integridade das estruturas do núcleo. Por exemplo, o módulo pode protexer contra cambios non autorizados no núcleo en execución e intentos de cambiar os permisos dos procesos dos usuarios (detectar o uso de exploits). O módulo é adecuado tanto para organizar a protección contra exploits xa coñecidos para o núcleo de Linux (por exemplo, en situacións nas que é difícil actualizar o núcleo no sistema), como para contrarrestar vulnerabilidades aínda descoñecidas. Código do proxecto licenciado baixo GPLv2.
Entre os cambios na nova versión:
- Cambiouse o posicionamento do proxecto LKRG, que xa non está dividido en subsistemas separados para comprobar a integridade e determinar o uso de exploits, senón que se presenta como un produto completo para identificar ataques e varias violacións de integridade;
- A compatibilidade ofrécese cos núcleos Linux de 5.3 a 5.7, así como con núcleos compilados con optimizacións GCC agresivas, sen as opcións CONFIG_USB e CONFIG_STACKTRACE ou coa opción CONFIG_UNWINDER_ORC, así como con núcleos que non teñan funcións enganchadas a LKRG, se poden. prescindirse de;
- Ao construír, compróbanse algunhas configuracións obrigatorias do núcleo CONFIG_* para xerar mensaxes de erro significativas en lugar de fallas escuras;
- Engadido soporte para os modos de espera (ACPI S3, suspender a RAM) e de suspensión (S4, suspender a disco);
- Engadido soporte DKMS a Makefile;
- Implementouse soporte experimental para plataformas ARM de 32 bits (probado en Raspberry Pi 3 Modelo B). O soporte AArch64 (ARM64) dispoñible anteriormente ampliouse para ofrecer compatibilidade coa placa Raspberry Pi 4;
- Engadíronse novos ganchos, incluíndo un manejador de chamadas capable() para identificar mellor os exploits que manipulan "", non os ID de proceso ();
- Propúxose unha nova lóxica para detectar intentos de escapar das restricións do espazo de nomes (por exemplo, desde os contedores Docker);
- Nos sistemas x86-64, compróbase e aplícase o bit SMAP (Prevención de acceso ao modo de supervisor), deseñado para bloquear o acceso aos datos do espazo do usuario desde o código privilexiado que se executa no nivel do núcleo. A protección SMEP (Supervisor Mode Execution Prevention) implementouse anteriormente;
- Durante o funcionamento, os axustes de LKRG colócanse nunha páxina de memoria que adoita ser de só lectura;
- A información de rexistro que pode ser máis útil para ataques (por exemplo, información sobre enderezos no núcleo) está limitada ao modo de depuración (log_level=4 e superior), que está desactivado por defecto.
- Aumentouse a escalabilidade da base de datos de seguimento de procesos: en lugar dunha árbore RB protexida por un spinlock, utilízase unha táboa hash de 512 árbores RB protexidas por 512 bloqueos de lectura-escritura;
- Implementouse e habilitouse un modo por defecto, no que a integridade dos identificadores do proceso adoita comprobarse só para a tarefa actual, e tamén opcionalmente para as tarefas activadas (despertar). Para outras tarefas que están en estado de suspensión ou funcionan sen acceder á API do núcleo controlada por LKRG, a comprobación realízase con menos frecuencia.
- Engadíronse novos parámetros sysctl e módulo para axustar LKRG, así como dous sysctl para simplificar a configuración seleccionando entre conxuntos de configuracións de axuste fino (perfís) preparados polos desenvolvedores;
- Modificouse a configuración predeterminada para conseguir un equilibrio máis equilibrado entre a velocidade de detección de infraccións e a eficacia da resposta, por unha banda, e o impacto no rendemento e o risco de falsos positivos, por outra;
- O ficheiro da unidade systemd foi redeseñado para cargar o módulo LKRG no inicio do arranque (pódese usar unha opción de liña de comandos do núcleo para desactivar o módulo);
Tendo en conta as optimizacións propostas na nova versión, a redución de rendemento ao usar LKRG 0.8 estímase nun 2.5% no modo predeterminado ("pesado") e nun 2% no modo lixeiro ("lixeiro").
Nunha celebrada recentemente eficacia dos paquetes para detectar rootkits LKRG mellores resultados, identificando 8 de cada 9 rootkicks probados que traballan a nivel do núcleo sen falsos positivos (os rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit e Sutekh foron identificados, pero Keysniffer, que é un módulo do núcleo, perdeuse cun keylogger, non cun rootkit no sentido literal). A modo de comparación, os paquetes AIDE, OSSEC e Rootkit Hunter detectaron 2 de cada 9 rootkits, mentres que Chkrootkit non detectou ningún. Ao mesmo tempo, LKRG non admite a detección de rootkits situados no espazo do usuario, polo que a maior eficiencia conséguese ao utilizar unha combinación de AIDE e LKRG, o que permitiu identificar 14 de cada 15 rootkits de todo tipo.
Ademais, pódese notar que o desenvolvedor da distribución comezou paquetes preparados con DKMS para Debian, Whonix, Qubes e Kicksecure, e un paquete para xa actualizado á versión 0.8. Os paquetes con LKRG tamén están dispoñibles en ruso и .
A verificación de integridade en LKRG realízase comparando o código e os datos reais do núcleo e dos módulos, algunhas estruturas de datos importantes e a configuración da CPU con hash almacenados ou copias das áreas de memoria, estruturas de datos ou rexistros correspondentes. As comprobacións actívanse periódicamente polo temporizador e cando se producen varios eventos.
A determinación do posible uso de exploits e o bloqueo de ataques realízase na fase anterior ao que o núcleo ofreza acceso aos recursos (por exemplo, antes de abrir un ficheiro), pero despois de que o proceso recibiu permisos non autorizados (por exemplo, cambiando o UID). Cando se detecta un comportamento non autorizado, os procesos vense obrigados a finalizar por defecto, o que é suficiente para bloquear moitos exploits.
Fonte: opennet.ru