SELinux, AppArmor и др. системы безопасности
Цитата с другой ветки, обсуждение перенесено сюда в отдельно созданную тему.
> Но безопасность в контексте браузера это фантастика, на сегодняшний день.
SELinux по идее должен защищать пользовательское пространство от уязвимостей в приложениях. Правда я пока не освоил эту технику. Может кто из знающих людей покажет пример? Предположим, нужно изолировать браузер Firefox
Вот пример создания политики для гуглохрома:
http://danwalsh.livejournal.com/32759.html
Или пример использования киоск-режима:
http://danwalsh.livejournal.com/11913.html
Но всё вменяемо работает только в Федоре (в нём ведётся официальна разработка), в других дистрах поддержка SELinux не очень хорошая (местами плачевная) и стабильно отлажена только в расчёте на запуск серверов. Многих утилит, фич просто может не быть. Особенно для юзер-приложений и иксов.
А вы уже пробовали как-то работать хотя-бы с готовыми политиками? Про всякие тонкости с "domain transition" внятно себе представляете?
По SELinux практически нет ни манов ни доков, только книжки, разрозненные описания в расчёте на опору поддержки дистростроителями готовых политик (что хорошо делается только в Федоре).
комментариев: 43 документов: 0 редакций: 7
1 != -1
правда ring -1 у amd вроде только
если атаковать скажем по нагруженному запросу сервер( для удобства пусть будет запрос к БД), то либо БД займёт все ресурсы если на неё квот нет, либо она будет очень плохо работать когда ресурсы есть. Даже двухуровневые квоты не спасают, это основная проблема серверов openvz
В контексте анонимности никто не запрещает сделать физически разные диски для разных гостевых ОС. Этим проблема с БД решается. Да и если пользователь находится за компьютером, вряд ли он не заметит перегрузки по ресурсам, причём такой, которая сразу на обеих гостевых ОС (где работают разные программы и решаются разные задачи).
Квота на CPU и память тоже выделяется Xen'ом (и даже динамически регулируема на лету — сколько из баллона надуешь, столько и будет).
комментариев: 43 документов: 0 редакций: 7
в openVZ или Jail таки да, один клиент может грохнуть всех других. Может также не запустится что нибудь, что требует 10 мб при свободных 200мб. Есть ещё много других радостей от прокачанного chroot.
Если речь вести о паравиртуализации, то там всё лучше, можно сказать всё по честному, но без hvm всё равно поломается что нибудь вроде SElinux, ну и windows нельзя будет запустить, что уже говорит о том, что гостевая ОС должна быть подготовлена специальным образом, т.е. не что хочешь, то и ставишь. hvm позволяет запустить почти что угодно в качестве гостевой ОС
Ну, наверное, на хостинге считают дыры в гипервизорах исключительным явлением? А без этого всё равно никуда не уехать. SELinux — это скорее защита внутри ОС от опасностей, исходящих из самой ОС, а не от соседних гостевых ОС. Хотя unknown писал, что и к виртуалкам его прикручивают.
Да, это понятно. Но для домашнего использования самое важное упущение не это, а то, что проброс PCI-устройств без хардварной поддержки (HVM) не заработает.
комментариев: 43 документов: 0 редакций: 7
Да, но не понятно где выполняется SE, в ring3 что ли?
Да, совсем забыл, игры не запустить будет.
комментариев: 9796 документов: 488 редакций: 5664
Сложность не только первоначальной установки/настройки, но и регулярного обновления/обслуживания используется как один из аргументов в пользу AppArmor/SELinux/etc.
Если в системе есть какие-то стабильные сервисы, которые надо защищать в первую очередь (к сожалению, tor не очень стабилен, но проблемы с ним в SELinux разрулить оказалось несложно), то можно их обновлять, и если применять на пользовательской машине параллельные иксы или квазивиртуализацию LXC, то достаточно делать стандартным образом каждый раз только одно обновление для общей системы.
Если же есть масса раздельных, тщательно изолированных друг от друга виртуалок, да и ещё запутанных слоями-каскадами, то поддержание всей этой структуры в актуальном состоянии кажется сложным.
комментариев: 43 документов: 0 редакций: 7
Для удобства рассматриваем XEN HVM.
Точно также, как обычную ОС на выделенном сервере
AppArmor и SE не заметят такой виртуализации. Настройка гостевой ОС не требуется почти никогда( конечно ОС внезапно могут понадобиться какие нибудь железки, которые XEN не виртуализирует. Тогда будет плохо )
В данном вопросе ситуация с hvm равнозначна ситуации с несколькими физическими серверами. Т.е. если tor у нас на отдельной машине, то хватит одного обновления.
есть xenconsole и вообще у всех гостевых ОС есть устройство терминал и сетевая карта, которые может дёргать хост. Вопрос в том как передать правильные обновления гостевым ОС. Можно настроить NAT, чтобы гостевые системы могли обновляться. Тут конечно вопрос насколько надёжен NAT и система обновления, но это от виртуализации не зависит. Хоть на реально изолированных серверах будет тот же вопрос.
Кто о чём :) Я имел в виду, что звука на будет, например. Точнее, мне трудно представить, как прозрачно туннелировать весь звук из domU в dom0. Аналогов xennet и xbd для звуковой я не видел. Может быть, в Linux они есть?
Чем-то оно даже проще: новую сборку можно заранее собрать в каком-то domU и протестировать, а потом централизованно накатить её на все остальные домены.
Это что-то типа
В NetBSD по умолчанию у гостевых ОС нет ни доступа к терминалу, ни к сетевой карте. Доступ — из-под виртуального сетевого интерфейса, бриджа. Если вы решили потом, пользуясь hvm, дать полный доступ к сетевой карте или какой-то tty-консоли — это уже на свой страх и риск.
комментариев: 43 документов: 0 редакций: 7
xm console domUname
Как нет, при создании domu виртуальная карта у гостя точно появляется, и виртуальное последовательное устройство тоже должно появляться( правда последнее перепиливали несколько раз, потому гарантировать нельзя )
комментариев: 9796 документов: 488 редакций: 5664
У SELinux есть какие-то готовые модули для этого, но как обычно, если внутри не ковыряться, то это вещь в себе, несмотря на то, что часть параметров в модулях обычно можно настраивать без компиляции.
В предыдущем абзаце получился стандартный образец отговорки, характерный для всех случаев, когда нечего конкретно сказать про SELinux ;-) Может кто-то разбирал подробнее.
UserFaq:
Unknown, вглядитесь внимательно в глаза этой женщины. Как вы думаете, стоит ли ей верить? Уже три года прошло с тех пор, как вы вынесли тему на обсуждение.
Оформление интернет-страничек с публикациями у неё интересное, оригинальное.
P.S. Навеяно комментом
Хотел сказать «Появилось ли что-то новое в плане мнения открытого сообщества по поводу её подхода?».
комментариев: 9796 документов: 488 редакций: 5664
Наивный подход к виртуалкам ведёт к ресурсоёмкости и затратности: при обновлениях системы нужно обновить каждую виртуалку. Как у неё это там автоматизировано — не знаю. Переходить на другую параллельно загружаемую ось для безопасной работы — это надоедливый дуалбут.
Что ещё неприятно с виртуалками — всевозможные /dev/(u)random для сильного противника в них превращаются в тыкву. Даже если подключить доверяемый аппаратный ГПСЧ, то нужен специальный демон-брокер энтропии, который корректно транслирует энтропию внутрь каждой виртуалки. Никто всерьёз это не воспринимает и не использует.
Интереснее подход с псевдовиртуалками (LXC). Сами по себе они не дают безопасности (рут в LXC = рут в системе и выход из псевдовиртуалки). Но для LXC уже сейчас есть специальные правила SELinux, которые исключают такую возможность, делая их допустимо безопасными. Стоит отметить, что проблема анонимности за счёт профилирования железа при этом не решается.
В будущем LXC планируется допилить до безопасного состояния, чтобы даже SELinux был не нужен. Это имеет не только перспективы для безопасности, но и коммерческого применения (хостинги на однотипных версиях ОС). И всяко больше шансов интеграции с обычной ОС.