id: Гость   вход   регистрация
текущее время 22:49 28/03/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 След.
Комментарии
— Гость (06/07/2012 08:45)   <#>
P.S.: Цитата взята с этой ссылки, забыл вставить.
— neverward (06/07/2012 10:23, исправлен 06/07/2012 10:36)   профиль/связь   <#>
комментариев: 43   документов: 0   редакций: 7
Это какой-то дешёвый гипервизор, раз он в ring 1

1 != -1
правда ring -1 у amd вроде только


Разве? Ну системные квоты же есть. Их можно заранее постестировать на эффективных fork-бомбах типа

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

— Гость (06/07/2012 10:54)   <#>
Как же тогда хостинги живут в такой агрессивной среде? Любой клиент виртуалки может повесить весь хостинг?

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

Квота на CPU и память тоже выделяется Xen'ом (и даже динамически регулируема на лету — сколько из баллона надуешь, столько и будет).
— neverward (09/07/2012 17:38)   профиль/связь   <#>
комментариев: 43   документов: 0   редакций: 7
Как же тогда хостинги живут в такой агрессивной среде? Любой клиент виртуалки может повесить весь хостинг?

в openVZ или Jail таки да, один клиент может грохнуть всех других. Может также не запустится что нибудь, что требует 10 мб при свободных 200мб. Есть ещё много других радостей от прокачанного chroot.

Если речь вести о паравиртуализации, то там всё лучше, можно сказать всё по честному, но без hvm всё равно поломается что нибудь вроде SElinux, ну и windows нельзя будет запустить, что уже говорит о том, что гостевая ОС должна быть подготовлена специальным образом, т.е. не что хочешь, то и ставишь. hvm позволяет запустить почти что угодно в качестве гостевой ОС
— Гость (09/07/2012 18:05)   <#>

Ну, наверное, на хостинге считают дыры в гипервизорах исключительным явлением? А без этого всё равно никуда не уехать. SELinux — это скорее защита внутри ОС от опасностей, исходящих из самой ОС, а не от соседних гостевых ОС. Хотя unknown писал, что и к виртуалкам его прикручивают.


Да, это понятно. Но для домашнего использования самое важное упущение не это, а то, что проброс PCI-устройств без хардварной поддержки (HVM) не заработает.
— neverward (10/07/2012 11:36)   профиль/связь   <#>
комментариев: 43   документов: 0   редакций: 7
Ну, наверное, на хостинге считают дыры в гипервизорах исключительным явлением?
например у амазона около 0.5 млн физических серверов. Если в гипервизоре будет дырка, то все 0.5 млн серверов можно смело считать скомпрометированными. Думаю прилагаются большие финансовые усилия в обеспечении изоляции виритуальных машин друг от друга.
Хотя unknown писал, что и к виртуалкам его прикручивают.

Да, но не понятно где выполняется SE, в ring3 что ли?

а, это понятно. Но для домашнего использования самое важное упущение не это, а то, что проброс PCI-устройств без хардварной поддержки (HVM) не заработает.

Да, совсем забыл, игры не запустить будет.
— unknown (10/07/2012 11:55)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
А насколько сложно на практике поддерживать виртуализированную ОС в актуальном состоянии со всеми апдейтами и пр.?

Сложность не только первоначальной установки/настройки, но и регулярного обновления/обслуживания используется как один из аргументов в пользу AppArmor/SELinux/etc.

Если в системе есть какие-то стабильные сервисы, которые надо защищать в первую очередь (к сожалению, tor не очень стабилен, но проблемы с ним в SELinux разрулить оказалось несложно), то можно их обновлять, и если применять на пользовательской машине параллельные иксы или квазивиртуализацию LXC, то достаточно делать стандартным образом каждый раз только одно обновление для общей системы.

Если же есть масса раздельных, тщательно изолированных друг от друга виртуалок, да и ещё запутанных слоями-каскадами, то поддержание всей этой структуры в актуальном состоянии кажется сложным.
— neverward (10/07/2012 13:32, исправлен 10/07/2012 13:36)   профиль/связь   <#>
комментариев: 43   документов: 0   редакций: 7

Для удобства рассматриваем XEN HVM.

А насколько сложно на практике поддерживать виртуализированную ОС в актуальном состоянии со всеми апдейтами и пр.?

Точно также, как обычную ОС на выделенном сервере

Сложность не только первоначальной установки/настройки, но и регулярного обновления/обслуживания используется как один из аргументов в пользу AppArmor/SELinux/etc.

AppArmor и SE не заметят такой виртуализации. Настройка гостевой ОС не требуется почти никогда( конечно ОС внезапно могут понадобиться какие нибудь железки, которые XEN не виртуализирует. Тогда будет плохо )

Если в системе есть какие-то стабильные сервисы, которые надо защищать в первую очередь (к сожалению, tor не очень стабилен, но проблемы с ним в SELinux разрулить оказалось несложно), то можно их обновлять, и если применять на пользовательской машине параллельные иксы или квазивиртуализацию LXC, то достаточно делать стандартным образом каждый раз только одно обновление для общей системы.

В данном вопросе ситуация с hvm равнозначна ситуации с несколькими физическими серверами. Т.е. если tor у нас на отдельной машине, то хватит одного обновления.


Если же есть масса раздельных, тщательно изолированных друг от друга виртуалок, да и ещё запутанных слоями-каскадами, то поддержание всей этой структуры в актуальном состоянии кажется сложным.

есть xenconsole и вообще у всех гостевых ОС есть устройство терминал и сетевая карта, которые может дёргать хост. Вопрос в том как передать правильные обновления гостевым ОС. Можно настроить NAT, чтобы гостевые системы могли обновляться. Тут конечно вопрос насколько надёжен NAT и система обновления, но это от виртуализации не зависит. Хоть на реально изолированных серверах будет тот же вопрос.

— Гость (10/07/2012 23:46)   <#>

Кто о чём :) Я имел в виду, что звука на будет, например. Точнее, мне трудно представить, как прозрачно туннелировать весь звук из domU в dom0. Аналогов xennet и xbd для звуковой я не видел. Может быть, в Linux они есть?


Чем-то оно даже проще: новую сборку можно заранее собрать в каком-то domU и протестировать, а потом централизованно накатить её на все остальные домены.


Это что-то типа
# xm dmesg
?


В NetBSD по умолчанию у гостевых ОС нет ни доступа к терминалу, ни к сетевой карте. Доступ — из-под виртуального сетевого интерфейса, бриджа. Если вы решили потом, пользуясь hvm, дать полный доступ к сетевой карте или какой-то tty-консоли — это уже на свой страх и риск.
— neverward (11/07/2012 15:29)   профиль/связь   <#>
комментариев: 43   документов: 0   редакций: 7
Я имел в виду, что звука на будет, например
звук можно настроить, у линуксов сейчас звуковая подсистема позволяет передавать прозрачно звук по сети на другой компьютер.
Это что-то типа

xm console domUname
В NetBSD по умолчанию у гостевых ОС нет ни доступа к терминалу, ни к сетевой карте
Как нет, при создании domu виртуальная карта у гостя точно появляется, и виртуальное последовательное устройство тоже должно появляться( правда последнее перепиливали несколько раз, потому гарантировать нельзя )
— Гость (02/12/2012 05:18)   <#>
SELinux не может быть использован для блокирования проблемы, так как он делегирует qemu отправку ioctl для дисков, без привязки к отдельным разделам.
Это правда, что SeLinux никак не помогает от подобных уязвимостей?
— unknown (02/12/2012 12:26)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
По поводу модулей для виртуалок.

У SELinux есть какие-то готовые модули для этого, но как обычно, если внутри не ковыряться, то это вещь в себе, несмотря на то, что часть параметров в модулях обычно можно настраивать без компиляции.

В предыдущем абзаце получился стандартный образец отговорки, характерный для всех случаев, когда нечего конкретно сказать про SELinux ;-) Может кто-то разбирал подробнее.
— Гость (02/08/2013 22:18)   <#>
filearch-spec-0.3.pdf:

1.2. Why new OS?

Authors of this document do not believe that, at any time in the foreseeable future, we would be able to patch all the bugs in the software we use, as well as detect all the malicious software. Consequently we need a different approach to build secure systems.

Obviously building a new OS can be a very time consuming task. Thats why, with Qubes OS, we reuse as much ready-to-use building blocks as possible, in particular the Xen hypervisor. This in turn implies the use of virtualization technology, which is used for two primary reasons: offering excellent security isolation properties, as well as the ability to reuse the large amount of software, including most of the applications and drivers written for mainstream OSes, like Linux or Windows.

UserFaq:

But still, all the other Qubes security mechanisms, such as AppVM separation, work as usual, and you still end up with a significantly secure OS, much more secure then Windows, Mac, or Linux, even if you don't have VT-d'''

Unknown, вглядитесь внимательно в глаза этой женщины. Как вы думаете, стоит ли ей верить? Уже три года прошло с тех пор, как вы вынесли тему на обсуждение.

Оформление интернет-страничек с публикациями у неё интересное, оригинальное.

P.S. Навеяно комментом
Везде сейчас понавтыкали, что же ставить, debian?
— Гость (02/08/2013 22:21)   <#>

Хотел сказать «Появилось ли что-то новое в плане мнения открытого сообщества по поводу её подхода?».
— unknown (03/08/2013 14:41, исправлен 03/08/2013 14:49)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Наивный подход к виртуалкам ведёт к ресурсоёмкости и затратности: при обновлениях системы нужно обновить каждую виртуалку. Как у неё это там автоматизировано — не знаю. Переходить на другую параллельно загружаемую ось для безопасной работы — это надоедливый дуалбут.


Что ещё неприятно с виртуалками — всевозможные /dev/(u)random для сильного противника в них превращаются в тыкву. Даже если подключить доверяемый аппаратный ГПСЧ, то нужен специальный демон-брокер энтропии, который корректно транслирует энтропию внутрь каждой виртуалки. Никто всерьёз это не воспринимает и не использует.


Интереснее подход с псевдовиртуалками (LXC). Сами по себе они не дают безопасности (рут в LXC = рут в системе и выход из псевдовиртуалки). Но для LXC уже сейчас есть специальные правила SELinux, которые исключают такую возможность, делая их допустимо безопасными. Стоит отметить, что проблема анонимности за счёт профилирования железа при этом не решается.


В будущем LXC планируется допилить до безопасного состояния, чтобы даже SELinux был не нужен. Это имеет не только перспективы для безопасности, но и коммерческого применения (хостинги на однотипных версиях ОС). И всяко больше шансов интеграции с обычной ОС.

На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3