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

Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимостей в ядре Linux, opennews (??), 27-Июн-20, (0) [смотреть все] Вот будет номер, когда в модуле для защиты от эксплуатации уязвимостей найдут эк, Аноним (1), 13:56 , 27-Июн-20, (1) +8 // Уже тыщу раз такое было, обычно дыры находят в патчах для защиты правда , Аноним (4), 14:04 , 27-Июн-20, (4) +4 // Понимаю дежурную иронию, которую мы здесь видим в комментариях почти на каждый а, solardiz (ok), 15:20 , 27-Июн-20, (12) +18 // Приятно вас почитать Правильно понимаю, что сейчас может быть безопаснее использ, Аноним (17), 15:40 , 27-Июн-20, (17) +3 Это сложная тема, связанная не только с ростом сложности ядер, но и с конкретным, solardiz (ok), 16:17 , 27-Июн-20, (22) +3 Спасибо, интересно было почитать , Аноним (17), 16:49 , 27-Июн-20, (26) +1 Ходят слухи, возможно даже от вас, что вы планируете перестать заниматься linux-, Аноним (37), 21:29 , 27-Июн-20, (37) Не слышал о таких слухах Разве что я здесь в одном из комментариев упоминал воз, solardiz (ok), 22:55 , 27-Июн-20, (42) +3 Интересно Спасибо за развёрнутый ответ А чем угодил или не угодил QubesOS Прос, Аноним (53), 03:32 , 28-Июн-20, (53) Про QubesOS сейчас расписывать не стану - off-topic, некогда Насчет BSD и гипер, solardiz (ok), 13:10 , 28-Июн-20, (61) +1 За 2 5 года публичного существования проекта уязвимостей в Linux выявлено полн, text (?), 03:46 , 28-Июн-20, (54) Да, есть такое очевидное отличие Но с точки зрения вероятности неприцельных ата, solardiz (ok), 14:12 , 28-Июн-20, (63) +2 Скрыто модератором, Мордиум (?), 14:00 , 27-Июн-20, (2) –1 // Скрыто модератором, Мордиум (?), 14:01 , 27-Июн-20, (3) +3 Скрыто модератором, Аноним (11), 15:03 , 27-Июн-20, (11) +1 // Скрыто модератором, Аноним (17), 15:35 , 27-Июн-20, (15) +1 // Скрыто модератором, Аноним (11), 15:51 , 27-Июн-20, (20) +1 Скрыто модератором, Аноним (17), 15:35 , 27-Июн-20, (16) +1 Интересно, сильно ли оно тормозит работу системы, Fracta1L (ok), 14:04 , 27-Июн-20, (5) +3 // Из текста новости снижение производительности при применении LKRG 0 8 оценивает, solardiz (ok), 18:15 , 27-Июн-20, (30) +3 Была попытка включить модуль в ядро Что ответили ядерщики , Аноним (6), 14:10 , 27-Июн-20, (6) // Такой попытки не было и пока не планируется Соответственно, ничего не ответили , solardiz (ok), 14:34 , 27-Июн-20, (9) +4 // А официально в дистры , Аноним (14), 15:34 , 27-Июн-20, (14) // Да, возможно, кто-то из участников сообщества или разработчиков LKRG возьмется з, solardiz (ok), 16:25 , 27-Июн-20, (24) +4 http packages altlinux org ru search query lkrg, Michael Shigorin (ok), 19:48 , 27-Июн-20, (33) +12 давайте проплюсуем Мишу, тот_же_анон_уже_без_мабилы (?), 20:25 , 27-Июн-20, (35) +4 АЛЬТ собирается в ядра добавлять KSPP https www kernel org doc html latest se, Аноним (59), 09:15 , 28-Июн-20, (59) +2 ---CONFIG_SECURITY_YAMA y--- http git altlinux org gears k kernel-image-std-de, Michael Shigorin (ok), 11:29 , 29-Июн-20, (67) PS vseleznv добавил поддержку lkrg в make-initrd 2 2 10 http git altlinux o, Michael Shigorin (ok), 21:20 , 24-Сен-20, (86) Если оно станет популярным, а тем более попадет как опция в ядро, эффективность , анонимус (??), 15:32 , 27-Июн-20, (13) // Мы это называем security through diversity Это одна из причин почему мы не пода, solardiz (ok), 15:44 , 27-Июн-20, (18) +4 // Through diversity - это ASLR , Аноним (14), 15:58 , 27-Июн-20, (21) +2 Да, и это тоже , solardiz (ok), 16:26 , 27-Июн-20, (25) +2 Напомните, кажется Alex Matrsov из hardwear io делал пен-тесты и ему понравилась, Мордиум (?), 19:01 , 27-Июн-20, (31) +1 К сожалению, не знаю о чем это Он тоже не знает , solardiz (ok), 22:30 , 27-Июн-20, (40) +2 Да, значит путаю, может это был Richard Hughes который lvfs и gnome, не буду гад, Мордиум (?), 00:25 , 28-Июн-20, (47) А вот и разгадка , Аноним (65), 09:55 , 29-Июн-20, (65) +2 Что будет если наплодить процессов которые будут делать for setuid 0 Как-т, анон (?), 14:15 , 27-Июн-20, (7) // А в чем проблема , Аноним (8), 14:33 , 27-Июн-20, (8) Ничего примечательного не будет Система будет работать примерно так же, как и б, solardiz (ok), 14:38 , 27-Июн-20, (10) +3 Для защиты Android от Qualcommо- и Broadcomогoвна подойдёт , Аноним (14), 15:45 , 27-Июн-20, (19) +1 // Предполагаю, что речь об атаках на Android, выполняемых из уязвимого кода прошив, solardiz (ok), 17:54 , 27-Июн-20, (29) +5 Когда уже выпуск модуля для защиты от эксплуатации уязвимостей в модуле для защ, Онаним (?), 19:42 , 27-Июн-20, (32) –1 // Попробуйте переключить ждуна на форсаж, вдруг быстрей само напишется , Michael Shigorin (ok), 19:51 , 27-Июн-20, (34) отличный проект хорошо, что починили суспенды, а то на ноутбуке модуль постоянн, онанимуз (?), 21:44 , 27-Июн-20, (38) // Надо срочно сообщить в Intel, а то они там мучаются патчи замедляющие штампуют, Аноним (39), 22:08 , 27-Июн-20, (39) +1 // то чувство, когда сарказм - это внезапно не сарказм , ananim (?), 10:34 , 28-Июн-20, (60) +1 Про capabilities, дак лучше неиспользуемые вообще отключать переходом в securele, Павел Отредиез (?), 22:41 , 27-Июн-20, (41) +1 // Проверяем, что capabilities процесса всё еще соответствуют сохраненным сразу пос, solardiz (ok), 23:06 , 27-Июн-20, (43) +1 // Понятно Вы используете security hooks и ваш модуль оформлен как модуль, я прави, Павел Отредиез (?), 23:13 , 27-Июн-20, (44) +1   // Используем kprobes Оформлен как модуль Экспорт самим ядром мы не трогаем, но д, solardiz (ok), 23:57 , 27-Июн-20, (46) +1   Если это возможно вашему модулю, то возможно security hooks и другому модулю Во, Павел Отредиез (?), 00:26 , 28-Июн-20, (48) +1   LKRG не предназначен нарушать работу других модулей, в том числе что-то переопре, solardiz (ok), 01:03 , 28-Июн-20, (50) +2   Я не помню сейчас стек вызовов хуков - до первого разрешения или запрета Но это, Павел Отредиез (?), 00:42 , 28-Июн-20, (49) +1   Мы не используем security hooks и не возвращаем разрешения запреты Мы перехваты, solardiz (ok), 01:18 , 28-Июн-20, (51) +2   Хорошо, мои мнения услышаны, спасибо за внимание , Павел Отредиез (?), 01:41 , 28-Июн-20, (52) +2   Для своего маленького модуля restrictcap я оставил оформление в виде модуля, но , Павел Отредиез (?), 23:40 , 27-Июн-20, (45) +1 Linux Defender, Аноним (55), 06:12 , 28-Июн-20, (55) // Ну давайте теперь у пользователя права админа отберём OH WAIT, OH SHI , КО (?), 08:03 , 28-Июн-20, (56) +1 Смотрел бегло ваши патчи, разные, начиная с owl Почитывал и вашу документацию о, Аноним (57), 08:49 , 28-Июн-20, (57) +1 // Важные ссылки напрямую не работают, надо их копировать набирать и открывать в др, Аноним (59), 09:01 , 28-Июн-20, (58) // Спасибо за мнение По-моему, у вас какая-то путаница 1 Что такое патчи owl Б, solardiz (ok), 13:38 , 28-Июн-20, (62) +2 // 1 Давно это было Смотрел, ваши патчи на ядро Выбрал тогда grsecurity 2 Ва, Аноним (69), 14:40 , 29-Июн-20, (69) Давно, да OK LKRG - это не патчи, а модуль Адам начиная с версии LKRG 0 7 доб, solardiz (ok), 16:16 , 29-Июн-20, (73) Патчи к ядру должны предоставлять, распространять бесплатно Если в нагрузку к п, Аноним (74), 16:29 , 29-Июн-20, (74) Не стану комментировать законность договора grsecurity Да, LKRG - только модуль, solardiz (ok), 16:47 , 29-Июн-20, (77) 3 Наглядная табличка для сравнения LKRG с другими средствами нужна Можете на с, Аноним (69), 14:52 , 29-Июн-20, (70) У нас почти исключительно другие Гарантий не даем LKRG пытается вовремя распоз, solardiz (ok), 16:40 , 29-Июн-20, (76) +1 В моих понятиях это плохо Как раз строгая реализация PAX для Linux дает гарантии, Аноним (80), 17:10 , 29-Июн-20, (80) Конечно плохо Полные гарантии - это об отсутствии или полном исправлении уязв, solardiz (ok), 18:28 , 29-Июн-20, (83) Возможно, Вам известны попытки проверить эти гарантии, не поделитесь Понятно, ч, Anonymouz (?), 21:33 , 29-Июн-20, (84) Tripware, AIDE - сканеры по запросу коим уже по 20 лет Но использовать сканер п, Аноним (69), 15:05 , 29-Июн-20, (72) +1 То что такое есть это хорошая новость, но при целевой атаке сервис могут просто , Anonymouz (?), 16:31 , 29-Июн-20, (75) +1 Реализацию IMA EVM от IBM отключить невозможно, оно все ядерное Какой сервис ес, Аноним (80), 16:49 , 29-Июн-20, (78) +2 Попробуй 1 патч grsecurity, с жесткими настройками 2 IMA EVM от IBM в режиме enf, Аноним (80), 17:00 , 29-Июн-20, (79) +2 s 3 переводить 3 пересобрать Все надо перекомпилировать , Аноним (80), 17:14 , 29-Июн-20, (81) Так ведь функционал LKRG ни с одним пунктом не пересекается, он борется с послед, анонимус (??), 14:32 , 28-Июн-20, (64) +2 // Мне нужна наглядная табличка с сравнением функционала Grsecurity тоже не надо на, Аноним (69), 14:58 , 29-Июн-20, (71) –1 Что-то не видно , Аноним (65), 10:51 , 29-Июн-20, (66) // Речь всего лишь об использовании переменной KERNELRELEASE при ее наличии вместо , solardiz (ok), 19:47 , 01-Июл-20, (85) // dkms conf есть в подготовленном deb пакете https deb whonix org pool main l lk, jura12 (ok), 02:57 , 16-Ноя-20, (88) а uefi не блокирует от изменения модули ядра , jura12 (??), 13:15 , 29-Июн-20, (68) ACL нормальный, блин, завезите , Аноним (82), 18:16 , 29-Июн-20, (82) –1 репозитарии в убунту когда будут , Юра (??), 00:53 , 03-Окт-20, (87) –1 // Тогда, когда ты их туда добавишь , ИмяХ (?), 02:01 , 13-Янв-21, (89) // уже добавил для 20 04 https launchpad net jurawww archive ubuntu www, jura12 (ok), 17:44 , 20-Янв-21, (90) 1,5,6,7,19,32,38,41,55,57,66,68,82,87

Сообщения

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

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

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

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