Исходное сообщение
"Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..." Отправлено solardiz, 28-Июн-20 01:03
LKRG не предназначен нарушать работу других модулей, в том числе что-то переопределяющих используя официальные API ядра. Он распознает некоторые атаки на ядро, где слово атака подразумевает что она осуществляется с неразрешенным пересечением уровня привилегий. Например, если простой пользователь эксплуатирует уязвимость в каком-нибудь системном вызове чтобы оттуда переписать свой euid в task_struct на 0 и затем попытается этим euid'ом воспользоваться, LKRG скорее всего это поймает и остановит. Загрузка модуля ядра корректно выглядящим root'ом (не полученным только что совершенной атакой на ядро) не относится к этой категории, здесь нет пересечения уровня привилегий. Помимо упомянутого, LKRG также распознает некоторые неразрешенные изменения ядра и модулей, то есть осуществляемые не через стандартные API. Например, он может распознать атаку которая перепишет не euid, а sys_call_table или кусок кода в ядре. Он также может распознать корректно загруженный модуль ядра, который сделает подобное - таким образом он смог распознать упомянутые в новости руткиты. Но если какой-либо модуль и загружен корректно (честно выглядящим root'ом) и ведет себя корректно, LKRG позволит ему работать. Если это нежелательно, есть возможность запретить загрузку модулей с помощью kernel.modules_disabled. Если же какой-нибудь руткит будет загружаться не как модуль (а через /dev/mem и т.п.), LKRG будет иметь выше шанс его поймать. Только для такой модели угроз и настроек системы нам надо еще добавить возможность запрета sysctl'ов LKRG. И да, если есть интерес к такой конфигурации системы, то мы подошли к теме securelevel (что всякий /dev/mem запретит, и останется загрузка руткитов только через уязвимости и через правку userspace, чтобы загрузиться при ближайшей перезагрузке системы). Адам исходно реализовал в LKRG аналог securelevel'а, но потом мы эту ветку забросили так как большинство установок этим бы не воспользовалось или же воспользовалось не всерьез (оставив обход через userspace). Я сам пользовался securelevel'ом и доводил его до ума в Linux 2.0, еще когда он там был под этим именем, но это или реально неудобно или не всерьез (по крайней мере, на серверах).

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> LKRG не предназначен нарушать работу других модулей, в том числе что-то переопределяющих > используя официальные API ядра. Он распознает некоторые атаки на ядро, где > слово атака подразумевает что она осуществляется с неразрешенным пересечением уровня привилегий. > Например, если простой пользователь эксплуатирует уязвимость в каком-нибудь системном > вызове чтобы оттуда переписать свой euid в task_struct на 0 и > затем попытается этим euid'ом воспользоваться, LKRG скорее всего это поймает и > остановит. Загрузка модуля ядра корректно выглядящим root'ом (не полученным только что > совершенной атакой на ядро) не относится к этой категории, здесь нет > пересечения уровня привилегий. > Помимо упомянутого, LKRG также распознает некоторые неразрешенные изменения ядра и модулей, > то есть осуществляемые не через стандартные API. Например, он может распознать > атаку которая перепишет не euid, а sys_call_table или кусок кода в > ядре. Он также может распознать корректно загруженный модуль ядра, который сделает > подобное - таким образом он смог распознать упомянутые в новости руткиты. > Но если какой-либо модуль и загружен корректно (честно выглядящим root'ом) и ведет > себя корректно, LKRG позволит ему работать. Если это нежелательно, есть возможность > запретить загрузку модулей с помощью kernel.modules_disabled. Если же какой-нибудь руткит > будет загружаться не как модуль (а через /dev/mem и т.п.), LKRG > будет иметь выше шанс его поймать. Только для такой модели угроз > и настроек системы нам надо еще добавить возможность запрета sysctl'ов LKRG. > И да, если есть интерес к такой конфигурации системы, то мы подошли > к теме securelevel (что всякий /dev/mem запретит, и останется загрузка руткитов > только через уязвимости и через правку userspace, чтобы загрузиться при ближайшей > перезагрузке системы). Адам исходно реализовал в LKRG аналог securelevel'а, но потом > мы эту ветку забросили так как большинство установок этим бы не > воспользовалось или же воспользовалось не всерьез (оставив обход через userspace). Я > сам пользовался securelevel'ом и доводил его до ума в Linux 2.0, > еще когда он там был под этим именем, но это или > реально неудобно или не всерьез (по крайней мере, на серверах).
	Введите код, изображенный на картинке: