| 1.1, Аноним (1), 13:56, 27/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +8 +/– |
Вот будет номер, когда в модуле для защиты от эксплуатации уязвимостей найдут эксплуатируемую уязвимость. Будет модуль превентивного вторжения.
| | |
| |
| 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.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 Про... текст свёрнут, показать | | |
|
|
|
|
| 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 +/– |
Да, есть такое очевидное отличие. Но с точки зрения вероятности неприцельных атак на вовремя не обновленные системы за этот период, наиболее важны опубликованные уязвимости.
| | |
|
|
|
|
| |
| 2.30, solardiz (ok), 18:15, 27/06/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Из текста новости: снижение производительности при применении LKRG 0.8 оценивается на уровне 2.5% в режиме по умолчанию ("heavy") и 2% в облегченном режиме ("light"). Результаты отдельно по 58 тестам из Phoronix Test Suite, которые сильно отличаются друг от друга, см. в файле PERFORMANCE.
| | |
|
| |
| 2.9, solardiz (ok), 14:34, 27/06/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
Такой попытки не было и пока не планируется. Соответственно, ничего не ответили.
| | |
| |
| 3.18, solardiz (ok), 15:44, 27/06/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
Мы это называем security through diversity. Это одна из причин почему мы не подаем LKRG для включения в ядро, хотя кроме сложности обхода есть и другие аспекты, влияющие на успешность атак in the wild (переносимость exploit'а между версиями ядра, вероятность его успешной работы с первого раза), на которые также влияет LKRG.
| | |
| |
| 4.31, Мордиум (?), 19:01, 27/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Напомните, кажется Alex Matrsov из hardwear.io делал пен-тесты и ему понравилась как LKRG отмела уязвимости.
Не могу найти или вспомнить, он ли это был, и где это было...
Может поделитесь ссылкой.
| | |
| |
| |
| 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.10, solardiz (ok), 14:38, 27/06/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Ничего примечательного не будет. Система будет работать примерно так же, как и без LKRG. Проверка целостности всего ядра не станет выполняться неразумно часто. Проверка целостности параметров конкретно этих процессов будет выполняться чаще, но в их же контекстах, так что это никому не помешает и загрузку системы не повысит (они и так гоняют холостые циклы).
| | |
|
| |
| 2.29, solardiz (ok), 17:54, 27/06/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
Предполагаю, что речь об атаках на 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, а то они там мучаются патчи замедляющие штампуют
| | |
|
| 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 модуль - очень важно. Потеря была бы очень велика - это бОльшая часть потенциальных пользователей, которые используют ядра из состава дистрибутивов, не пересобирая их.
| | |
|
|
|
| 3.45, Павел Отредиез (?), 23:40, 27/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Для своего маленького модуля restrictcap я оставил оформление в виде модуля, но возможность сборки только монолитно. Это избавляет от экспорта символов, потому что структуры security это не игрушки. ;)
| | |
|
|
| |
| 2.56, КО (?), 08:03, 28/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну давайте теперь у пользователя права админа отберём...
OH WAIT, OH SHI~
| | |
|
| 1.57, Аноним (57), 08:49, 28/06/2020 [ответить] [﹢﹢﹢] [ · · · ] | +1 +/– | Смотрел бегло ваши патчи, разные, начиная с owl Почитывал и вашу документацию о... большой текст свёрнут, показать | | |
| |
| |
| 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.dev/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 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> То что такое есть это хорошая новость, но при целевой атаке сервис могут просто остановить, так?
Реализацию 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 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Вообще ситуация с руткитами в Linux удручает,...
Попробуй:
1 патч grsecurity, с жесткими настройками.
2 IMA/EVM от IBM в режиме enforce & appraise
3 переводить весь софт без JIT и с опциями -fPIE -fPIC -fstack-protector-all
4 если ресурсы компа позволяют то на /home /tmp куда пишут пользователи и на весь входящий трафик повесть clamav со сторонними базами.
Я вот пытаюсь организовать базку с сигнатурами в формате YARA и ище одну для лечения, но желающих поддержать мало.
| | |
|
|
|
|
| 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.
| | |
|
|
| |
| 2.85, solardiz (ok), 19:47, 01/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
Речь всего лишь об использовании переменной KERNELRELEASE при ее наличии вместо 'uname -r', чтобы пакеты LKRG с DKMS могли не изменять Makefile от LKRG. А какая еще поддержка DKMS была бы полезна в tarball'ах с LKRG? Подготовленный dkms.conf? Что-то еще? Честно говоря, мы сами (разработчики LKRG) не пользуемся DKMS и толком не знаем что в этом плане ожидается от нас.
| | |
|
|
