Проект Openwall опубликовал выпуск модуля ядра LKRG 0.8 (Linux Kernel Runtime Guard), предназначенного для выявления и блокирования атак и нарушений целостности структур ядра. Например, модуль может защитить от несанкционированного внесения изменений в работающее ядро и попыток изменения полномочий пользовательских процессов (определение применения эксплоитов). Модуль подходит как для организации защиты от уже известных эксплоитов для ядра Linux (например, в ситуациях когда в системе проблематично обновить ядро), так и для противостояния эксплоитам для ещё неизвестных уязвимостей. Код проекта распространяется под лицензией GPLv2...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53244
Вот будет номер, когда в модуле для защиты от эксплуатации уязвимостей найдут эксплуатируемую уязвимость. Будет модуль превентивного вторжения.
Уже тыщу раз такое было, обычно дыры находят в патчах для "защиты" правда.
Понимаю дежурную иронию, которую мы здесь видим в комментариях почти на каждый анонс очередной версии LKRG, особенно в контексте регулярных подобных новостей про другие проекты. Современные ядра Linux слишком сложны, из-за чего в них присутствует огромное количество еще не выявленных уязвимостей. На фоне этого даже наличие в модуле защиты еще небольшого их количества существенно не ухудшит ситуацию в целом (кроме как в плане иронии), в то время как защита может помочь - в зависимости от того какие уязвимости и как реально будут пытаться эксплуатировать на конкретной системе. Мы с самого начала проекта указываем на домашней странице LKRG, что он может содержать ошибки и уязвимости, и рекомендуем взвесить пользу и риски от его использования в конкретной ситуации. LKRG наиболее актуален там, где вероятно что ядро не будет своевременно обновлено. LKRG наиболее неприятен риском ложных срабатываний. За 2.5 года публичного существования проекта уязвимостей в Linux выявлено полно, а в LKRG ни одной. Разумеется, это может измениться. Чтобы иметь шанс на отсутствие серьезных уязвимостей, надо использовать системы гораздо проще чем Linux (кстати, LKRG гораздо проще чем Linux и чем многие другие средства защиты, такие как "антивирусы" под Windows). Альтернативой же является принятие вероятного наличия уязвимостей и использование нескольких уровней защиты (что к сожалению еще более усложняет систему в целом) и/или готовность своевременно обновлять компоненты на хотя бы части уровней. Это нынешняя реальность.
Приятно вас почитать.Правильно понимаю, что сейчас может быть безопаснее использовать mainline ядра, чем стабильные и лонгтерм?
Это сложная тема, связанная не только с ростом сложности ядер, но и с конкретными процессами разработки (какие исправления распознаются и помечаются как требующие 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, за что ему искреннее спасибо.)
Спасибо, интересно было почитать.
Ходят слухи, возможно даже от вас, что вы планируете перестать заниматься linux-related проектами. Если это так, то что будет дальше? Типичные виндозно-макосятные [анти]вирусы?
Не слышал о таких слухах. Разве что я здесь в одном из комментариев упоминал возможность ухода с Linux, но это было в ответ на вопрос об ОС для личного использования и не относилось к проектам. (Рассматриваю вариант вместо QubesOS использовать какую-нибудь *BSD с маленьким гипервизором для запуска VM'ок с Linux'ами, только вот их интеграцию тогда придется изобрести заново. Рассматриваю аналогичный вариант и для серверов, что проще.) LKRG делался именно для Linux и у нас сейчас нет планов ни переносить его на другую платформу, ни завершать проект. Движемся в сторону версии 1.0. Проект Owl действительно заморожен, по причинам описанным мной в owl-users в 2014 году, куда есть ссылка с домашней страницы Owl. А остальные проекты у нас и так кросс-платформенные. Разумеется, поддержка Linux в них сохранится. Планов делать "типичные виндозно-макосятные [анти]вирусы" у нас нет.
Интересно. Спасибо за развёрнутый ответ.
А чем угодил или не угодил QubesOS? Просто для себя я не стал бы такое использовать. KVM+VirtManager хватает вообще для всего, касаемо вирталок. Без интеграции десктопов, конечно. Моя точка зрения - сильно проще, раз какой-то хромиум сливает телеметрию, будучи по факту трояном, то никакое разграничение не спасёт мой скомпрометированный комп. А если есть какое-то "мутное" приложение, которое обойдётся без сети - то его можно в пустой неймспейс аншарить.
Насчёт BSD как гипервизора - интересно какую вы хотите. Во всех проблемы с поддержкой железа... В сторону будущей HyperbolaBSD посматриваете?
Про QubesOS сейчас расписывать не стану - off-topic, некогда. Насчет BSD и гипервизора, пока не ясно какую/какой, но в целом направление выглядит правильным. Да, есть вопрос поддержки железа.
" За 2.5 года публичного существования проекта уязвимостей в Linux выявлено полно, а в LKRG ни оной." - а сколько людей искало в 1 и 2 случаях ? каково отношение "ищущие в Linux "/"ищущие в LKRG "
Да, есть такое очевидное отличие. Но с точки зрения вероятности неприцельных атак на вовремя не обновленные системы за этот период, наиболее важны опубликованные уязвимости.
Офф: читали отповедь сисадмина и cto вк/телеги про Дуровых? Это шикарно, как роман, особенно ранние фотки Николая...https://medium.com/@anton.rozenberg/friendship-betrayal...
Жареное с 4ой главы начнётся )
С разморозкой! Спойлер: розенберг оказался истеричным инфантилом, а телеграм неоднократно публично опровергнул этого "сисадмина" со всеми пруфами (сканами документов etc.)
Розенберг в ВК был вторым человеком после Николая, если брать технарей. Он не просто сисадмин, а сисадмин и безопасник, который делал большую часть работы.
На каких ролях он был в ТГ, уже хз, но это человек не левый и не с улицы.Все остальное у вас в посте - наклеивание ярлыков и проецирование собственных комплексов. Вы уверены, что Розенберг инфантилен? Можете поручиться?
Ты вначале этот самый сериал досмотри, а потом уже пытайся контр-аргументировать.- https://telegra.ph/Realnyj-Kot-Durova-09-21
- https://telegra.ph/Dokumenty-razoblachayushchie-zayavleniya-...> Вы уверены, что Розенберг инфантилен? Можете поручиться?
Почитай характеристику на розенберга от Андрея Рогозова. Там же, по ссылкам.
А зачем вы это сейчас достали? Это уже давние дела и стороны договорились.
Интересно, сильно ли оно тормозит работу системы
Из текста новости: снижение производительности при применении LKRG 0.8 оценивается на уровне 2.5% в режиме по умолчанию ("heavy") и 2% в облегченном режиме ("light"). Результаты отдельно по 58 тестам из Phoronix Test Suite, которые сильно отличаются друг от друга, см. в файле PERFORMANCE.
Была попытка включить модуль в ядро? Что ответили ядерщики?
Такой попытки не было и пока не планируется. Соответственно, ничего не ответили.
А официально в дистры?
Да, возможно, кто-то из участников сообщества или разработчиков 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 в случае включения пакета. Посмотрим.
http://packages.altlinux.org/ru/search?query=lkrg
давайте проплюсуем Мишу
АЛЬТ собирается в ядра добавлять:KSPP: https://www.kernel.org/doc/html/latest/security/self-protect...
YAMA: https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama....Может даже GrSecurity добавите?
> АЛЬТ собирается в ядра добавлять:
> 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@ спросить, если вопрос по существу).
Насчёт "частично" им на всякий передал, спасибо.
PS: vseleznv@ добавил поддержку lkrg в make-initrd 2.2.10: http://git.altlinux.org/gears/m/make-initrd.git?p=make-initr...
Если оно станет популярным, а тем более попадет как опция в ядро, эффективность против ItW заразы упадет очень сильно, ведь сложность обхода часто не велика (https://github.com/milabs/lkrg-bypass). А пока прекрасно работает принцип security by obscurity..
Мы это называем security through diversity. Это одна из причин почему мы не подаем LKRG для включения в ядро, хотя кроме сложности обхода есть и другие аспекты, влияющие на успешность атак in the wild (переносимость exploit'а между версиями ядра, вероятность его успешной работы с первого раза), на которые также влияет LKRG.
Through diversity - это ASLR.
Да, и это тоже.
Напомните, кажется Alex Matrsov из hardwear.io делал пен-тесты и ему понравилась как LKRG отмела уязвимости.Не могу найти или вспомнить, он ли это был, и где это было...
Может поделитесь ссылкой.
К сожалению, не знаю о чем это. Он тоже не знает.
Да, значит путаю, может это был Richard Hughes который lvfs и gnome, не буду гадать, ладно.
А вот и разгадка:>As free LKRG becomes somewhat popular and maybe a target of some exploits, we might introduce paid LKRG Pro
Что будет если наплодить процессов которые будут делать for (;;) setuid(0);
Как-там проверка целостности в ядре работать будет?
А в чем проблема?
Ничего примечательного не будет. Система будет работать примерно так же, как и без LKRG. Проверка целостности всего ядра не станет выполняться неразумно часто. Проверка целостности параметров конкретно этих процессов будет выполняться чаще, но в их же контекстах, так что это никому не помешает и загрузку системы не повысит (они и так гоняют холостые циклы).
Для защиты Android от Qualcommо- и Broadcomогoвна подойдёт?
Предполагаю, что речь об атаках на Android, выполняемых из уязвимого кода прошивок сетевых "чипов". LKRG может распознать модификацию ядра Linux, осуществленную через запись в общую память из "чипа", имеющего такой доступ. LKRG может в таком случае быстро сделать kernel panic. Наверное, это поможет от атак, которые не направлены (почти) сразу на Android'овый userspace, а (сначала) модифицируют работающее ядро (и не успевают за несколько секунд закрепиться в userspace, чтобы после перезагрузки активироваться уже оттуда).
Когда уже: выпуск модуля для защиты от эксплуатации уязвимостей в модуле для защиты от эксплуатации уязвимостей в ядре Linux?
> Когда уже: выпуск модуля для защиты от эксплуатации уязвимостей
> в модуле для защиты от эксплуатации уязвимостей в ядре Linux?Попробуйте переключить ждуна на форсаж, вдруг быстрей само напишется.
отличный проект. хорошо, что починили суспенды, а то на ноутбуке модуль постоянно с ума сходил.> С учётом предложенных в новом выпуске оптимизаций снижение производительности при применении LKRG 0.8 оценивается на уровне 2.5% в режиме по умолчанию ("heavy") и 2% в облегченном режиме ("light").
выключил все защиты от спектров и мелт даунов, включил LKRG => увеличение производительности на уровне 5%, а защита от хеккеров такая же, если не лучше.
Надо срочно сообщить в Intel, а то они там мучаются патчи замедляющие штампуют
то чувство, когда сарказм - это внезапно не сарказм.
Про capabilities, дак лучше неиспользуемые вообще отключать переходом в securelevel. Что вы делаете на вызов cap_capable?
Проверяем, что capabilities процесса всё еще соответствуют сохраненным сразу после их корректного изменения одним из предназначенных для этого вызовов. Делаем эту проверку до того как capable(), возможно, подтвердит что процесс имеет право сделать что-то привилегированное. Про неиспользуемые и securelevel - отдельная тема, здесь не об этом.
Понятно. Вы используете security hooks и ваш модуль оформлен как модуль, я правильно понимаю? Насколько я помню старые версии ядер часть security, не пришлось ли вам экспортировать некоторые символы ядра, а то это не очень разрешено по моему мнению?
Используем kprobes. Оформлен как модуль. Экспорт самим ядром мы не трогаем, но для отдельных символов нам приходится использовать kallsyms_lookup_name, а его самого (начиная с 5.7, где его перестали экспортировать) находить с помощью kprobes же. Конечно, это выходит за рамки официального API.
> Используем kprobes. Оформлен как модуль. Экспорт самим ядром мы не трогаем, но
> для отдельных символов нам приходится использовать kallsyms_lookup_name, а его самого
> (начиная с 5.7, где его перестали экспортировать) находить с помощью kprobes
> же. Конечно, это выходит за рамки официального API.Если это возможно вашему модулю, то возможно security hooks и другому модулю. Вот и можно предположить почему модуль-эксплоит успешен, он переопределил хуки.
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, еще когда он там был под этим именем, но это или реально неудобно или не всерьез (по крайней мере, на серверах).
> Используем kprobes. Оформлен как модуль. Экспорт самим ядром мы не трогаем, но
> для отдельных символов нам приходится использовать kallsyms_lookup_name, а его самого
> (начиная с 5.7, где его перестали экспортировать) находить с помощью kprobes
> же. Конечно, это выходит за рамки официального API.Я не помню сейчас стек вызовов хуков - до первого разрешения или запрета. Но это в общем то не важно. Для меня важно как программировать. Усложненно как хакер-программист, или проще как clean- программист. Clean программист не выходит за рамки api, в данном случае я бы отказался от загрузки модулем, невелика потеря а простоты намного больше.
Мы не используем security hooks и не возвращаем разрешения/запреты. Мы перехватываем наиболее актуальные нам функции и сами отвечаем на распознанные атаки в соответствии со своими настройками. Можем убить процесс, а можем и вызвать kernel panic (в некоторых случаях более мягкий ответ уже не будет эффективным) - это настраиваемо. Насчет стиля программирования согласен - было бы хорошо, если бы LKRG можно было написать чисто, в рамках API, а не по-хакерски, как он написан сейчас. К сожалению, так бы не вышло реализовать то, что он сейчас умеет. Даже если бы он был патчем, а не модулем, нам пришлось бы завязываться на не предназначенные для сторонних проектов внутренние интерфейсы ядра. Также, то что LKRG модуль - очень важно. Потеря была бы очень велика - это бОльшая часть потенциальных пользователей, которые используют ядра из состава дистрибутивов, не пересобирая их.
Хорошо, мои мнения услышаны, спасибо за внимание.
Для своего маленького модуля restrictcap я оставил оформление в виде модуля, но возможность сборки только монолитно. Это избавляет от экспорта символов, потому что структуры security это не игрушки. ;)
Linux Defender
Ну давайте теперь у пользователя права админа отберём...
OH WAIT, OH SHI~
Смотрел бегло ваши патчи, разные, начиная с 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
Можете себя в эту табличку добавить?
Важные ссылки напрямую не работают, надо их копировать/набирать и открывать в другом окне/вкладке:
https://grsecurity.net/features
https://grsecurity.net/compare
Спасибо за мнение. По-моему, у вас какая-то путаница.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 с их пристрастным выбором критериев сравнения.
1. Давно это было.... Смотрел, ваши патчи на ядро. Выбрал тогда grsecurity.2. Ваши патчи LKRG совместно с grsecurity на свежих ядрах работают?
> Если вы купили grsecurity
Сами патчи Grsecurity бесплатны, как производная от ядра Linux защищенного GPL-2. Поддержка у них платная, как и везде.
Давно, да. OK. LKRG - это не патчи, а модуль. Адам начиная с версии LKRG 0.7 добавил экспериментальную поддержку работы с grsecurity. Проверял ли это кто-либо для версии 0.8, я не знаю. Насколько я понимаю, у grsecurity платная не только поддержка, но и доступ к свежим патчам. Наверное, сами это знаете лучше меня. Я не критикую, а лишь поясняю слово "купили".
> у grsecurity платная не только поддержка, но и доступ к свежим патчам. Наверное, сами это знаете лучше меня. Я не критикую, а лишь поясняю слово "купили".Патчи к ядру должны предоставлять, распространять бесплатно. Если в нагрузку к патчам цепляют договор поддержки то это незаконно.
https://www.opennet.dev/openforum/vsluhforumID3/120167.html#80
У меня ядро строго монолитное, без поддержки модулей, для безопасности. У вас только модуль?
Не стану комментировать законность договора grsecurity. Да, LKRG - только модуль. Есть вариант включать sysctl kernel.modules_disabled сразу после загрузки LKRG. Может быть, мы добавим возможность влинковки LKRG в ядро в одной из будущих версий. Один из пользователей в lkrg-users уже такое проделал сам (по-видимому для включения в какой-то продукт его работодателя).
3. Наглядная табличка для сравнения LKRG с другими средствами нужна. Можете на своем сайте сделать. Grsecurity в своей табличке сравнения написал свои фичи, возможно у вас есть и другие.PS: реклама это хорошо, таблички сравнений тоже. Главное это гарантии которые дает или нет реализация. Приводил пример реализации W^X у Linux+PAX и OpenBSD. Linux+PAX дает строгие гарантии реализации W^X и защиты памяти, а реализация W^X в OpenBSD гарантии не дает! Иследования KSPP сделанные grsecurity тоже выявили реализацию KSPP с дырами, без гарантий.
Строгий не строгий профиль это все субъективно, как у вас со строгой реализацией и гарантиями?
У нас почти исключительно другие. Гарантий не даем. LKRG пытается вовремя распознать почти успешные атаки, но для многих из них может и не успеть. Грубо говоря, он заменяет стабильно успешные атаки на вероятностно успешные, осознанно привнося в них необходимость выиграть гонку (race condition). Частичные гарантии (вроде "идеальный W^X") хороши для простоты рассуждений ("этот класс атак мы исключили полностью, теперь можно думать только о других"), но обычно не дают гарантии от эксплуатации уязвимостей (за исключением случаев когда речь идет фактически об исправлении уязвимостей).
> Гарантий не даем.В моих понятиях это плохо.
> Частичные гарантии (вроде "идеальный W^X") хороши для простоты рассуждений ("этот класс атак мы исключили полностью, теперь можно думать только о других"), но обычно не дают гарантии от эксплуатации уязвимостей
Как раз строгая реализация PAX для Linux дает гарантии защиты от атак переполнения буфера. Мы согласны не иметь JIT, оптимизирует все при компиляции.
Конечно плохо. Полные гарантии - это об отсутствии (или полном исправлении) уязвимостей и о formal verification кода, а не о mitigations. Например, PaX не дает гарантии успешной защиты от атак переполнения буфера, он может давать гарантию от внедрения кода, тогда как атаки могут действовать и иначе.
>Как раз строгая реализация PAX для Linux дает гарантии защиты от атак переполнения буфераВозможно, Вам известны попытки проверить эти гарантии, не поделитесь? Понятно, что в математическом смысле их нет и быть не может (патчи часть Linux), но вот подробное независимое исследование что-то не гуглится :(
> поэтому наибольшая эффективность достигается при использовании связки AIDE и LKRG, позволившей выявить 14 из 15 руткитов всех типов.Tripware, AIDE - сканеры по запросу коим уже по 20 лет. Но использовать сканер по запросу надо всем обязательно.
Уже лет 10 как в Linux есть сканер при доступе - IMA/EVM от IBM. Работает идеально. Обеспечивает подсистему Integrity для Linux. Мелким патчем добавляется в него ACL, PAX, ... получаем полную верификацию при доступе.
То что такое есть это хорошая новость, но при целевой атаке сервис могут просто остановить, так?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, но это еще нужно сделать корректный дамп, скоро этот момент будут отслеживать и станет совсем тяжко
> То что такое есть это хорошая новость, но при целевой атаке сервис могут просто остановить, так?Реализацию 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
> Вообще ситуация с руткитами в Linux удручает,...Попробуй:
1 патч grsecurity, с жесткими настройками.
2 IMA/EVM от IBM в режиме enforce & appraise
3 переводить весь софт без JIT и с опциями -fPIE -fPIC -fstack-protector-all
4 если ресурсы компа позволяют то на /home /tmp куда пишут пользователи и на весь входящий трафик повесть clamav со сторонними базами.Я вот пытаюсь организовать базку с сигнатурами в формате YARA и ище одну для лечения, но желающих поддержать мало.
s/3 переводить/3 пересобрать/Все надо перекомпилировать.
Так ведь функционал LKRG ни с одним пунктом не пересекается, он борется с последствиями. Причем в отличии от SELinux / Apparmor работает без профилей, это расширяет потенциальную аудиторию.Можно использовать совместно:
- свежее ядро с KSPP (уменьшаем поверхность атак на ядро)
- LKRG ловит часть 0-day'ев в ядре и позволяет не так сильно торопиться с обновлением (если нет подписки на kernel live patch)- YAMA: нет ptrace (мешаем развивать атаку на пользователей)
- настроены профили SELinux/seccomp (в целом меньше площадь атак)Здесь LKRG берет на себя важную работу по отлову части того, что просочилось через другие уровни защиты.
> функционал LKRG ни с одним пунктом не пересекается,Мне нужна наглядная табличка с сравнением функционала.
Grsecurity тоже не надо настраивать, если без RBAC, и 0-day в ядре оно тоже ловит, причем лучше, со строгими гарантиями, а не как KSPP.
> В Makefile добавлена поддержка DKMS;Что-то не видно.
Речь всего лишь об использовании переменной KERNELRELEASE при ее наличии вместо `uname -r`, чтобы пакеты LKRG с DKMS могли не изменять Makefile от LKRG. А какая еще поддержка DKMS была бы полезна в tarball'ах с LKRG? Подготовленный dkms.conf? Что-то еще? Честно говоря, мы сами (разработчики LKRG) не пользуемся DKMS и толком не знаем что в этом плане ожидается от нас.
dkms.conf есть в подготовленном deb пакете https://deb.whonix.org/pool/main/l/lkrg/
а uefi не блокирует от изменения модули ядра?
ACL нормальный, блин, завезите!!!
репозитарии в убунту когда будут?
Тогда, когда ты их туда добавишь.
> Тогда, когда ты их туда добавишь.уже добавил для 20.04 https://launchpad.net/~jurawww/+archive/ubuntu/www