Проект Openwall опубликовал (https://www.openwall.com/lists/lkrg-users/2019/02/19/1) выпуск модуля ядра LKRG 0.6 (http://www.openwall.com/lkrg/) (Linux Kernel Runtime Guard), обеспечивающего выявление несанкционированного внесения изменений в работающее ядро (проверка целостности) или попыток изменения полномочий пользовательских процессов (определение применения эксплоитов). Модуль подходит как для организации защиты от уже известных эксплоитов для ядра Linux (например, в ситуациях когда в системе проблематично обновить ядро), так и для противостояния эксплоитам для ещё неизвестных уязвимостей. Об особенностях LKRG можно прочитать в первом анонсе проекта (https://www.opennet.ru/opennews/art.shtml?num=47989).
В новой версии для systemd подготовлен unit-файл для инициализации LKRG на начальной стадии загрузки, а также предложены сборочные опции для его установки и удаления. В подсистеме проверки целостности переработана поддержка меток перехода (*_JUMP_LABEL (http://openwall.info/wiki/p_lkrg/Main#JUMP_LABEL)) и обеспечена защита битов
SMEP (Supervisor Mode Execution Protection, 20 бит в регистре CR4) и WP (Write Protect, 16 бит в регистре CR0) для систем с архитектурой x86.
В коде определения применения эксплоитов при помощи pCFI (вариант Control Flow Integrity (https://ru.wikipedia.org/wiki/Control-flow_integrity)) реализована защита против эксплуатации через непреднамеренный вызов функций ядра в качестве ROP-гаджетов (https://ru.wikipedia.org/wiki/%D0%92%D0%.... Доступ к интерфейсу usermodehelper ограничен только для приложений из белого списка. Ограничение usermodehelper вместе с pCFI позволили блокировать один из методов обхода LKRG. Для исключения ложных срабатываний обеспечено замораживание всех пользовательских процессов во время инициализации LKRG. Решены проблемы со сборкой в ядрах Linux 4.17+ при включении опции CONFIG_ARCH_HAS_SYSCALL_WRAPPER.URL: https://www.openwall.com/lists/lkrg-users/2019/02/19/1
Новость: https://www.opennet.ru/opennews/art.shtml?num=50175
Это что, антивирус?!
Нет, это Патрик.
> Это что, антивирус?!не антивирус, а система защиты затрудняющая эксплуатацию дырок
Каков урон производительности при этом?
Типично от долей процента до единиц процентов. Иногда наблюдается даже повышение производительности, что говорит о том что урон сравним с шумом от случайных изменений (расположения компонентов системы в памяти) между перезагрузками системы и т.п. Некоторые результаты тестов есть в файле PERFORMANCE в архиве с релизом и тут: https://www.openwall.com/presentations/CONFidence2018-LKRG-U...
> Иногда наблюдается даже повышение производительностиОй, а за счёт чего так? (не нашёл в PERFORMANCE)
Повторюсь, но: за счет того, что урон сравним со "случайными" колебаниями, происходящими по независящим от LKRG по сути причинам. Если просто сравнивать производительность системы между ее разными перезагрузками, при разных загруженных модулях, запущенных спящих программах, то на многих аппаратных платформах результаты будут колебаться в пределах нескольких процентов (а на некоторых и хуже, иногда гораздо хуже). На некоторых получается даже как-бы стабильный эффект (пока не поменяешь что-то еще - например, версию ядра), что загрузка модуля LKRG дает плюс чуть-чуть. Но это не значит, что LKRG такой прям ускоритель. Это просто так карты^Wадреса легли. Почему изменения адресов могут такое давать? Думаю, в основном из-за низкой ассоциативности различных кешей, включая TLB. В PERFORMANCE результаты с системы, где этого эффекта почти не было. Такой эффект был, например, на лаптопе Адама, но мы те результаты не опубликовали. Сейчас посмотрел на его свежие результаты по pCFI в VM на лаптопе - там в одном тесте ускорение на 9%, а в худшем замедление всего лишь на 1.6%. Но мы же не станем говорить, что LKRG в среднем ускоряет компьютер. Мы понимаем, что это сочетание разных эффектов.
> Это просто так карты^Wадреса легли.А, то есть ещё один фактор и разлёт измеряемого вследствие остальных, превышающий влияние этого.
> Мы понимаем, что это сочетание разных эффектов.
Понял, спасибо.
Ой какой сообразительный. Всегда приятно знать что мои посты удаляет более умный человек чем я.
Я не люблю давать советов, когда не просят, но... давайте я это изложу как пожелание: можно не только среднее указывать в результатах, но ещё и дисперсию. Такая штука позволит видеть размеры ошибок и насколько вообще эти средние о чём-либо говорят (может быть случайный шум больше измеряемой разницы?). Кроме того, различия дисперсии задержек в экспериментальном сетапе и в контрольном -- это тоже очень полезная информация, если мы говорим о производительности.
Спасибо. В файле PERFORMANCE сейчас даны не только средние, но и отдельные результаты 10-ти тестов для каждого случая. Думаю, это в целом показывает картину. Важно еще то, что измеряем мы на конкретном тесте, тогда как реальное использование систем будет сильно отличаться, как впрочем и сами системы. Так что эти тесты - лишь чтобы показать общую картину и чтобы сравнивать разные версии и настройки LKRG друг с другом.
На надо дисперсию, пусть всю гистограмму дают.
> На надо дисперсию, пусть всю гистограмму дают.Гистограмма -- это уже график. Это дополнительные геморрои. Дисперсию же посчитать не сложнее чем среднее, и добавить её в табличку данных тоже несложно.
Если же рисовать картинки, то мне больше нравятся доверительные интервалы. Восприятие гистограммы более субъективно, нежели восприятие доверительных интервалов.
вы бы тут еще и на стат анализ ссылочек понакидали, если кто не в курсе
Для проверки простых моделей (сводящихся к утверждениям вида "что-то одно всегда лучше другого на N%") достаточно сигму смотреть https://ru.wikipedia.org/wiki/%D0%A1%D1%...
а как же коэффициент корреляции, или мат ожидание?
> а как же коэффициент корреляции, или мат ожидание?Что, много букф? По ссылке, внизу указатели на "продолжение осмотра".
А то давайте сразу "кто не в курсе" посылать к Семендяеву унд Бронштейну. Или в http://natribu.org/
А лучше не поленитесь оставить свой вариант ссылочек для интересующихся. Вдруг кому пригодится?
так я и предложил Ordu оставить ссылочку на стат анализ, для тех кто не в курсе.
Я не знаю что посоветовать. Обычно в таких случаях люди рекомендуют всем повторить их путь, но здесь это не очень работает, я довольно долго добирался до статистике. Прошёл когда-то по касательной к матстатистике копая тему принятия решений в неопределённых условиях, а потом туда погрузился через курс экспериментальной психологии, курс матстатистики (в смысле теоретической математики), затем курс матметодов в психологии, а потом через практику и подражание (научнику, коллегам по лабе, докладчикам с конференций, чтение статей о психологических исследованиях). Из этого пути, я думаю, принятие решений в неопределённых условиях можно выкинуть; теоретический курс математики, пожалуй тоже; эксперименталку, с меньшей уверенностью, но, наверное, туда же.И если так, то остаются матметоды и практика. С матметодами есть неплохая книженция Наследова: "математические методы психологического исследования". Книжка легко гуглится. Психология там не должна пугать, её по сути нет, только методы. Она даёт всю необходимую базу, для того чтобы матстатистика не выглядела бы как беспорядочный сборник костылей для разных случаев. То есть матстатистика и есть такой сборник костылей, но Наследов это укладывает в некое подобие системы. После этого уже не чувствуешь себя безнадёжным болваном, когда в очередной раз сталкиваешься с каким-нибудь методом, про который раньше не слышал даже. Что мне не нравится в этой книге, так это то, что там когда речь заходит о практическом применении методов, то в качестве инструмента используется SPSS, а не R. R придётся осваивать отдельно. Но всякие туторы по R неплохо заходят после наследова.
А практика... В качестве практики надо найти какой-то класс задач, который интересен и релевантен. Желательно достаточно популярен, чтобы были бы полноценные научные статьи на эту тему и способ эти научные статьи находить: просто если они в elsevier'е где-нибудь, оттуда их разве что через sci-hub выковыривать, если другим образом доступа получить не удалось, а в sci-hub сложно искать статьи -- можно по названию, но так чтобы "дай мне все статьи за последние полгода из данной области, да отсортируй их по частоте цитирования" -- это не. Но главное -- это должна быть тема, которая требует применения матстатистики и которая достаточно интересна, чтобы её можно было бы систематически копать.
Гистограмма - это не график. Это пары значений "границы корзины" - "количество элементов, попавших в корзину". Если это нормировать на число элементов, то будет аппроксимация плотности вероятности - а это уже значит, что мы приблизительно знаем распределение. А знание распределения это > чем знание среднего. Проблема тут в выботе корзин, но есть алгоритмы, генерирующие корзины из самих точек.
все есть график, если это "рисуется", любой график зависимости можно представить в виде таблицы "пара-значение"
Подскажите, кто в курсе. Сие только для x86\AMD64? На Power & K распространяется?
Пока только x86(-64), но поддержка других архитектур может быть добавлена при наличии спроса, особенно коммерческого (какой-нибудь "cloud" провайдер на Aarch64, какой-нибудь производитель телефонов на Android и т.п.) Причем добавлена она может быть легко, но частично (путем исключения специфичной для x86(-64) функциональности при сборке под другие архитектуры) или сложно, но полностью (путем добавления аналогичной функциональности для конкретных других архитектур). Вот ответ Адама на схожий вопрос: https://www.openwall.com/lists/lkrg-users/2018/07/31/3
Частичная поддержка мониторинга целостности лучше всё-таки, чем никакой. И, если это и правда несложно, то можно добавить поддержку POWER хотя бы?В любом случае, спасибо за вашу работу!
Вы будете использовать LKRG на POWER, если мы добавим поддержку? Можете рассказать подробнее? В любом случае, боюсь Адаму будет негде это тестировать, кроме как в QEMU. Так что пока вот добавили AArch64, может быть добавим 32-битный ARM.
На одной из железок https://www.raptorcs.com/content/base/products.html (наверное, подожду рабочей станции на POWER10, но, может, и Blackbird возьму). Машины достаточно мощные, и думаю, что сервера на них обретут ограниченную популярность.
А так, я бы использовал и на MIPS, и на SPARC,но это специфично и едва ли интересно тем, у кого нет Yeelong и Ultra.
Кстати, интересно, как архитектура повлияет на производительность. Надеюсь, что накладные расходы останутся низкими.
А вот и новые обходы от Ильи:
Илья молодец, спасибо ему. Я только что прокомментировал новые обходы там дальше по треду: думаю, нам надо будет считать такие обходы выходящими за рамки предоставляемой LKRG защиты как минимум на системах/VM'ах без SMEP, а также усилить защиту бита SMEP (пока что очень слабую). Любопытно, что сегодня же Kees Cook предложил в upstream-ядрах устранить gadget, типично используемый эксплойтами (в том числе этим) для выключения SMEP. Может быть, LKRG привнесет аналогичное изменение и в старые ядра.
solardiz, вижу https вы таки наладили. Спасибо. А планируются ли оффициальные пакеты?
Бинарные пакеты LKRG, если когда-либо будут, скорее всего окажутся специфичными для конкретных версий конкретных дистрибутивов, а возможно и для конкретных сборок ядра. В ближайших планах их нет, но есть вариант в отдаленном будущем сделать такие сборки под какие-нибудь enterprise'ные дистрибутивы в платном LKRG Pro - как способ финансирования проекта, не связанный с каким-либо урезанием функциональности бесплатного LKRG и позволяющий использовать свободную лицензию (сейчас это GPLv2) и для LKRG Pro (который в таком случае будет лишь проверенной нами сборкой LKRG). Нужны ли бинарные пакеты кроме как под enterprise дистрибутивы и бесплатно? Какие, кому и зачем, учитывая разнообразие версий и сборок ядер, которые нам пришлось бы поддерживать? Пока нам представляется проще нынешний вариант, когда пользователь дает команду make сам и получает сборку под своё ядро. В этом контексте, мы также рассматриваем добавление рандомизации при сборке, что даст пользовательским сборкам некоторое преимущество по безопасности перед заранее подготовленными и у всех одинаковыми пакетами.
> Бинарные пакеты LKRG, если когда-либо будут, скорее всего окажутся специфичными для конкретных
> версий конкретных дистрибутивов, а возможно и для конкретных сборок ядра.
> разнообразие версий и сборок ядер, которые нам пришлось бы поддерживатьа dkms использовать?
Спасибо. Мы пока не рассматривали вариант использовать DKMS, но может быть.
Когда в прошлом году я пробовал LKRG на своем ноуте, то он начинал с материться про взлом поле выхода ноута из спящего режима. Как с этим в новой версии? У меня, к сожалению, сейчас нет времени для теста (
Знаем об этой проблеме. Проявляется не на всяком железе, что усложняет проверку возможных исправлений. Пока не исправили. Когда исправим, напишем об этом в CHANGES.