The OpenNET Project / Index page

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



"Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимостей в ядре Linux"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимостей в ядре Linux"  +/
Сообщение от opennews (??), 27-Июн-20, 13:56 
Проект Openwall опубликовал выпуск модуля ядра LKRG 0.8  (Linux Kernel Runtime Guard), предназначенного для выявления и блокирования атак и нарушений целостности структур ядра. Например, модуль может защитить от несанкционированного внесения изменений в работающее ядро и попыток изменения полномочий пользовательских процессов (определение применения эксплоитов). Модуль подходит как для организации защиты от уже известных эксплоитов для ядра Linux (например, в ситуациях когда в системе проблематично обновить ядро), так и для противостояния эксплоитам для ещё неизвестных уязвимостей.  Код проекта распространяется под лицензией GPLv2...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53244

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +7 +/
Сообщение от Аноним (1), 27-Июн-20, 13:56 
Вот будет номер, когда в модуле для защиты от эксплуатации уязвимостей найдут эксплуатируемую уязвимость. Будет модуль превентивного вторжения.
Ответить | Правка | Наверх | Cообщить модератору

4. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +4 +/
Сообщение от Аноним (4), 27-Июн-20, 14:04 
Уже тыщу раз такое было, обычно дыры находят в патчах для "защиты" правда.
Ответить | Правка | Наверх | Cообщить модератору

12. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +18 +/
Сообщение от solardiz (ok), 27-Июн-20, 15:20 
Понимаю дежурную иронию, которую мы здесь видим в комментариях почти на каждый анонс очередной версии LKRG, особенно в контексте регулярных подобных новостей про другие проекты. Современные ядра Linux слишком сложны, из-за чего в них присутствует огромное количество еще не выявленных уязвимостей. На фоне этого даже наличие в модуле защиты еще небольшого их количества существенно не ухудшит ситуацию в целом (кроме как в плане иронии), в то время как защита может помочь - в зависимости от того какие уязвимости и как реально будут пытаться эксплуатировать на конкретной системе. Мы с самого начала проекта указываем на домашней странице LKRG, что он может содержать ошибки и уязвимости, и рекомендуем взвесить пользу и риски от его использования в конкретной ситуации. LKRG наиболее актуален там, где вероятно что ядро не будет своевременно обновлено. LKRG наиболее неприятен риском ложных срабатываний. За 2.5 года публичного существования проекта уязвимостей в Linux выявлено полно, а в LKRG ни одной. Разумеется, это может измениться. Чтобы иметь шанс на отсутствие серьезных уязвимостей, надо использовать системы гораздо проще чем Linux (кстати, LKRG гораздо проще чем Linux и чем многие другие средства защиты, такие как "антивирусы" под Windows). Альтернативой же является принятие вероятного наличия уязвимостей и использование нескольких уровней защиты (что к сожалению еще более усложняет систему в целом) и/или готовность своевременно обновлять компоненты на хотя бы части уровней. Это нынешняя реальность.
Ответить | Правка | Наверх | Cообщить модератору

17. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +3 +/
Сообщение от Аноним (17), 27-Июн-20, 15:40 
Приятно вас почитать.

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

Ответить | Правка | Наверх | Cообщить модератору

22. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +3 +/
Сообщение от solardiz (ok), 27-Июн-20, 16:17 
Это сложная тема, связанная не только с ростом сложности ядер, но и с конкретными процессами разработки (какие исправления распознаются и помечаются как требующие 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, за что ему искреннее спасибо.)
Ответить | Правка | Наверх | Cообщить модератору

26. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от Аноним (17), 27-Июн-20, 16:49 
Спасибо, интересно было почитать.

Ответить | Правка | Наверх | Cообщить модератору

37. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Аноним (37), 27-Июн-20, 21:29 
Ходят слухи, возможно даже от вас, что вы планируете перестать заниматься linux-related проектами. Если это так, то что будет дальше? Типичные виндозно-макосятные [анти]вирусы?
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

42. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +3 +/
Сообщение от solardiz (ok), 27-Июн-20, 22:55 
Не слышал о таких слухах. Разве что я здесь в одном из комментариев упоминал возможность ухода с Linux, но это было в ответ на вопрос об ОС для личного использования и не относилось к проектам. (Рассматриваю вариант вместо QubesOS использовать какую-нибудь *BSD с маленьким гипервизором для запуска VM'ок с Linux'ами, только вот их интеграцию тогда придется изобрести заново. Рассматриваю аналогичный вариант и для серверов, что проще.) LKRG делался именно для Linux и у нас сейчас нет планов ни переносить его на другую платформу, ни завершать проект. Движемся в сторону версии 1.0. Проект Owl действительно заморожен, по причинам описанным мной в owl-users в 2014 году, куда есть ссылка с домашней страницы Owl. А остальные проекты у нас и так кросс-платформенные. Разумеется, поддержка Linux в них сохранится. Планов делать "типичные виндозно-макосятные [анти]вирусы" у нас нет.
Ответить | Правка | Наверх | Cообщить модератору

53. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Аноним (53), 28-Июн-20, 03:32 
Интересно. Спасибо за развёрнутый ответ.
А чем угодил или не угодил QubesOS? Просто для себя я не стал бы такое использовать. KVM+VirtManager хватает вообще для всего, касаемо вирталок. Без интеграции десктопов, конечно. Моя точка зрения - сильно проще, раз какой-то хромиум сливает телеметрию, будучи по факту трояном, то никакое разграничение не спасёт мой скомпрометированный комп. А если есть какое-то "мутное" приложение, которое обойдётся без сети - то его можно в пустой неймспейс аншарить.
Насчёт BSD как гипервизора - интересно какую вы хотите. Во всех проблемы с поддержкой железа... В сторону будущей HyperbolaBSD посматриваете?
Ответить | Правка | Наверх | Cообщить модератору

61. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от solardiz (ok), 28-Июн-20, 13:10 
Про QubesOS сейчас расписывать не стану - off-topic, некогда. Насчет BSD и гипервизора, пока не ясно какую/какой, но в целом направление выглядит правильным. Да, есть вопрос поддержки железа.
Ответить | Правка | Наверх | Cообщить модератору

54. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от text (?), 28-Июн-20, 03:46 
" За 2.5 года публичного существования проекта уязвимостей в Linux выявлено полно, а в LKRG ни оной." - а сколько людей искало в 1 и 2 случаях ? каково отношение "ищущие в Linux "/"ищущие в LKRG "
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

63. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +2 +/
Сообщение от solardiz (ok), 28-Июн-20, 14:12 
Да, есть такое очевидное отличие. Но с точки зрения вероятности неприцельных атак на вовремя не обновленные системы за этот период, наиболее важны опубликованные уязвимости.
Ответить | Правка | Наверх | Cообщить модератору

2. Скрыто модератором  –1 +/
Сообщение от Мордиум (?), 27-Июн-20, 14:00 
Ответить | Правка | Наверх | Cообщить модератору

3. Скрыто модератором  +3 +/
Сообщение от Мордиум (?), 27-Июн-20, 14:01 
Ответить | Правка | Наверх | Cообщить модератору

11. Скрыто модератором  +1 +/
Сообщение от Аноним (11), 27-Июн-20, 15:03 
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

15. Скрыто модератором  +1 +/
Сообщение от Аноним (17), 27-Июн-20, 15:35 
Ответить | Правка | Наверх | Cообщить модератору

20. Скрыто модератором  +1 +/
Сообщение от Аноним (11), 27-Июн-20, 15:51 
Ответить | Правка | Наверх | Cообщить модератору

16. Скрыто модератором  +1 +/
Сообщение от Аноним (17), 27-Июн-20, 15:35 
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

5. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +3 +/
Сообщение от Fracta1L (ok), 27-Июн-20, 14:04 
Интересно, сильно ли оно тормозит работу системы
Ответить | Правка | Наверх | Cообщить модератору

30. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +3 +/
Сообщение от solardiz (ok), 27-Июн-20, 18:15 
Из текста новости: снижение производительности при применении LKRG 0.8 оценивается на уровне 2.5% в режиме по умолчанию ("heavy") и 2% в облегченном режиме ("light"). Результаты отдельно по 58 тестам из Phoronix Test Suite, которые сильно отличаются друг от друга, см. в файле PERFORMANCE.
Ответить | Правка | Наверх | Cообщить модератору

6. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Аноним (6), 27-Июн-20, 14:10 
Была попытка включить модуль в ядро? Что ответили ядерщики?
Ответить | Правка | Наверх | Cообщить модератору

9. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +3 +/
Сообщение от solardiz (ok), 27-Июн-20, 14:34 
Такой попытки не было и пока не планируется. Соответственно, ничего не ответили.
Ответить | Правка | Наверх | Cообщить модератору

14. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Аноним (14), 27-Июн-20, 15:34 
А официально в дистры?
Ответить | Правка | Наверх | Cообщить модератору

24. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +4 +/
Сообщение от solardiz (ok), 27-Июн-20, 16:25 
Да, возможно, кто-то из участников сообщества или разработчиков 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 в случае включения пакета. Посмотрим.
Ответить | Правка | Наверх | Cообщить модератору

33. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +10 +/
Сообщение от Michael Shigorinemail (ok), 27-Июн-20, 19:48 
http://packages.altlinux.org/ru/search?query=lkrg
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

35. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +4 +/
Сообщение от тот_же_анон_уже_без_мабилы (?), 27-Июн-20, 20:25 
давайте проплюсуем Мишу
Ответить | Правка | Наверх | Cообщить модератору

59. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +2 +/
Сообщение от Аноним (59), 28-Июн-20, 09:15 
АЛЬТ собирается в ядра добавлять:

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

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

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

67. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Michael Shigorinemail (ok), 29-Июн-20, 11:29 
> АЛЬТ собирается в ядра добавлять:
> YAMA: https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama....

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

13. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от анонимус (??), 27-Июн-20, 15:32 
Если оно станет популярным, а тем более попадет как опция в ядро, эффективность против ItW заразы упадет очень сильно, ведь сложность обхода часто не велика (https://github.com/milabs/lkrg-bypass). А пока прекрасно работает принцип security by obscurity..
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

18. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +4 +/
Сообщение от solardiz (ok), 27-Июн-20, 15:44 
Мы это называем security through diversity. Это одна из причин почему мы не подаем LKRG для включения в ядро, хотя кроме сложности обхода есть и другие аспекты, влияющие на успешность атак in the wild (переносимость exploit'а между версиями ядра, вероятность его успешной работы с первого раза), на которые также влияет LKRG.
Ответить | Правка | Наверх | Cообщить модератору

21. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +2 +/
Сообщение от Аноним (14), 27-Июн-20, 15:58 
Through diversity - это ASLR.
Ответить | Правка | Наверх | Cообщить модератору

25. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от solardiz (ok), 27-Июн-20, 16:26 
Да, и это тоже.
Ответить | Правка | Наверх | Cообщить модератору

31. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от Мордиум (?), 27-Июн-20, 19:01 
Напомните, кажется Alex Matrsov из hardwear.io делал пен-тесты и ему понравилась как LKRG отмела уязвимости.

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

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

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

40. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от solardiz (ok), 27-Июн-20, 22:30 
К сожалению, не знаю о чем это. Он тоже не знает.
Ответить | Правка | Наверх | Cообщить модератору

47. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Мордиум (?), 28-Июн-20, 00:25 
Да, значит путаю, может это был Richard Hughes который lvfs и gnome, не буду гадать, ладно.
Ответить | Правка | Наверх | Cообщить модератору

65. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +2 +/
Сообщение от Аноним (65), 29-Июн-20, 09:55 
А вот и разгадка:

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

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

7. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от анон (?), 27-Июн-20, 14:15 
Что будет если наплодить процессов которые будут делать for (;;) setuid(0);
Как-там проверка целостности в ядре работать будет?
Ответить | Правка | Наверх | Cообщить модератору

8. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  –1 +/
Сообщение от Аноним (8), 27-Июн-20, 14:33 
А в чем проблема?
Ответить | Правка | Наверх | Cообщить модератору

10. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +2 +/
Сообщение от solardiz (ok), 27-Июн-20, 14:38 
Ничего примечательного не будет. Система будет работать примерно так же, как и без LKRG. Проверка целостности всего ядра не станет выполняться неразумно часто. Проверка целостности параметров конкретно этих процессов будет выполняться чаще, но в их же контекстах, так что это никому не помешает и загрузку системы не повысит (они и так гоняют холостые циклы).
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

19. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от Аноним (14), 27-Июн-20, 15:45 
Для защиты Android от Qualcommо- и Broadcomогoвна подойдёт?
Ответить | Правка | Наверх | Cообщить модератору

29. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +4 +/
Сообщение от solardiz (ok), 27-Июн-20, 17:54 
Предполагаю, что речь об атаках на Android, выполняемых из уязвимого кода прошивок сетевых "чипов". LKRG может распознать модификацию ядра Linux, осуществленную через запись в общую память из "чипа", имеющего такой доступ. LKRG может в таком случае быстро сделать kernel panic. Наверное, это поможет от атак, которые не направлены (почти) сразу на Android'овый userspace, а (сначала) модифицируют работающее ядро (и не успевают за несколько секунд закрепиться в userspace, чтобы после перезагрузки активироваться уже оттуда).
Ответить | Правка | Наверх | Cообщить модератору

32. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  –1 +/
Сообщение от Онаним (?), 27-Июн-20, 19:42 
Когда уже: выпуск модуля для защиты от эксплуатации уязвимостей в модуле для защиты от эксплуатации уязвимостей в ядре Linux?
Ответить | Правка | Наверх | Cообщить модератору

34. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Michael Shigorinemail (ok), 27-Июн-20, 19:51 
> Когда уже: выпуск модуля для защиты от эксплуатации уязвимостей
> в модуле для защиты от эксплуатации уязвимостей в ядре Linux?

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

Ответить | Правка | Наверх | Cообщить модератору

38. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от онанимуз (?), 27-Июн-20, 21:44 
отличный проект. хорошо, что починили суспенды, а то на ноутбуке модуль постоянно с ума сходил.

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

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

Ответить | Правка | Наверх | Cообщить модератору

39. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от Аноним (39), 27-Июн-20, 22:08 
Надо срочно сообщить в Intel, а то они там мучаются патчи замедляющие штампуют
Ответить | Правка | Наверх | Cообщить модератору

60. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от ananim (?), 28-Июн-20, 10:34 
то чувство, когда сарказм - это внезапно не сарказм.
Ответить | Правка | Наверх | Cообщить модератору

41. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от Павел Отредиезemail (?), 27-Июн-20, 22:41 
Про capabilities, дак лучше неиспользуемые вообще отключать переходом в securelevel. Что вы делаете на вызов cap_capable?
Ответить | Правка | Наверх | Cообщить модератору

43. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от solardiz (ok), 27-Июн-20, 23:06 
Проверяем, что capabilities процесса всё еще соответствуют сохраненным сразу после их корректного изменения одним из предназначенных для этого вызовов. Делаем эту проверку до того как capable(), возможно, подтвердит что процесс имеет право сделать что-то привилегированное. Про неиспользуемые и securelevel - отдельная тема, здесь не об этом.
Ответить | Правка | Наверх | Cообщить модератору

44. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от Павел Отредиезemail (?), 27-Июн-20, 23:13 
Понятно. Вы используете security hooks и ваш модуль оформлен как модуль, я правильно понимаю? Насколько я помню старые версии ядер часть security, не пришлось ли вам экспортировать некоторые символы ядра, а то это не очень разрешено по моему мнению?
Ответить | Правка | Наверх | Cообщить модератору

46. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от solardiz (ok), 27-Июн-20, 23:57 
Используем kprobes. Оформлен как модуль. Экспорт самим ядром мы не трогаем, но для отдельных символов нам приходится использовать kallsyms_lookup_name, а его самого (начиная с 5.7, где его перестали экспортировать) находить с помощью kprobes же. Конечно, это выходит за рамки официального API.
Ответить | Правка | Наверх | Cообщить модератору

48. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от Павел Отредиезemail (?), 28-Июн-20, 00:26 
> Используем kprobes. Оформлен как модуль. Экспорт самим ядром мы не трогаем, но
> для отдельных символов нам приходится использовать kallsyms_lookup_name, а его самого
> (начиная с 5.7, где его перестали экспортировать) находить с помощью kprobes
> же. Конечно, это выходит за рамки официального API.

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

Ответить | Правка | Наверх | Cообщить модератору

50. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +2 +/
Сообщение от solardiz (ok), 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, еще когда он там был под этим именем, но это или реально неудобно или не всерьез (по крайней мере, на серверах).

Ответить | Правка | Наверх | Cообщить модератору

49. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от Павел Отредиезemail (?), 28-Июн-20, 00:42 
> Используем kprobes. Оформлен как модуль. Экспорт самим ядром мы не трогаем, но
> для отдельных символов нам приходится использовать kallsyms_lookup_name, а его самого
> (начиная с 5.7, где его перестали экспортировать) находить с помощью kprobes
> же. Конечно, это выходит за рамки официального API.

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

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

51. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +2 +/
Сообщение от solardiz (ok), 28-Июн-20, 01:18 
Мы не используем security hooks и не возвращаем разрешения/запреты. Мы перехватываем наиболее актуальные нам функции и сами отвечаем на распознанные атаки в соответствии со своими настройками. Можем убить процесс, а можем и вызвать kernel panic (в некоторых случаях более мягкий ответ уже не будет эффективным) - это настраиваемо. Насчет стиля программирования согласен - было бы хорошо, если бы LKRG можно было написать чисто, в рамках API, а не по-хакерски, как он написан сейчас. К сожалению, так бы не вышло реализовать то, что он сейчас умеет. Даже если бы он был патчем, а не модулем, нам пришлось бы завязываться на не предназначенные для сторонних проектов внутренние интерфейсы ядра. Также, то что LKRG модуль - очень важно. Потеря была бы очень велика - это бОльшая часть потенциальных пользователей, которые используют ядра из состава дистрибутивов, не пересобирая их.
Ответить | Правка | Наверх | Cообщить модератору

52. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +2 +/
Сообщение от Павел Отредиезemail (?), 28-Июн-20, 01:41 
Хорошо, мои мнения услышаны, спасибо за внимание.
Ответить | Правка | Наверх | Cообщить модератору

45. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от Павел Отредиезemail (?), 27-Июн-20, 23:40 
Для своего маленького модуля restrictcap я оставил оформление в виде модуля, но возможность сборки только монолитно. Это избавляет от экспорта символов, потому что структуры security это не игрушки. ;)
Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

55. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Аноним (55), 28-Июн-20, 06:12 
Linux Defender
Ответить | Правка | Наверх | Cообщить модератору

56. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от КО (?), 28-Июн-20, 08:03 
Ну давайте теперь у пользователя права админа отберём...
OH WAIT, OH SHI~
Ответить | Правка | Наверх | Cообщить модератору

57. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от Аноним (57), 28-Июн-20, 08:49 
Смотрел бегло ваши патчи, разные, начиная с owl. Почитывал и вашу документацию о lkrg. Никогда не использовал.

Мое личное, субъективное, мнение со стороны:

1. от ваших падчей owl сразу меня оттолкнуло их невозможность одновременного применения с PAX+Grsec.

2. Текущий функционал lkrg не превосходит:
стандарт KSPP: https://www.kernel.org/doc/html/latest/security/self-protect...
+
YAMA: https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama....
+
PAX: https://pax.grsecurity.net/
+
GrSec: https://grsecurity.net/features
+ (RSBAC (Grsec) || SMACK || SELinux) && (Apparmor || Toyomo)

3. Надо нарисовать табличку для наглядного сравнения разных моделей и возможность их совместного применения, типа:
https://grsecurity.net/compare
Можете себя в эту табличку добавить?

Ответить | Правка | Наверх | Cообщить модератору

58. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Аноним (59), 28-Июн-20, 09:01 
Важные ссылки напрямую не работают, надо их копировать/набирать и открывать в другом окне/вкладке:
https://grsecurity.net/features
https://grsecurity.net/compare
Ответить | Правка | Наверх | Cообщить модератору

62. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +2 +/
Сообщение от solardiz (ok), 28-Июн-20, 13:38 
Спасибо за мнение. По-моему, у вас какая-то путаница.

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 с их пристрастным выбором критериев сравнения.

Ответить | Правка | Наверх | Cообщить модератору

69. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Аноним (69), 29-Июн-20, 14:40 
1. Давно это было.... Смотрел, ваши патчи на ядро. Выбрал тогда grsecurity.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

73. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от solardiz (ok), 29-Июн-20, 16:16 
Давно, да. OK. LKRG - это не патчи, а модуль. Адам начиная с версии LKRG 0.7 добавил экспериментальную поддержку работы с grsecurity. Проверял ли это кто-либо для версии 0.8, я не знаю. Насколько я понимаю, у grsecurity платная не только поддержка, но и доступ к свежим патчам. Наверное, сами это знаете лучше меня. Я не критикую, а лишь поясняю слово "купили".
Ответить | Правка | Наверх | Cообщить модератору

74. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Аноним (74), 29-Июн-20, 16:29 
> у grsecurity платная не только поддержка, но и доступ к свежим патчам. Наверное, сами это знаете лучше меня. Я не критикую, а лишь поясняю слово "купили".

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

77. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от solardiz (ok), 29-Июн-20, 16:47 
Не стану комментировать законность договора grsecurity. Да, LKRG - только модуль. Есть вариант включать sysctl kernel.modules_disabled сразу после загрузки LKRG. Может быть, мы добавим возможность влинковки LKRG в ядро в одной из будущих версий. Один из пользователей в lkrg-users уже такое проделал сам (по-видимому для включения в какой-то продукт его работодателя).
Ответить | Правка | Наверх | Cообщить модератору

70. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Аноним (69), 29-Июн-20, 14:52 
3. Наглядная табличка для сравнения LKRG с другими средствами нужна. Можете на своем сайте сделать. Grsecurity в своей табличке сравнения написал свои фичи, возможно у вас есть и другие.

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

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

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

76. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от solardiz (ok), 29-Июн-20, 16:40 
У нас почти исключительно другие. Гарантий не даем. LKRG пытается вовремя распознать почти успешные атаки, но для многих из них может и не успеть. Грубо говоря, он заменяет стабильно успешные атаки на вероятностно успешные, осознанно привнося в них необходимость выиграть гонку (race condition). Частичные гарантии (вроде "идеальный W^X") хороши для простоты рассуждений ("этот класс атак мы исключили полностью, теперь можно думать только о других"), но обычно не дают гарантии от эксплуатации уязвимостей (за исключением случаев когда речь идет фактически об исправлении уязвимостей).
Ответить | Правка | Наверх | Cообщить модератору

80. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Аноним (80), 29-Июн-20, 17:10 
> Гарантий не даем.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

83. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от solardiz (ok), 29-Июн-20, 18:28 
Конечно плохо. Полные гарантии - это об отсутствии (или полном исправлении) уязвимостей и о formal verification кода, а не о mitigations. Например, PaX не дает гарантии успешной защиты от атак переполнения буфера, он может давать гарантию от внедрения кода, тогда как атаки могут действовать и иначе.
Ответить | Правка | Наверх | Cообщить модератору

84. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Anonymouz (?), 29-Июн-20, 21:33 
>Как раз строгая реализация PAX для Linux дает гарантии защиты от атак переполнения буфера

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

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

72. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от Аноним (69), 29-Июн-20, 15:05 
> поэтому наибольшая эффективность достигается при использовании связки AIDE и LKRG, позволившей выявить 14 из 15 руткитов всех типов.

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

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

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

75. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от Anonymouz (?), 29-Июн-20, 16:31 
То что такое есть это хорошая новость, но при целевой атаке сервис могут просто остановить, так?

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, но это еще нужно сделать корректный дамп, скоро этот момент будут отслеживать и станет совсем тяжко

Ответить | Правка | Наверх | Cообщить модератору

78. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от Аноним (80), 29-Июн-20, 16:49 
> То что такое есть это хорошая новость, но при целевой атаке сервис могут просто остановить, так?

Реализацию 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

Ответить | Правка | Наверх | Cообщить модератору

79. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +1 +/
Сообщение от Аноним (80), 29-Июн-20, 17:00 
> Вообще ситуация с руткитами в Linux удручает,...

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

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

Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

81. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Аноним (80), 29-Июн-20, 17:14 
s/3 переводить/3 пересобрать/

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

Ответить | Правка | Наверх | Cообщить модератору

64. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +2 +/
Сообщение от анонимус (??), 28-Июн-20, 14:32 
Так ведь функционал LKRG ни с одним пунктом не пересекается, он борется с последствиями. Причем в отличии от SELinux / Apparmor работает без профилей, это расширяет потенциальную аудиторию.

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

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

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

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

71. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  –1 +/
Сообщение от Аноним (69), 29-Июн-20, 14:58 
> функционал LKRG ни с одним пунктом не пересекается,

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

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

Ответить | Правка | Наверх | Cообщить модератору

66. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Аноним (65), 29-Июн-20, 10:51 
> В Makefile добавлена поддержка DKMS;

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

Ответить | Правка | Наверх | Cообщить модератору

85. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от solardiz (ok), 01-Июл-20, 19:47 
Речь всего лишь об использовании переменной KERNELRELEASE при ее наличии вместо `uname -r`, чтобы пакеты LKRG с DKMS могли не изменять Makefile от LKRG. А какая еще поддержка DKMS была бы полезна в tarball'ах с LKRG? Подготовленный dkms.conf? Что-то еще? Честно говоря, мы сами (разработчики LKRG) не пользуемся DKMS и толком не знаем что в этом плане ожидается от нас.
Ответить | Правка | Наверх | Cообщить модератору

68. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от jura12 (??), 29-Июн-20, 13:15 
а uefi не блокирует от изменения модули ядра?
Ответить | Правка | Наверх | Cообщить модератору

82. "Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимосте..."  +/
Сообщение от Аноним (82), 29-Июн-20, 18:16 
ACL нормальный, блин, завезите!!!
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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