LINUX.ORG.RU

Linux Kernel Runtime Guard v0.3

 , , , ,


0

1

Linux Kernel Runtime Guard (LKRG) ― это экспериментальный модуль ядра, обеспечивающий контроль целостности и обнаружение работы эксплоитов, направленных на пространство ядра.

Изменения с предыдущей версии:

  • Исправлена ошибка первого рода, вызванная потенциальным состоянием гонки, когда дочерний процесс может быть быстрее чем родительский процесс во время вызова fork().
  • Изменена логика и уровень протоколирования для сообщений, выводящихся в случае описанного состояния гонки в fork().
  • Измененены значения вероятностей во время запуска процедуры контроля целостности.

Как и ранее, этот релиз разработан Адамом «pi3» Заброцки. На этот раз это своего рода стабильный релиз. Также, недавно Адам рассказал о внутренней работе LKRG на конференции CONFidence в Кракове, Польша.

>>> Слайды с презентации

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Ответ на: удаленный комментарий

потому что появились новые векторы атаки от которых нельзя защититься другим способом( ну кроме того универсального уничтожить компьютер и тогда его не взломают).

Thero ★★★★★ ()
Ответ на: комментарий от Thero

Я о том, что нормальная работа ядра должна быть незаметна вообще. Там мини-микро-нано оптимизации на каждый чих чтоб пол байтика памяти сэкономить, а тут слона в посудную лавку приперли. Нате, преступники просто не влезут в ваше заведение.

rj45 ()
Ответ на: комментарий от rj45

Там мини-микро-нано оптимизации на каждый чих чтоб пол байтика памяти сэкономить

Спасибо, посмеялся.

Открою для тебя страшную тайну — иногда из ядра запускают бинарник в user space, который собирает данные из интерфейсов ядра вроде proc и потом вызывает через какой-нибудь netlink что-то в ядре.

Скажешь костыль? Но такой апстрим ядра :)

jollheef ★★★★★ ()
Ответ на: комментарий от jollheef

Открою для тебя страшную тайну — иногда из ядра запускают бинарник в user space, который собирает данные из интерфейсов ядра вроде proc и потом вызывает через какой-нибудь netlink что-то в ядре.

Ну, будем честны, есть fast path, а есть slow path. И fast path в ядре в последнее время стараются делать побыстрее.

kirk_johnson ★★ ()
Последнее исправление: kirk_johnson (всего исправлений: 1)

Исправлена ошибка первого рода, вызванная потенциальным состоянием гонки, когда дочерний процесс может быть быстрее чем родительский процесс во время вызова fork().

Но как ?

kto_tama ★★★★★ ()

Нужно и годно. Интересно, кто нибудь из лоровцев юзает? Какие отзывы? Интересует, LKRG влияет на отзывчивость системы? Тормозит нормальную работу ядра, или нет?

Odalist ★★★★★ ()
Последнее исправление: Odalist (всего исправлений: 1)
Ответ на: комментарий от jollheef

Скажешь костыль?

Судя по описанию — жуткий костыль. Вот именно для сбора данных не проще файлы изнутри открыть?

Но такой апстрим ядра

Пример показал бы, что ли.

i-rinat ★★★★★ ()
Ответ на: комментарий от kto_tama

Известно как - тормознуть дочерний процесс, ну так, на всякий случай. Ничего не жалко ради безопасности. Ну придется купить три сервера вместо двух, тоже мне, проблема.

araks ()
Ответ на: комментарий от jollheef

иногда из ядра запускают бинарник в user space, который собирает данные из интерфейсов ядра вроде proc и потом вызывает через какой-нибудь netlink что-то в ядре

называется init :)

intelfx ★★★★★ ()
Ответ на: комментарий от i-rinat

Вот именно для сбора данных не проще файлы изнутри открыть?

Читать файлы из ядра плохой тон, такие дела.

Пример показал бы, что ли.

security/tomoyo/load_policy.c, например. Было где-то ещё, но видимо уже переделали.

jollheef ★★★★★ ()
Последнее исправление: jollheef (всего исправлений: 1)
Ответ на: комментарий от jollheef

Читать файлы из ядра плохой тон, такие дела.

Лучше так, чем запуск в юзерспейсе программы, которая делает то же самое. Не думаю, что в апстрим такая дикость пройдёт.

tomoyo

У безопасников всегда альтернативная логика.

Хотя там тоже понятно, зачем — для конфигурации. Не в ядро же намертво вкомпиливать.

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 2)

а кто будет обеспечивать/проверять целостность памяти этого «Linux Kernel Runtime Guard v0.3»

нужен новый модуль для этого, потом модуль для модуля, и модуль для модуля модуля... ну вы поняли

чтото на уровне изобретения вечного двигателя на постоянных магнитах, может даже выше
(усложняя конструкцию крайний элемент всеравно остается)

missxu ()
Ответ на: комментарий от i-rinat

Хотя там тоже понятно, зачем

Так и мне понятно, зачем и почему. Это я исходным постом хотел объяснить человеку, что он слишком многое возлагает на ядро и его разработчиков.

jollheef ★★★★★ ()
Ответ на: комментарий от i-rinat

Пример показал бы, что ли.

Тебе обязательно из актуального ядра? Если нет, тогда держи

До ЕМНИП 3.7 был uevent helper(обычно /sbin/hotplug), путь к которому прописывался в ядре. Выпилен в том числе из-за того что тормоза, вот это вот всё.

P.S. Лол, не заметил что в современном конфиге ядра эта строчка всё еще есть, я как выпилил её, так и не вспоминал. А говорят stable api nonsense :-)

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

Так я и не говорю что в современном ядре такое везде. Но и отрицать очевидное - глупо. Да, была такая практика, да, от этого уходят.

Но в результате сохранения обратной совместимости(и нет, я не говорю что это что-то плохое, как раз наоборот) это просуществовало как видишь очень долго.

Возможно в каких-то сурово ынтерпрайзных драйверах(или лютом быдлокоде, что иногда, увы, одно и то же) такое и сейчас есть. Но это не повод говорить что это хорошо.

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)

Мысль, конечно, интересная, но...

За пару последних лет столько уже было потайных эксплойтов, замаскированных под вполне мирные софтины, что я одно время устал от них отбиваться.

rht ★★★★★ ()

Идея интересная но непонятно кому нужная. Типа мы строим критически важные, как нам кажется, структуры данных по системным вызовам и сравниваем их с теми которые находятся в ядре. Может это кого и спасет. Интересно от каких конкретно эксплоитов эта штука защищает и не проще ли пофиксить вместо этого ядро.

A-234 ★★★★★ ()
Ответ на: комментарий от anonymous

ой-ой.. кто-то не согласен что линукс - это просто зомби ходячий, с разлагающимся кодом.. ... антивирус встроить с ядро, вместо того, чтобы перейти на другой язык... ололололо

anonymous ()
Ответ на: комментарий от ChAnton

селинукс не контролирует целостность. Он контролирует доступ. По сути селинукс просто расширенная система аутентификации взамен стандартной.

anonymous ()
Ответ на: комментарий от anonymous

селинукс не контролирует целостность. Он контролирует доступ. >>По сути селинукс просто расширенная система аутентификации >>
взамен стандартной.

Не совсем так, selinux скорее БЕРЕЖЕТ целостность, а контролировать ее - задача отнюдь нетривиальная, потому как например кто будет контролировать уже целостность указанной утилиты ядра?) А потому такая избыточность может быть излишней и даже вредной, тут достаточно selinux как защитника целостности.

ChAnton ()