id: Гость   вход   регистрация
текущее время 08:31 20/04/2024
Автор темы: unknown, тема открыта 11/04/2010 21:58 Печать
https://www.pgpru.com/Форум/UnixLike/SELinuxAppArmorИДрСистемыБезопасности
создать
просмотр
ссылки

SELinux, AppArmor и др. системы безопасности


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

> Но безопасность в контексте браузера это фантастика, на сегодняшний день.
SELinux по идее должен защищать пользовательское пространство от уязвимостей в приложениях. Правда я пока не освоил эту технику. Может кто из знающих людей покажет пример? Предположим, нужно изолировать браузер Firefox

Вот пример создания политики для гуглохрома:


http://danwalsh.livejournal.com/32759.html


Или пример использования киоск-режима:


http://danwalsh.livejournal.com/11913.html


Но всё вменяемо работает только в Федоре (в нём ведётся официальна разработка), в других дистрах поддержка SELinux не очень хорошая (местами плачевная) и стабильно отлажена только в расчёте на запуск серверов. Многих утилит, фич просто может не быть. Особенно для юзер-приложений и иксов.


А вы уже пробовали как-то работать хотя-бы с готовыми политиками? Про всякие тонкости с "domain transition" внятно себе представляете?


По SELinux практически нет ни манов ни доков, только книжки, разрозненные описания в расчёте на опору поддержки дистростроителями готовых политик (что хорошо делается только в Федоре).


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 След.
Комментарии
— Гость (05/10/2011 21:35)   <#>
завязан на закрытые проприетарные стандарты Intel
Кто вникал в суть, подскажите: как так получается, что Xen — полностью свободен и открыт, а Qubes, на нём основанный, жизненно требует каких-то "закрытых проприетарных стандартов"? Может, не во всех конфигурациях?
— unknown (06/10/2011 15:53)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Возможно, действительно не во всех. В описаниях там явно упоминается использование TPM-чипа против атаки "злонамеренной уборщицы" и идёт упор поддержки виртуализации на аппаратном уровне от Intel для ёщё чего-то.
— sentaus (06/10/2011 16:04)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
идёт упор поддержки виртуализации на аппаратном уровне от Intel для ёщё чего-то

От DMA, видимо, если речь идёт о VT-d.
— Гость (06/10/2011 17:11)   <#>
как так получается, что Xen — полностью свободен и открыт, а Qubes, на нём основанный, жизненно требует каких-то "закрытых проприетарных стандартов"?
Вообе говоря, почему бы и нет – сделать на основе открытой вещи что-то специализированное. Вот если наоборот – было бы странно...
— Гость (06/10/2011 17:15)   <#>
А если уборщицу исключить как угрозу и рассматривать чисто программную изоляцию данных? Просто Xen в минимальной функциональной форме сам по себе ничего такого не требует в применении к Linux'ам, даже аппаратной поддержки. Я понимаю, если бы они винду хотели в domU засунуть.
— Гость (06/10/2011 17:16)   <#>
почему бы и нет – сделать на основе открытой вещи что-то специализированное
Сама Рутковска ничего специально не закрывает и не опроприетаривает, насколько я понимаю.
— Гость (15/10/2011 05:55)   <#>
unknown, как мы поняли отсюда http://www.pgpru.com/forum/ano.....rbundleipaketnyjjtor и из рассылки Tor, Вы очень продвинулись в деле юзанья SELinux.
Может быть, напишите на досуге раздел в FAQ по данному вопросу?
— unknown (15/10/2011 20:07)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Там конечно много полезных вещей. Например запрет пинга не руту, просмотра dmesg и /proc по-умолчанию. Защита хотя бы таких стабильных программ, как ssh, dhcp или gpg.

Но вообще, SELinux всё ещё кривой и ужасный. По крайней мере в исполнении Debian. Приходиться использовать только стандартные политики (выучить и понять весь его синтаксис нет сил), выгружать часть глючных модулей (оставляя часть программ без защиты). Те модули, которые относительно успешно можно запустить хотя бы с глюками, есть возможность дополнять своими политиками в соответствии с тем, что выдаёт audit2allow, что есть неправильно и заведомо опасно (но лучше, чем совсем без них). И после каждого обновления есть шанс получить много геммороя с поиском причин глюков и перенастройкой. Стандартную поставку очень хреново обновляют. Иногда приходиться его полностью отключать (превращение защиты в театр). Но хоть какая-то защита (по принципу — в плане защиты SELinux не делает хуже, он может сделать "лучше, чем ничего" или ничего не сделать).

Надеюсь, что в будущем им можно будет пользоваться нормально. А так, поделиться в плане некривых и верных решений пока нечем.
— Гость (17/10/2011 23:34)   <#>
А что можно сказать про аналогичные решения усиления безопасности для платформы FreeBSD? Они существуют? они стабильны и эффективны или дело еще хуже чем с SELinux?
— Гость (18/10/2011 00:19)   <#>
что можно сказать про аналогичные решения усиления безопасности для платформы FreeBSD?
/comment34765
— Гость (20/10/2011 01:20)   <#>
Но хоть какая-то защита (по принципу — в плане защиты SELinux не делает хуже, он может сделать "лучше, чем ничего" или ничего не сделать).

Все эти замечания справедливы только в одном случае, когда отсутствует 0-day в ядре, т.е. будь-то мандатный контроль доступа и/или ролевой, он может дополнить заплатанное PAX/grsecurity ядро. Найти уязвимость наверное можно и в песочнице SELinux, а последняя представляет из себя модуль безопасности ядра, здесь об этом есть немного.
— Гость (03/06/2012 20:20, исправлен 04/06/2012 10:16)   <#>

Продолжение обсуждения от /comment52970


чтобы и не глючил, и лишнее не позволялось

А что ему может позволяться? Боитесь, что потрёт файлы чужих программ, или тех, с которыми работает? Если среда враждебная до такой степени исключительности, а данные настолько критичны, запускайте его от отдельного юзера, где больше ничего нет, предварительно дав ему копию файла для чтения. Если боитесь local root, запустите виртуалке, где ничего кроме него нет. И даже это, пожалуй, будет сделать намного проще и надёжней, чем самопальные правила для SELinux, собранные на коленке.

— Гость (03/06/2012 20:44)   <#>
Почему вы так уповаете на надёжность виртуалок? На форуме это обсуждалось уже.
— Гость (03/06/2012 21:35)   <#>

Ну обсуждалось, и что? Да, я когда-то обсуждал это с unknown'ом, теперь вы ссылаетесь в споре со мной на мой же пост, lol. Итог этих обсуждений я озвучивал в /comment38612. Раз уж на то пошло, обратите внимание и на критику SeLinux:

В итоге толку от обоих может быть мало — один плохо настраивается и толком не работает, другой добавляет столь мало безопасности, что иногда больше создаёт её иллюзию.

Работа, которую привели выше интересна тем, что на практике показывает, что реально используемые правила AppArmor немного безопаснее SELinux, но там рассматривается доступ, который злоумышленник может получить к дополнительным утилитам только определённым способом и не рассматриваются другие возможные способы.

Судя по количесту багов даже в правилах, поставляемых самими разработчикам SELinux, вполне возможно, что он хорош в теории, а на практике многое в плачевном состоянии.

Всё зависит от степени параноидальности настроек. Но по большому счёту, да эти security-панцири не панацея, а не более чем костыль.

Сложность — в создании правил компактного описания разрешений/запретов из-за сложности самого ядра.

Были и другие посты, суть которых сводилась к тому, что SELinux настолько сложен, что обычным пользователям (даже достаточно опытным) он попросту не под силу. Скорее, это уровень коммитеров в ядро, причём хорошо понимающих, как разные системы ОС/ядра взаимосвязаны между собой.

Если говорить на языке ИБ, векторы атаки для анонимов и для TdR совершенно разные. Что касается основного детища TdR, OpenBSD, в ней на local root сквозь пальцы смотрят, да и цитата
Only two remote holes in the default install, in a heck of a long time!
говорит о том же. Виртулаки — не панацеи, но довольно эффективны в качестве средства изоляции враждебного окружения как от сети, так и от знания реальных параметров железа. У разработчиков же OpenBSD анонимность, шифрование дисков и тому подобные вещи имеют низкий приоритет: «им нечего скрывать» на их рутерах, и уже тем более они не рассматривают получение к ним физического доступа атакующим.
— Гость (03/06/2012 22:32)   <#>
spinore, ну вы бы тогда подписывались что ли. Или я должен детектировать вас, хотя вы даже не потрудились имя в поле вписать? К чему упрёк?
Хотя, здесь похоже кроме вас с SATtva, да unknown и нет никого.
И я дал ссылку на цитату и дальнейшее обсуждение скорее, там в посте кроме неё ничего нет.

Что касается основного детища TdR, OpenBSD, в ней на local root сквозь пальцы смотрят
Смелое заявление. Подкрепите словами Тео? Цитата про remote holes ни о чём не говорит.

Насчёт сложности SELinux. Вы конечно же в курсе, что оно по дефолту включено в федоре? Пользователи, судя по всему, жалуются всё меньше и меньше (субъективно, конечно). Имеются подробные доки и кое-какие гуи-утилиты.
А вообще, я и не говорил, что оно простое. Но у меня больше доверия к нативной системе защиты, чем к сделанным совсем для других целей инструментам. Впрочем, в качестве quick&dirty решения — согласен, годится.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3