SELinux, AppArmor и др. системы безопасности
Цитата с другой ветки, обсуждение перенесено сюда в отдельно созданную тему.
> Но безопасность в контексте браузера это фантастика, на сегодняшний день.
SELinux по идее должен защищать пользовательское пространство от уязвимостей в приложениях. Правда я пока не освоил эту технику. Может кто из знающих людей покажет пример? Предположим, нужно изолировать браузер Firefox
Вот пример создания политики для гуглохрома:
http://danwalsh.livejournal.com/32759.html
Или пример использования киоск-режима:
http://danwalsh.livejournal.com/11913.html
Но всё вменяемо работает только в Федоре (в нём ведётся официальна разработка), в других дистрах поддержка SELinux не очень хорошая (местами плачевная) и стабильно отлажена только в расчёте на запуск серверов. Многих утилит, фич просто может не быть. Особенно для юзер-приложений и иксов.
А вы уже пробовали как-то работать хотя-бы с готовыми политиками? Про всякие тонкости с "domain transition" внятно себе представляете?
По SELinux практически нет ни манов ни доков, только книжки, разрозненные описания в расчёте на опору поддержки дистростроителями готовых политик (что хорошо делается только в Федоре).
Можно сделать одну систему, которая будет снапшотом для остальных, и все гостевые системы клонировать с этого доверенного снапшота (одного или нескольких).
Qubes поддерживает установку собственных гостевых ОС в Qubes штатным образом. По сути Qubes играет роль обычного гипервизора типа Xen, только с примесью юзерофилии. Я не разбирался глубоко, но там есть инструкции, как поставить любую гостевую ОС, натыкался даже на инструкции по установке
MinixNetBSD в Qubes.С этим не поспоришь, в этом надо быть аккуратным.
А мужики-то не знают!Да ладно?! Я вам написал короткий комментарий на эту тему.Местное wiki — это пипец. Чуть больше
140 символов8-ми страниц — и всё, коммент (да и любой документ вики) начинает обрезаться, форматирование — портиться. Из-за этого какие-то жалкие 15 страниц экранных разворотов приходится разбивать на несколько комментариев, неудобно. Кто такие драконовские лимиты на максимальных объём текста поставил?Вы сами всё сказали.
Как я понял из ваших постов, SELinux для анонимности (не путать с безопасностью), который бы позволял прятать от пользователя какую бы то ни было информацию о системе и железе, вообще не развивают. А раз так, фингерпринтинг таких систем всегда будет висеть дамокловым мечом.
LXC при чтении вызывает стойкие ассоциации с LHC.
Как я понял, основная идея Рутковской (да и не только её, сейчас так многие рассуждают) в том, что индустрия софта показала, что безопасных программ у нас не будет в наличии никогда. И именно с этим придётся смириться и жить. Надеяться, что для всех неидеальных программ будет один идеальный SELinux, который магически решит все их проблемы, несколько наивно. В конце концов, SELinux — это тоже программы, в них самих могут быть баги. Альтернатива — осознать проблему и сразу строить архитектуру безопасности/анонимности/ещё чего-нибудь (подставить нужное) так, чтобы бажность программ нейтрализовывались другими программами более высокого уровня.* Во всяком случае, нормально настроить такую архитектуру несоизмеримо проще, чем детально разобраться с SELinux'ом.** Более того, при апдейтах всё будет продолжать работать как и ранее — это не SELinux, где небольшое изменение ядра может порушить все SELinux-костыли, которые были до этого настроены. Да и вообще гипервизор как-то слабо зависит от внутренностей ОС. Какие-то такие мысли.
*ACL, разделение доступа, разделение осей, гипервизоры, физически выделенные машины и т.д., зависит от задачи.
**На свете есть хоть один человек, который идеально знает ядро Linux, и потому у него не вызывает каких-либо проблем настройка SELinux под любую задачу? Вы писали, что, например, всё Debian-коммунити, вместе взятое, так и не осилило базовые патчи SELinux под последний релиз.
комментариев: 9796 документов: 488 редакций: 5664
И так после каждого apt-get update; apt-get upgrade? Для всех n-цати анонимных профилей?
Получается, что:
Никто не надеется. Есть несколько векторов SELinux-защиты: отдельные программы, системные демоны и ограниченный пользователь (это неполный список).
С программами и демонами понятно. Для многих из них правил просто нет и они незащищены. Для других правила настолько глючат, что не допиливаются даже вручную. Для третьих вроде оно работает, но насколько это только видимость защиты — понять сложно.
С пользовательской ролью интереснее. Недоверенным пользователям (это все пользователи, которые ходят в сеть) по желанию присваивается роль с низкими привилегиями. Если они получат рута (что само по себе намного усложняется), он будет бесполезен. У него только UID=0, а SELinux-роль как у простого пользователя. Фактически — это не рут, чужих файлов и процессов он поиметь не может. У таких пользователей не работает sudo, ping, dmesg, ifconfig, доступ к /proc, запуск демонов из-под пользователя и много чего ещё. Это может спасти в случае уязвимости в TBB, но в особо хитрых случаях может быть и обойдено. Даёт ли это профилирование? В случае оптимального компромисса: если эксплойта нет — пользователь не отпрофилирован, если есть эксплойт — то он отпрофилирован, но только как невосприимчивый к этому эксплойту. Неплохой вариант компромисса. Хуже конечно, если эксплойт сможет обойти SELinux.
Там не только и не столько в ядре дело, но и во внутреннем синтаксисе SELinux. Не столько из-за ядра всё отваливается, сколько из-за всяких новых фич udev и пр.
Хуже то, что коммунити там никакое. В крайнем случае пишут модули и подкручивают правила на метаязыке, но исходный код кроме самого АНБ и его контракторов, похоже, вообще никто не пилит и не аудитит.
На самом деле, архитектуру надо серьёзно продумывать, но общие мысли таковы:
электрификации в тайгесети. Т.е. просто дом, в который можно прийти и поработать, где сеть не нужна.Ремонтироватьобновлять его можно редко.Не совсем так всё же. По возможности все нужные статические настройки софта вносятся в саму чистую копию, в снапшот. Далее команды сноса текущего дома rm -R и восстановления его из копии rdiff-backup -v5 -r now /снапшот /дом выполняются за секунды, поэтому большой проблемы не вижу. Да, есть вопрос дисциплины, надо себя приучить помнить, что любые изменения надо вносить в снэпшот или в него и в текущую версию сразу.
После каждого обновления TBB — да, безусловно. Кстати, чистой копии с TBB можно давать поработать в сети, чтобы она обросла свежей статистикой и сменила при необходимости guard'ы. По каким-либо сайтам из-под неё ходить, конечно, не надо.
При правильной инфраструктуре это как раз не страшно. Не обновили вы сейчас, не сделали амнезию в этой конкретной сесиии — не страшно. Главное — что есть готовая инфраструктура, и в любой момент времени позже вы можете навести порядок в системе, сделав всё, как надо. Когда же инфраструктуры нет вообще, сделать нельзя ничего. Если у вас утекли серийники, что мы можете сделать? Менять железо либо устанавливать гипервизор с набором осей, где и то и то — затратные действия, а если гипервизор с домами есть, достаточно обновить лишь проблемый дом. Если вы подозреваете взлом системы, что можно сделать, если система одна? Полностью переустанавливать, затрагивая вообще всё и все данные, останавливая всю работу со всем. Если же у вас подозрения по поводу конкретных жильцов конкретного дома, вы решаете эту проблему только с ним, а остальное продолжает работать, как работало даже без перезагрузки. Ну разве не удобно? Хостинги бы давно померли, если б все работали в одной ОС.
Так и я о том же: один раз помучаться с настройками для установки гипервизора и базовых домов, после чего можно менять системы, вносить обновления, и всё это не будет так накладно. То, что я предлагаю, не противоречит тому, что хотите вы. Вам никто не запрещает, если есть недостаток времени, держать временно один дом U с SELinux'ом и той его внутренней инфраструктурой, к которой вы привыкли. Но если вы хотите что-то поменять, какие-то программы или задачи переселить в другой дом, гипервизор у вас уже есть. Если же его нету, устанавливать его и настраивать (да ещё и с пробросом PCI-устройств) — занятие не для слабонервных.
Можно посмотреть в сторону не самых слабых ноутов. Мне наоборот кажется, что современные ноутбуки в несколько раз мощнее чем то, что реально необходимо. Конечно, они нашпигованы потенциальными или не совсем зловредами, с этим ничего не поделать.
В наш век место дешевеет быстрее, чем растут реальные потребности в нём. Терабайтный HDD лёгок и умещается в полладони. Куда вам больше? Для лишних домов можно использовать внешние диски.
Запрет доступа к программам хорош, когда те суидны. Если же не суидны, то вопрос надо ставить не о доступе к готовым программам, а о доступе к определённым библиотечным вызовам. Например, dmesg не суиден. Кто такому пользователю запретит написать собственный dmesg, скомпилить его сорсы и запустить? Конечно, все запреты должны быть фичами ядра, а не правами доступа к исполнимым несуидным файлам (к слову, так же можно обойти и запрет просмотра списков процессов, если какой-то умный админ убрал права с ps).
комментариев: 11558 документов: 1036 редакций: 4118
Насколько я понимаю, ограничения пользовательских привилегий в SELinux основаны на фильтрации системных вызовов.
Ядро.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 301 документов: 8 редакций: 4
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 301 документов: 8 редакций: 4
Network Associates Laboratories (NAI Labs) – это та компания, где Ф.Циммерманн был Senior Fellow и она специализировалась на криптографии?
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 301 документов: 8 редакций: 4
А кто утверждал, что он был акционером? Вы о чем-то о своём…
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 301 документов: 8 редакций: 4
http://en.wikipedia.org/wiki/Phil_Zimmermann
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 301 документов: 8 редакций: 4