Proyekto ng Openwall pagpapalabas ng kernel module (Linux Kernel Runtime Guard), na idinisenyo upang makita at harangan ang mga pag-atake at mga paglabag sa integridad ng mga istruktura ng kernel. Halimbawa, maaaring maprotektahan ng module laban sa mga hindi awtorisadong pagbabago sa tumatakbong kernel at pagtatangka na baguhin ang mga pahintulot ng mga proseso ng user (pagtukoy sa paggamit ng mga pagsasamantala). Ang module ay angkop kapwa para sa pag-aayos ng proteksyon laban sa mga kilalang pagsasamantala para sa Linux kernel (halimbawa, sa mga sitwasyon kung saan mahirap i-update ang kernel sa system), at para sa pagkontra sa mga pagsasamantala para sa hindi pa alam na mga kahinaan. Code ng proyekto lisensyado sa ilalim ng GPLv2.
Kabilang sa mga pagbabago sa bagong bersyon:
- Ang pagpoposisyon ng proyekto ng LKRG ay binago, na hindi na nahahati sa magkakahiwalay na mga subsystem para sa pagsuri sa integridad at pagtukoy sa paggamit ng mga pagsasamantala, ngunit ipinakita bilang isang kumpletong produkto para sa pagtukoy ng mga pag-atake at iba't ibang mga paglabag sa integridad;
- Ang pagiging tugma ay ibinibigay sa mga kernel ng Linux mula 5.3 hanggang 5.7, pati na rin sa mga kernel na pinagsama-sama sa mga agresibong pag-optimize ng GCC, nang walang mga opsyon na CONFIG_USB at CONFIG_STACKTRACE o sa opsyon na CONFIG_UNWINDER_ORC, gayundin sa mga kernel na walang mga function na nakakabit ng LKRG, kung kaya nila ipagkaloob sa;
- Kapag bumubuo, ang ilang mandatoryong CONFIG_* na mga setting ng kernel ay sinusuri upang makabuo ng mga makabuluhang mensahe ng error sa halip na mga hindi malinaw na pag-crash;
- Nagdagdag ng suporta para sa standby (ACPI S3, suspindihin sa RAM) at sleep (S4, suspindihin sa disk) na mga mode;
- Nagdagdag ng suporta sa DKMS sa Makefile;
- Ang pang-eksperimentong suporta para sa 32-bit na mga platform ng ARM ay ipinatupad (nasubok sa Raspberry Pi 3 Model B). Ang dating magagamit na suporta ng AArch64 (ARM64) ay pinalawak upang magbigay ng compatibility sa Raspberry Pi 4 board;
- Ang mga bagong hook ay naidagdag, kabilang ang isang may kakayahang() call handler upang mas mahusay na makilala ang mga pagsasamantala na nagmamanipula ng "", hindi iproseso ang mga ID ();
- Ang bagong lohika ay iminungkahi para sa pagtukoy ng mga pagtatangka na makatakas sa mga paghihigpit sa namespace (halimbawa, mula sa mga lalagyan ng Docker);
- Sa mga x86-64 system, ang SMAP (Supervisor Mode Access Prevention) bit ay sinusuri at inilapat, na idinisenyo upang harangan ang access sa data ng espasyo ng user mula sa privileged code na tumatakbo sa antas ng kernel. Ang proteksyon ng SMEP (Supervisor Mode Execution Prevention) ay ipinatupad dati;
- Sa panahon ng operasyon, ang mga setting ng LKRG ay inilalagay sa isang memory page na karaniwang read-only;
- Ang impormasyon sa pag-log na maaaring maging pinaka-kapaki-pakinabang para sa mga pag-atake (halimbawa, impormasyon tungkol sa mga address sa kernel) ay limitado sa debugging mode (log_level=4 at mas mataas), na hindi pinagana bilang default.
- Ang scalability ng database ng pagsubaybay sa proseso ay nadagdagan - sa halip na isang RB tree na protektado ng isang spinlock, isang hash table ng 512 RB tree na protektado ng 512 read-write lock ang ginagamit;
- Ang isang mode ay ipinatupad at pinagana bilang default, kung saan ang integridad ng mga identifier ng proseso ay kadalasang sinusuri lamang para sa kasalukuyang gawain, at opsyonal din para sa mga naka-activate (nakakagising) na gawain. Para sa iba pang mga gawain na nasa sleep state o gumagana nang hindi ina-access ang kernel API na kinokontrol ng LKRG, ang pagsusuri ay ginagawa nang mas madalas.
- Nagdagdag ng bagong sysctl at module na mga parameter para sa fine-tuning ng LKRG, pati na rin ang dalawang sysctl para sa pinasimpleng configuration sa pamamagitan ng pagpili mula sa mga set ng fine-tuning na mga setting (profile) na inihanda ng mga developer;
- Ang mga default na setting ay binago upang makamit ang isang mas balanseng balanse sa pagitan ng bilis ng pagtuklas ng mga paglabag at ang pagiging epektibo ng tugon, sa isang banda, at ang epekto sa pagganap at ang panganib ng mga maling positibo, sa kabilang banda;
- Ang systemd unit file ay muling idinisenyo upang i-load ang LKRG module nang maaga sa boot (isang kernel command line na opsyon ay maaaring gamitin upang hindi paganahin ang module);
Isinasaalang-alang ang mga pag-optimize na iminungkahi sa bagong release, ang pagbabawas ng performance kapag gumagamit ng LKRG 0.8 ay tinatantya sa 2.5% sa default mode (βmabigatβ) at 2% sa light mode (βmagaanβ).
Sa isang kamakailang ginanap pagiging epektibo ng mga pakete para sa pag-detect ng mga rootkit LKRG pinakamahusay na mga resulta, pagtukoy ng 8 sa 9 na nasubok na rootkit na gumagana sa antas ng kernel nang walang mga maling positibo (rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit at Sutekh ay natukoy, ngunit Keysniffer, na isang kernel module, ay napalampas gamit ang isang keylogger, hindi isang rootkit sa literal na kahulugan). Para sa paghahambing, ang mga pakete ng AIDE, OSSEC at Rootkit Hunter ay nakakita ng 2 sa 9 na rootkit, habang ang Chkrootkit ay walang nakitang anuman. Kasabay nito, hindi sinusuportahan ng LKRG ang pagtuklas ng mga rootkit na matatagpuan sa espasyo ng gumagamit, kaya nakakamit ang pinakamalaking kahusayan kapag gumagamit ng kumbinasyon ng AIDE at LKRG, na naging posible upang makilala ang 14 sa 15 rootkit ng lahat ng uri.
Bukod pa rito, mapapansin na ang developer ng pamamahagi nagsimula handa na mga pakete na may DKMS para sa Debian, Whonix, Qubes at Kicksecure, at isang pakete para sa na-update na sa bersyon 0.8. Available din ang mga package na may LKRG sa Russian ΠΈ .
Ang pagsuri ng integridad sa LKRG ay isinasagawa sa pamamagitan ng paghahambing ng aktwal na code at data ng kernel at mga module, ilang mahahalagang istruktura ng data at mga setting ng CPU na may mga nakaimbak na hash o mga kopya ng kaukulang mga lugar ng memorya, istruktura ng data o mga rehistro. Ang mga tseke ay isinaaktibo kapwa pana-panahon sa pamamagitan ng timer at sa paglitaw ng iba't ibang mga kaganapan.
Ang pagtukoy sa posibleng paggamit ng mga pagsasamantala at pagharang ng mga pag-atake ay isinasagawa sa yugto bago ang kernel ay nagbibigay ng access sa mga mapagkukunan (halimbawa, bago buksan ang isang file), ngunit pagkatapos na ang proseso ay makatanggap ng hindi awtorisadong mga pahintulot (halimbawa, pagbabago ng UID). Kapag natukoy ang hindi awtorisadong pag-uugali, ang mga proseso ay napipilitang wakasan bilang default, na sapat upang harangan ang maraming pagsasamantala.
Pinagmulan: opennet.ru