LINUX.ORG.RU

Linux Kernel Runtime Guard v0.3

 , , , ,


1

1

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

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

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

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

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

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

Deleted

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

Runtime

обеспечивающий контроль целостности

То есть тормозить нормальную работу ядра будет, да?

Deleted
()

Много безопасности не бывает.

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

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

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

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

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

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

Deleted
()

Microsoft (currently)

ха!

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

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

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

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

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

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

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

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

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

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

Но как ?

kto_tama ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

Лучше прочитать по ссылке. Там чётко сказано, что это приводило к false positive.

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

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

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

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

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

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

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

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

tomoyo

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

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

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

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

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

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

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

В чём альтернативность? Баг в ядре грозит кучей неприятностей. Баг в этой программке скорей всего грозит куда меньшими неприятностями.

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

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

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

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

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

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

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

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

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

Жесть, да. Не проще было какой-нибудь файловый дескриптор для этого сделать?

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

Ответ не верный. Верный - call_usermodehelper

И этот деятель что-то комитит для systemd...курам на смех.

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

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

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

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

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

Не, я к тому, что это задолго до 3.7 не нужно.

Хотя, честно говоря, я особой проблемы не вижу. Ну зовет ядро бинарник, чего тут такого. Главное привилегии дропать.

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

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

Thero ★★★★★
()

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

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

Deleted
()

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

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

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

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

По-поросячьи то орать умеет?

Да не упомяни поросят в суе

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

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

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

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

anonymous
()

Модуль ядра, который сам является эксплоитом?)

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

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

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

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

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

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

Нет. Ленин давно помер, ровно как его мертворожденные идеи-) Но тут речь о другом-)

ChAnton ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.