The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимостей в ядре Linux

27.06.2020 12:52

Проект Openwall опубликовал выпуск модуля ядра LKRG 0.8 (Linux Kernel Runtime Guard), предназначенного для выявления и блокирования атак и нарушений целостности структур ядра. Например, модуль может защитить от несанкционированного внесения изменений в работающее ядро и попыток изменения полномочий пользовательских процессов (определение применения эксплоитов). Модуль подходит как для организации защиты от уже известных эксплоитов для ядра Linux (например, в ситуациях когда в системе проблематично обновить ядро), так и для противостояния эксплоитам для ещё неизвестных уязвимостей. Код проекта распространяется под лицензией GPLv2.

Среди изменений в новой версии:

  • Изменено позиционирование проекта LKRG, который теперь не разделяется на отдельные подсистемы для проверки целостности и определения применения эксплоитов, а преподносится как цельный продукт для выявления атак и различных нарушений целостности;
  • Обеспечена совместимость с ядрами Linux с 5.3 по 5.7, а также с ядрами, собранными с агрессивными оптимизациями GCC, без опций CONFIG_USB и CONFIG_STACKTRACE или с опцией CONFIG_UNWINDER_ORC, а также с ядрами, в которых отсутствуют перехватываемые LKRG функции, если без них можно обойтись;
  • При сборке обеспечена проверка некоторых обязательных настроек ядра CONFIG_* для формирования осмысленных сообщений об ошибках вместо неясных сбоев;
  • Добавлена поддержка ждущего (ACPI S3, suspend to RAM) и спящего (S4, suspend to disk) режимов;
  • В Makefile добавлена поддержка DKMS;
  • Реализована экспериментальная поддержка 32-разрядных платформ ARM (протестировано на Raspberry Pi 3 Model B). Ранее доступная поддержка AArch64 (ARM64) дополнена обеспечением совместимости с платой Raspberry Pi 4;
  • Добавлены новые обработчики (hook), в том числе обработчик вызова capable() для лучшего определения эксплоитов, манипулирующих "capabilities", а не идентификаторами процессов (credentials);
  • Предложена новая логика определения попыток выхода из ограничений пространств имён (например, из контейнеров Docker);
  • На системах x86-64 обеспечена проверка и применение бита SMAP (Supervisor Mode Access Prevention), предназначенного для блокирования доступа к данным в пространстве пользователя из привилегированного кода, выполняемого на уровне ядра. Защита SMEP (Supervisor Mode Execution Prevention) была реализована ранее;
  • В процессе работы обеспечено размещение настроек LKRG в странице памяти, обычно доступной только для чтения;
  • Вывод в логи сведений, которые могут быть наиболее полезны для атак (например, информация об адресах в ядре), ограничен отладочным режимом (log_level=4 и выше), отключенным по умолчанию.
  • Повышена масштабируемость БД отслеживания процессов - вместо одного дерева RB, защищаемого одним spinlock, задействована хэш таблица из 512 деревьев RB, защищённых соответственно 512 блокировками чтения-записи;
  • Реализован и включён по умолчанию режим, при котором проверка целостности идентификаторов процесса часто выполняется только для текущей задачи, а также опционально для активируемых (просыпающихся) задач. Для остальных задач, находящихся в состоянии сна или работающих без обращения контролируемому в LKRG API ядра, проверка выполняется реже.
  • Добавлены новые sysctl и параметры модуля для тонкой настройки LKRG, а также два sysctl для упрощенной настройки путем выбора из подготовленных разработчиками наборов тонких настроек (profiles);
  • Настройки по умолчанию изменены для достижения более взвешенного баланса между оперативностью выявления нарушений и эффективностью реакции с одной стороны, и влиянием на производительность и риском ложных срабатываний с другой;
  • Unit-файл systemd переработан для загрузки модуля LKRG на раннем этапе загрузки (для отключения модуля может использоваться параметр командной строки ядра);

С учётом предложенных в новом выпуске оптимизаций снижение производительности при применении LKRG 0.8 оценивается на уровне 2.5% в режиме по умолчанию ("heavy") и 2% в облегченном режиме ("light").

В недавно проведённом исследовании эффективности пакетов для выявления руткитов LKRG показал лучшие результаты, без ложных срабатываний определив 8 из 9 протестированных руткиков, работающих на уровне ядра (были выявлены руткиты Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit и Sutekh, но пропущен Keysniffer, который является модулем ядра с кейлоггером, а не руткитом в прямом смысле). Для сравнения, пакеты AIDE, OSSEC и Rootkit Hunter выявили 2 руткита из 9, а Chkrootkit не выявил ни одного. При этом LKRG не поддерживает определение руткитов, размещаемых в пространстве пользователя, поэтому наибольшая эффективность достигается при использовании связки AIDE и LKRG, позволившей выявить 14 из 15 руткитов всех типов.

Дополнительно можно отметить что разработчик дистрибутива Whonix начал формирование готовых пакетов с DKMS для Debian, Whonix, Qubes и Kicksecure, а пакет для Arch Linux уже обновлен до версии 0.8. Пакеты с LKRG также присутствуют в российских ALT Linux и Astra Linux.

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

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

  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: Выпуск модуля LKRG 0.7 для защиты от эксплуатации уязвимостей в ядре Linux
  3. OpenNews: В ядро Linux 5.4 приняты патчи для ограничения доступа root к внутренностям ядра
  4. OpenNews: Проект Openwall подготовил модуль для защиты от эксплуатации уязвимостей в ядре Linux
  5. OpenNews: Экспериментальная поддержка пересборки ядра Linux в Clang с механизмом защиты CFI
  6. OpenNews: Проблемы с безопасностью в патчах, предложенных сотрудником Huawei для защиты ядра Linux
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/53244-lkrg
Ключевые слова: lkrg, kernel, linux, protect
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (81) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 13:56, 27/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Вот будет номер, когда в модуле для защиты от эксплуатации уязвимостей найдут эксплуатируемую уязвимость. Будет модуль превентивного вторжения.
     
     
  • 2.4, Аноним (4), 14:04, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Уже тыщу раз такое было, обычно дыры находят в патчах для "защиты" правда.
     
     
  • 3.12, solardiz (ok), 15:20, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +18 +/
    Понимаю дежурную иронию, которую мы здесь видим в комментариях почти на каждый анонс очередной версии LKRG, особенно в контексте регулярных подобных новостей про другие проекты. Современные ядра Linux слишком сложны, из-за чего в них присутствует огромное количество еще не выявленных уязвимостей. На фоне этого даже наличие в модуле защиты еще небольшого их количества существенно не ухудшит ситуацию в целом (кроме как в плане иронии), в то время как защита может помочь - в зависимости от того какие уязвимости и как реально будут пытаться эксплуатировать на конкретной системе. Мы с самого начала проекта указываем на домашней странице LKRG, что он может содержать ошибки и уязвимости, и рекомендуем взвесить пользу и риски от его использования в конкретной ситуации. LKRG наиболее актуален там, где вероятно что ядро не будет своевременно обновлено. LKRG наиболее неприятен риском ложных срабатываний. За 2.5 года публичного существования проекта уязвимостей в Linux выявлено полно, а в LKRG ни одной. Разумеется, это может измениться. Чтобы иметь шанс на отсутствие серьезных уязвимостей, надо использовать системы гораздо проще чем Linux (кстати, LKRG гораздо проще чем Linux и чем многие другие средства защиты, такие как "антивирусы" под Windows). Альтернативой же является принятие вероятного наличия уязвимостей и использование нескольких уровней защиты (что к сожалению еще более усложняет систему в целом) и/или готовность своевременно обновлять компоненты на хотя бы части уровней. Это нынешняя реальность.
     
     
  • 4.17, Аноним (17), 15:40, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Приятно вас почитать.

    Правильно понимаю, что сейчас может быть безопаснее использовать mainline ядра, чем стабильные и лонгтерм?

     
     
  • 5.22, solardiz (ok), 16:17, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это сложная тема, связанная не только с ростом сложности ядер, но и с конкретными процессами разработки (какие исправления распознаются и помечаются как требующие back-port'ов и что потом реально делается в отношении каких веток). Я не возьмусь однозначно сравнить mainline/stable/LTS ветки от kernel.org. По мне, на данный момент ядра в RHEL7 находятся в близкой к оптимальной стадии - многое уже вычищено, а поддержка еще будет. Кстати, LKRG поддерживает ядра начиная как раз с RHEL7. См. по теме: https://www.openwall.com/lists/oss-security/2018/12/12/3 и до конца треда https://www.openwall.com/lists/oss-security/2018/12/14/7 где я очень мягко попросил Greg'а уточнить его нонсенс, что он не стал делать. (Greg поддерживает stable ветки от kernel.org, за что ему искреннее спасибо.)
     
     
  • 6.26, Аноним (17), 16:49, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Спасибо, интересно было почитать.

     
  • 6.37, Аноним (37), 21:29, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ходят слухи, возможно даже от вас, что вы планируете перестать заниматься linux-related проектами. Если это так, то что будет дальше? Типичные виндозно-макосятные [анти]вирусы?
     
     
  • 7.42, solardiz (ok), 22:55, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не слышал о таких слухах Разве что я здесь в одном из комментариев упоминал воз... большой текст свёрнут, показать
     
     
  • 8.53, Аноним (53), 03:32, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно Спасибо за развёрнутый ответ А чем угодил или не угодил QubesOS Про... текст свёрнут, показать
     
     
  • 9.61, solardiz (ok), 13:10, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Про QubesOS сейчас расписывать не стану - off-topic, некогда Насчет BSD и гипер... текст свёрнут, показать
     
  • 4.54, text (?), 03:46, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    " За 2.5 года публичного существования проекта уязвимостей в Linux выявлено полно, а в LKRG ни оной." - а сколько людей искало в 1 и 2 случаях ? каково отношение "ищущие в Linux "/"ищущие в LKRG "
     
     
  • 5.63, solardiz (ok), 14:12, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да, есть такое очевидное отличие. Но с точки зрения вероятности неприцельных атак на вовремя не обновленные системы за этот период, наиболее важны опубликованные уязвимости.
     

  • 1.2, Мордиум (?), 14:00, 27/06/2020 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –1 +/
     
     
  • 2.3, Мордиум (?), 14:01, 27/06/2020 Скрыто модератором
  • +3 +/
     
  • 2.11, Аноним (11), 15:03, 27/06/2020 Скрыто модератором
  • +1 +/
     
     
  • 3.15, Аноним (17), 15:35, 27/06/2020 Скрыто модератором
  • +1 +/
     
     
  • 4.20, Аноним (11), 15:51, 27/06/2020 Скрыто модератором
  • +1 +/
     
  • 2.16, Аноним (17), 15:35, 27/06/2020 Скрыто модератором
  • +1 +/
     

     ....ответы скрыты модератором (5)

  • 1.5, Fracta1L (ok), 14:04, 27/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Интересно, сильно ли оно тормозит работу системы
     
     
  • 2.30, solardiz (ok), 18:15, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Из текста новости: снижение производительности при применении LKRG 0.8 оценивается на уровне 2.5% в режиме по умолчанию ("heavy") и 2% в облегченном режиме ("light"). Результаты отдельно по 58 тестам из Phoronix Test Suite, которые сильно отличаются друг от друга, см. в файле PERFORMANCE.
     

  • 1.6, Аноним (6), 14:10, 27/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Была попытка включить модуль в ядро? Что ответили ядерщики?
     
     
  • 2.9, solardiz (ok), 14:34, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Такой попытки не было и пока не планируется. Соответственно, ничего не ответили.
     
     
  • 3.14, Аноним (14), 15:34, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А официально в дистры?
     
     
  • 4.24, solardiz (ok), 16:25, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Да, возможно, кто-то из участников сообщества или разработчиков LKRG возьмется за его поддержку в каких-либо дистрибутивах. Вот обсуждение про Debian: https://www.openwall.com/lists/lkrg-users/2020/06/21/7 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944476 где Mariusz Zaborski, недавно присоединившийся к разработке LKRG, брался за back-port'ы для Debian в случае включения пакета. Посмотрим.
     
  • 4.33, Michael Shigorin (ok), 19:48, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +10 +/
    http://packages.altlinux.org/ru/search?query=lkrg
     
     
  • 5.35, тот_же_анон_уже_без_мабилы (?), 20:25, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    давайте проплюсуем Мишу
     
  • 5.59, Аноним (59), 09:15, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    АЛЬТ собирается в ядра добавлять:

    KSPP: https://www.kernel.org/doc/html/latest/security/self-protection.html
    YAMA: https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html

    Может даже GrSecurity добавите?

     
     
  • 6.67, Michael Shigorin (ok), 11:29, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > АЛЬТ собирается в ядра добавлять:
    > YAMA: https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html

    ---
    CONFIG_SECURITY_YAMA=y
    --- http://git.altlinux.org/gears/k/kernel-image-std-def.git?p=kernel-image-std-d

    > KSPP: https://www.kernel.org/doc/html/latest/security/self-protection.html

    Частично учтено; см. там же.

    > Может даже GrSecurity добавите?

    Не вижу, как бы это было возможно (и не уверен, что наши ядерщики бы стали -- но это лучше ldv@ спросить, если вопрос по существу).

    Насчёт "частично" им на всякий передал, спасибо.

     
  • 2.13, анонимус (??), 15:32, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если оно станет популярным, а тем более попадет как опция в ядро, эффективность против ItW заразы упадет очень сильно, ведь сложность обхода часто не велика (https://github.com/milabs/lkrg-bypass). А пока прекрасно работает принцип security by obscurity..
     
     
  • 3.18, solardiz (ok), 15:44, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Мы это называем security through diversity. Это одна из причин почему мы не подаем LKRG для включения в ядро, хотя кроме сложности обхода есть и другие аспекты, влияющие на успешность атак in the wild (переносимость exploit'а между версиями ядра, вероятность его успешной работы с первого раза), на которые также влияет LKRG.
     
     
  • 4.21, Аноним (14), 15:58, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Through diversity - это ASLR.
     
     
  • 5.25, solardiz (ok), 16:26, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, и это тоже.
     
  • 4.31, Мордиум (?), 19:01, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Напомните, кажется Alex Matrsov из hardwear.io делал пен-тесты и ему понравилась как LKRG отмела уязвимости.

    Не могу найти или вспомнить, он ли это был, и где это было...

    Может поделитесь ссылкой.

     
     
  • 5.40, solardiz (ok), 22:30, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    К сожалению, не знаю о чем это. Он тоже не знает.
     
     
  • 6.47, Мордиум (?), 00:25, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да, значит путаю, может это был Richard Hughes который lvfs и gnome, не буду гадать, ладно.
     
  • 3.65, Аноним (65), 09:55, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А вот и разгадка:

    >As free LKRG becomes somewhat popular and maybe a target of some exploits, we might introduce paid LKRG Pro

     

  • 1.7, анон (?), 14:15, 27/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что будет если наплодить процессов которые будут делать for (;;) setuid(0);
    Как-там проверка целостности в ядре работать будет?
     
     
  • 2.8, Аноним (8), 14:33, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А в чем проблема?
     
  • 2.10, solardiz (ok), 14:38, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ничего примечательного не будет. Система будет работать примерно так же, как и без LKRG. Проверка целостности всего ядра не станет выполняться неразумно часто. Проверка целостности параметров конкретно этих процессов будет выполняться чаще, но в их же контекстах, так что это никому не помешает и загрузку системы не повысит (они и так гоняют холостые циклы).
     

  • 1.19, Аноним (14), 15:45, 27/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Для защиты Android от Qualcommо- и Broadcomогoвна подойдёт?
     
     
  • 2.29, solardiz (ok), 17:54, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Предполагаю, что речь об атаках на Android, выполняемых из уязвимого кода прошивок сетевых "чипов". LKRG может распознать модификацию ядра Linux, осуществленную через запись в общую память из "чипа", имеющего такой доступ. LKRG может в таком случае быстро сделать kernel panic. Наверное, это поможет от атак, которые не направлены (почти) сразу на Android'овый userspace, а (сначала) модифицируют работающее ядро (и не успевают за несколько секунд закрепиться в userspace, чтобы после перезагрузки активироваться уже оттуда).
     

  • 1.32, Онаним (?), 19:42, 27/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Когда уже: выпуск модуля для защиты от эксплуатации уязвимостей в модуле для защиты от эксплуатации уязвимостей в ядре Linux?
     
     
  • 2.34, Michael Shigorin (ok), 19:51, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Когда уже: выпуск модуля для защиты от эксплуатации уязвимостей
    > в модуле для защиты от эксплуатации уязвимостей в ядре Linux?

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

     

  • 1.38, онанимуз (?), 21:44, 27/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    отличный проект. хорошо, что починили суспенды, а то на ноутбуке модуль постоянно с ума сходил.

    > С учётом предложенных в новом выпуске оптимизаций снижение производительности при применении LKRG 0.8 оценивается на уровне 2.5% в режиме по умолчанию ("heavy") и 2% в облегченном режиме ("light").

    выключил все защиты от спектров и мелт даунов, включил LKRG => увеличение производительности на уровне 5%, а защита от хеккеров такая же, если не лучше.

     
     
  • 2.39, Аноним (39), 22:08, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Надо срочно сообщить в Intel, а то они там мучаются патчи замедляющие штампуют
     
     
  • 3.60, ananim (?), 10:34, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    то чувство, когда сарказм - это внезапно не сарказм.
     

  • 1.41, Павел Отредиез (?), 22:41, 27/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Про capabilities, дак лучше неиспользуемые вообще отключать переходом в securelevel. Что вы делаете на вызов cap_capable?
     
     
  • 2.43, solardiz (ok), 23:06, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Проверяем, что capabilities процесса всё еще соответствуют сохраненным сразу после их корректного изменения одним из предназначенных для этого вызовов. Делаем эту проверку до того как capable(), возможно, подтвердит что процесс имеет право сделать что-то привилегированное. Про неиспользуемые и securelevel - отдельная тема, здесь не об этом.
     
     
  • 3.44, Павел Отредиез (?), 23:13, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Понятно. Вы используете security hooks и ваш модуль оформлен как модуль, я правильно понимаю? Насколько я помню старые версии ядер часть security, не пришлось ли вам экспортировать некоторые символы ядра, а то это не очень разрешено по моему мнению?
     
     
  • 4.46, solardiz (ok), 23:57, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Используем kprobes. Оформлен как модуль. Экспорт самим ядром мы не трогаем, но для отдельных символов нам приходится использовать kallsyms_lookup_name, а его самого (начиная с 5.7, где его перестали экспортировать) находить с помощью kprobes же. Конечно, это выходит за рамки официального API.
     
     
  • 5.48, Павел Отредиез (?), 00:26, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Используем kprobes. Оформлен как модуль. Экспорт самим ядром мы не трогаем, но
    > для отдельных символов нам приходится использовать kallsyms_lookup_name, а его самого
    > (начиная с 5.7, где его перестали экспортировать) находить с помощью kprobes
    > же. Конечно, это выходит за рамки официального API.

    Если это возможно вашему модулю, то возможно security hooks и другому модулю. Вот и можно предположить почему модуль-эксплоит успешен, он переопределил хуки.

     
     
  • 6.50, solardiz (ok), 01:03, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    LKRG не предназначен нарушать работу других модулей, в том числе что-то переопре... большой текст свёрнут, показать
     
  • 5.49, Павел Отредиез (?), 00:42, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Используем kprobes. Оформлен как модуль. Экспорт самим ядром мы не трогаем, но
    > для отдельных символов нам приходится использовать kallsyms_lookup_name, а его самого
    > (начиная с 5.7, где его перестали экспортировать) находить с помощью kprobes
    > же. Конечно, это выходит за рамки официального API.

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

     
     
  • 6.51, solardiz (ok), 01:18, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Мы не используем security hooks и не возвращаем разрешения/запреты. Мы перехватываем наиболее актуальные нам функции и сами отвечаем на распознанные атаки в соответствии со своими настройками. Можем убить процесс, а можем и вызвать kernel panic (в некоторых случаях более мягкий ответ уже не будет эффективным) - это настраиваемо. Насчет стиля программирования согласен - было бы хорошо, если бы LKRG можно было написать чисто, в рамках API, а не по-хакерски, как он написан сейчас. К сожалению, так бы не вышло реализовать то, что он сейчас умеет. Даже если бы он был патчем, а не модулем, нам пришлось бы завязываться на не предназначенные для сторонних проектов внутренние интерфейсы ядра. Также, то что LKRG модуль - очень важно. Потеря была бы очень велика - это бОльшая часть потенциальных пользователей, которые используют ядра из состава дистрибутивов, не пересобирая их.
     
     
  • 7.52, Павел Отредиез (?), 01:41, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Хорошо, мои мнения услышаны, спасибо за внимание.
     
  • 3.45, Павел Отредиез (?), 23:40, 27/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для своего маленького модуля restrictcap я оставил оформление в виде модуля, но возможность сборки только монолитно. Это избавляет от экспорта символов, потому что структуры security это не игрушки. ;)
     

  • 1.55, Аноним (55), 06:12, 28/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Linux Defender
     
     
  • 2.56, КО (?), 08:03, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну давайте теперь у пользователя права админа отберём...
    OH WAIT, OH SHI~
     

  • 1.57, Аноним (57), 08:49, 28/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Смотрел бегло ваши патчи, разные, начиная с owl Почитывал и вашу документацию о... большой текст свёрнут, показать
     
     
  • 2.58, Аноним (59), 09:01, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Важные ссылки напрямую не работают, надо их копировать/набирать и открывать в другом окне/вкладке:
    https://grsecurity.net/features
    https://grsecurity.net/compare
     
     
  • 3.62, solardiz (ok), 13:38, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Спасибо за мнение. По-моему, у вас какая-то путаница.

    1. Что такое "патчи owl"? Были патчи "-ow" (мелкие, для ядер с 2.0.x по 2.4.x), из которых исторически произошел grsecurity (когда я тянул с переходом с 2.2.x на 2.4.x и вообще ушел в безопасность userland с проектом Owl, а Brad тянуть не стал и портировал мой код сам, вскоре начав добавлять туда еще много чего). Оттолкнула "невозможность одновременного применения с PAX+Grsec"? Но в этом нет смысла. grsecurity с PaX можно было считать апгрейдом "-ow", и на него переходить или не переходить по разным причинам. Почти вся функциональность "-ow" была туда включена. Если же речь всё же идет именно про Owl, то это не отдельные патчи, а дистрибутив, где маленький патч на ядро тоже был, но в итоге он был специфичный для ядер OpenVZ и предназначенный только для использования в Owl же.

    2. KSPP - это проект по повышению безопасности mainline ядер. Соответственно, если вы используете LKRG (или что угодно другое) на каком-либо свежем ядре, вы также используете и KSPP. Функционалы KSPP и LKRG дополняют друг друга, а не пытаются друг друга превзойти. Никто не мешает также использовать LKRG совместно с другими перечисленными вами средствами, хотя осмысленность таких сложностей под вопросом. Если вы купили grsecurity и регулярно обновляете ядра с ним, LKRG вам не очень нужен, а связанные с таким количеством защит риски могут быть неоправданны. LKRG наиболее полезен для полу-заброшенных систем, где ядро вероятно не будет своевременно обновлено.

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

     
     
  • 4.69, Аноним (69), 14:40, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    1. Давно это было.... Смотрел, ваши патчи на ядро. Выбрал тогда grsecurity.

    2. Ваши патчи LKRG совместно с grsecurity на свежих ядрах работают?

    > Если вы купили grsecurity

    Сами патчи Grsecurity бесплатны, как производная от ядра Linux защищенного GPL-2. Поддержка у них платная, как и везде.

     
     
  • 5.73, solardiz (ok), 16:16, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Давно, да. OK. LKRG - это не патчи, а модуль. Адам начиная с версии LKRG 0.7 добавил экспериментальную поддержку работы с grsecurity. Проверял ли это кто-либо для версии 0.8, я не знаю. Насколько я понимаю, у grsecurity платная не только поддержка, но и доступ к свежим патчам. Наверное, сами это знаете лучше меня. Я не критикую, а лишь поясняю слово "купили".
     
     
  • 6.74, Аноним (74), 16:29, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > у grsecurity платная не только поддержка, но и доступ к свежим патчам. Наверное, сами это знаете лучше меня. Я не критикую, а лишь поясняю слово "купили".

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

    https://www.opennet.ru/openforum/vsluhforumID3/120167.html#80

    У меня ядро строго монолитное, без поддержки модулей, для безопасности. У вас только модуль?

     
     
  • 7.77, solardiz (ok), 16:47, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не стану комментировать законность договора grsecurity. Да, LKRG - только модуль. Есть вариант включать sysctl kernel.modules_disabled сразу после загрузки LKRG. Может быть, мы добавим возможность влинковки LKRG в ядро в одной из будущих версий. Один из пользователей в lkrg-users уже такое проделал сам (по-видимому для включения в какой-то продукт его работодателя).
     
  • 4.70, Аноним (69), 14:52, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    3. Наглядная табличка для сравнения LKRG с другими средствами нужна. Можете на своем сайте сделать. Grsecurity в своей табличке сравнения написал свои фичи, возможно у вас есть и другие.

    PS: реклама это хорошо, таблички сравнений тоже. Главное это гарантии которые дает или нет реализация. Приводил пример реализации W^X у Linux+PAX и OpenBSD. Linux+PAX дает строгие гарантии реализации W^X и защиты памяти, а реализация W^X в OpenBSD гарантии не дает! Иследования KSPP сделанные grsecurity тоже выявили реализацию KSPP с дырами, без гарантий.

    Строгий не строгий профиль это все субъективно, как у вас со строгой реализацией и гарантиями?

     
     
  • 5.76, solardiz (ok), 16:40, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У нас почти исключительно другие. Гарантий не даем. LKRG пытается вовремя распознать почти успешные атаки, но для многих из них может и не успеть. Грубо говоря, он заменяет стабильно успешные атаки на вероятностно успешные, осознанно привнося в них необходимость выиграть гонку (race condition). Частичные гарантии (вроде "идеальный W^X") хороши для простоты рассуждений ("этот класс атак мы исключили полностью, теперь можно думать только о других"), но обычно не дают гарантии от эксплуатации уязвимостей (за исключением случаев когда речь идет фактически об исправлении уязвимостей).
     
     
  • 6.80, Аноним (80), 17:10, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Гарантий не даем.

    В моих понятиях это плохо.

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

    Как раз строгая реализация PAX для Linux дает гарантии защиты от атак переполнения буфера. Мы согласны не иметь JIT, оптимизирует все при компиляции.

     
     
  • 7.83, solardiz (ok), 18:28, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно плохо. Полные гарантии - это об отсутствии (или полном исправлении) уязвимостей и о formal verification кода, а не о mitigations. Например, PaX не дает гарантии успешной защиты от атак переполнения буфера, он может давать гарантию от внедрения кода, тогда как атаки могут действовать и иначе.
     
  • 7.84, Anonymouz (?), 21:33, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Как раз строгая реализация PAX для Linux дает гарантии защиты от атак переполнения буфера

    Возможно, Вам известны попытки проверить эти гарантии, не поделитесь? Понятно, что в математическом смысле их нет и быть не может (патчи часть Linux), но вот подробное независимое исследование что-то не гуглится :(

     
  • 4.72, Аноним (69), 15:05, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > поэтому наибольшая эффективность достигается при использовании связки AIDE и LKRG, позволившей выявить 14 из 15 руткитов всех типов.

    Tripware, AIDE - сканеры по запросу коим уже по 20 лет. Но использовать сканер по запросу надо всем обязательно.

    Уже лет 10 как в Linux есть сканер при доступе - IMA/EVM от IBM. Работает идеально. Обеспечивает подсистему Integrity для Linux. Мелким патчем добавляется в него ACL, PAX, ... получаем полную верификацию при доступе.

     
     
  • 5.75, Anonymouz (?), 16:31, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    То что такое есть это хорошая новость, но при целевой атаке сервис могут просто остановить, так?

    Fileless malware встречается редко, но все-таки существует, вот тут любопытный пример: "SyScan'14 Singapore: Linux Memory Forensics A Real life Case Study By Georg Wicherski" (https://www.youtube.com/watch?v=JpY88tnqPhw https://archive.org/details/SyScanArchiveInfocon) - внедряется в процесс, перехватывая GOT, судя по описанию промежуточные файлы не использует.

    Вообще ситуация с руткитами в Linux удручает, в дикой природе кое-что ловится Volatility, но это еще нужно сделать корректный дамп, скоро этот момент будут отслеживать и станет совсем тяжко

     
     
  • 6.78, Аноним (80), 16:49, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > То что такое есть это хорошая новость, но при целевой атаке сервис могут просто остановить, так?

    Реализацию IMA/EVM от IBM отключить невозможно, оно все ядерное. Какой сервис если нам надо верифицировать init (PID 1).

    https://www.linux.org.ru/forum/admin/15742224?cid=15744272

    > Fileless malware встречается редко, но все-таки существует, вот тут любопытный пример: "SyScan'14 Singapore: Linux Memory Forensics A Real life Case Study By Georg Wicherski"

    Пусть себе внедряется PAX его пиибьет, или ASLR, канарейка от ssp.

    Здесь очень актуальный вопрос внедрению уже существующей безопасности в дистрах:

    paxtest blackhat

    hardened-check /bin/bash

     
  • 6.79, Аноним (80), 17:00, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вообще ситуация с руткитами в Linux удручает,...

    Попробуй:
    1 патч grsecurity, с жесткими настройками.
    2 IMA/EVM от IBM в режиме enforce & appraise
    3 переводить весь софт без JIT и с опциями -fPIE -fPIC -fstack-protector-all
    4 если ресурсы компа позволяют то на /home /tmp  куда пишут пользователи и на весь входящий трафик повесть clamav со сторонними базами.

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

     
     
  • 7.81, Аноним (80), 17:14, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    s/3 переводить/3 пересобрать/

    Все надо перекомпилировать.

     
  • 2.64, анонимус (??), 14:32, 28/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Так ведь функционал LKRG ни с одним пунктом не пересекается, он борется с последствиями. Причем в отличии от SELinux / Apparmor работает без профилей, это расширяет потенциальную аудиторию.

    Можно использовать совместно:
    - свежее ядро с KSPP (уменьшаем поверхность атак на ядро)
    - LKRG ловит часть 0-day'ев в ядре и позволяет не так сильно торопиться с обновлением (если нет подписки на kernel live patch)

    - YAMA: нет ptrace (мешаем развивать атаку на пользователей)
    - настроены профили SELinux/seccomp (в целом меньше площадь атак)

    Здесь LKRG берет на себя важную работу по отлову части того, что просочилось через другие уровни защиты.

     
     
  • 3.71, Аноним (69), 14:58, 29/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > функционал LKRG ни с одним пунктом не пересекается,

    Мне нужна наглядная табличка с сравнением функционала.

    Grsecurity тоже не надо настраивать, если без RBAC,  и 0-day в ядре оно тоже ловит, причем лучше, со строгими гарантиями, а не как KSPP.

     

  • 1.66, Аноним (65), 10:51, 29/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > В Makefile добавлена поддержка DKMS;

    Что-то не видно.

     
     
  • 2.85, solardiz (ok), 19:47, 01/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Речь всего лишь об использовании переменной KERNELRELEASE при ее наличии вместо 'uname -r', чтобы пакеты LKRG с DKMS могли не изменять Makefile от LKRG. А какая еще поддержка DKMS была бы полезна в tarball'ах с LKRG? Подготовленный dkms.conf? Что-то еще? Честно говоря, мы сами (разработчики LKRG) не пользуемся DKMS и толком не знаем что в этом плане ожидается от нас.
     

  • 1.68, jura12 (??), 13:15, 29/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а uefi не блокирует от изменения модули ядра?
     
  • 1.82, Аноним (82), 18:16, 29/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ACL нормальный, блин, завезите!!!
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру