id: Гость   вход   регистрация
текущее время 17:07 29/03/2024
Автор темы: unknown, тема открыта 11/04/2010 21:58 Печать
http://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/08/2013 21:55)   <#>

Можно сделать одну систему, которая будет снапшотом для остальных, и все гостевые системы клонировать с этого доверенного снапшота (одного или нескольких).


Qubes поддерживает установку собственных гостевых ОС в Qubes штатным образом. По сути Qubes играет роль обычного гипервизора типа Xen, только с примесью юзерофилии. Я не разбирался глубоко, но там есть инструкции, как поставить любую гостевую ОС, натыкался даже на инструкции по установке Minix NetBSD в Qubes.


С этим не поспоришь, в этом надо быть аккуратным.


А мужики-то не знают! Да ладно?! Я вам написал короткий комментарий на эту тему.

Местное wiki — это пипец. Чуть больше 140 символов 8-ми страниц — и всё, коммент (да и любой документ вики) начинает обрезаться, форматирование — портиться. Из-за этого какие-то жалкие 15 страниц экранных разворотов приходится разбивать на несколько комментариев, неудобно. Кто такие драконовские лимиты на максимальных объём текста поставил?


Вы сами всё сказали.


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

LXC при чтении вызывает стойкие ассоциации с LHC.

Как я понял, основная идея Рутковской (да и не только её, сейчас так многие рассуждают) в том, что индустрия софта показала, что безопасных программ у нас не будет в наличии никогда. И именно с этим придётся смириться и жить. Надеяться, что для всех неидеальных программ будет один идеальный SELinux, который магически решит все их проблемы, несколько наивно. В конце концов, SELinux — это тоже программы, в них самих могут быть баги. Альтернатива — осознать проблему и сразу строить архитектуру безопасности/анонимности/ещё чего-нибудь (подставить нужное) так, чтобы бажность программ нейтрализовывались другими программами более высокого уровня.* Во всяком случае, нормально настроить такую архитектуру несоизмеримо проще, чем детально разобраться с SELinux'ом.** Более того, при апдейтах всё будет продолжать работать как и ранее — это не SELinux, где небольшое изменение ядра может порушить все SELinux-костыли, которые были до этого настроены. Да и вообще гипервизор как-то слабо зависит от внутренностей ОС. Какие-то такие мысли.


*ACL, разделение доступа, разделение осей, гипервизоры, физически выделенные машины и т.д., зависит от задачи.
**На свете есть хоть один человек, который идеально знает ядро Linux, и потому у него не вызывает каких-либо проблем настройка SELinux под любую задачу? Вы писали, что, например, всё Debian-коммунити, вместе взятое, так и не осилило базовые патчи SELinux под последний релиз.
— unknown (07/08/2013 11:24)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Можно сделать одну систему, которая будет снапшотом для остальных, и все гостевые системы клонировать с этого доверенного снапшота (одного или нескольких).

И так после каждого apt-get update; apt-get upgrade? Для всех n-цати анонимных профилей?

Получается, что:
  1. Нужно повторять процедуру клонирования снэпшотов при каждом обновлении пакетов в системе, что бывает довольно часто при обновлениях безопасности. Вот включил комп, увидел, что надо обновиться и всё готово одной командой. А с виртуалками — это будет каждый раз морока. Скриптование не поможет: см. ниже.
  2. В каждом склонированном снэпшоте может потребоваться применить разный профиль настроек. После клонирования их придёться накатывать заново. Скорее всего с разбором вручную. Эта проблема есть даже без виртуалок в TBB, поскольку он не идёт пакетом, его приходиться распаковывать и заново настраивать в разных анонимных профилях. Хватит гемора хотя бы только с ним, а не со всеми пакетами системы. А настройки могут быть разными. Где-то нельзя иметь закладок и сохранённых документов, а где-то наоборот — некритично и желательно для удобства. Ладно, когда это только один TBB. А когда много пакетов? При первом же признаке нехватки времени и усталости самого продвинутого пользователя — лень победит паранойю. Должен быть компромисс в сторону средней степени удобства. По принципу: хотя бы один раз помучаться с настройками, а затем всё работает.
  3. В разных профилях могут быть не только одинаковые пакеты с разными настройками, но и может быть разный набор пакетов с разными настройками. Где-то нужен, например, GIMP или LaTeX, или Office, или ещё чего, и в каждом профиле свои настройки. Как это расклонировать, сохранять и накатывать настройки каждый раз?
  4. Ресурсоёмкость. Даже один TBB в последних версиях тормозит на слабых ноутах. А если запустить несколько параллельно, да ещё в виртуалках, чтобы пока один чего-то качает, в другом смотреть другие сайты, не пересекаясь профилями? Плюс масса тяжеловесных повторяющихся пакетов для каждой виртуалки тупо занимает место.

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

Никто не надеется. Есть несколько векторов SELinux-защиты: отдельные программы, системные демоны и ограниченный пользователь (это неполный список).

С программами и демонами понятно. Для многих из них правил просто нет и они незащищены. Для других правила настолько глючат, что не допиливаются даже вручную. Для третьих вроде оно работает, но насколько это только видимость защиты — понять сложно.

С пользовательской ролью интереснее. Недоверенным пользователям (это все пользователи, которые ходят в сеть) по желанию присваивается роль с низкими привилегиями. Если они получат рута (что само по себе намного усложняется), он будет бесполезен. У него только UID=0, а SELinux-роль как у простого пользователя. Фактически — это не рут, чужих файлов и процессов он поиметь не может. У таких пользователей не работает sudo, ping, dmesg, ifconfig, доступ к /proc, запуск демонов из-под пользователя и много чего ещё. Это может спасти в случае уязвимости в TBB, но в особо хитрых случаях может быть и обойдено. Даёт ли это профилирование? В случае оптимального компромисса: если эксплойта нет — пользователь не отпрофилирован, если есть эксплойт — то он отпрофилирован, но только как невосприимчивый к этому эксплойту. Неплохой вариант компромисса. Хуже конечно, если эксплойт сможет обойти SELinux.

На свете есть хоть один человек, который идеально знает ядро Linux, и потому у него не вызывает каких-либо проблем настройка SELinux под любую задачу? Вы писали, что, например, всё Debian-коммунити, вместе взятое, так и не осилило базовые патчи SELinux под последний релиз.

Там не только и не столько в ядре дело, но и во внутреннем синтаксисе SELinux. Не столько из-за ядра всё отваливается, сколько из-за всяких новых фич udev и пр.

В конце концов, SELinux — это тоже программы, в них самих могут быть баги.

Хуже то, что коммунити там никакое. В крайнем случае пишут модули и подкручивают правила на метаязыке, но исходный код кроме самого АНБ и его контракторов, похоже, вообще никто не пилит и не аудитит.
— Гость (07/08/2013 12:52)   <#>

На самом деле, архитектуру надо серьёзно продумывать, но общие мысли таковы:
  1. В нулевом доме нет ничего, кроме firewall'а и разруливания сети. Это сугубо административная система. Там даже иксы не факт, что должны быть (видеокарту можно пробросить в дом U?).
  2. В домах U сидит всё: и анонимные профили и неанонимные. Не думаю, что под каждую софтину нужно выделять свой дом, скорее нужно расклассифицировать софт и задачи по группам, и каждой группе назначить свой дом. Как мне представляется, n-цать домов не наберётся, но, как минимум, нужны следующие дома:
    1. Дом без электрификации в тайге сети. Т.е. просто дом, в который можно прийти и поработать, где сеть не нужна. Ремонтировать обновлять его можно редко.
    2. Абсолютно анонимный дом. Обновления будут сравнительно частыми.
    3. Абсолютно неанонимный дом. Да, такое тоже бывает нужным.
    4. Частино анонимный дом.
    5. <ещё какие-то задачи>
  3. Дома могут быть со снапшотами и без.
    1. Дом без сети можно вообще не обновлять.
    2. С абсолютно анонимным домом всё так, да: к нему хранится персональная чистая копия, по сути — вспомогательный дом. Чистую копию время от времени обновляем. Перед началом работы в доме его состояние каждый раз клонируется из чистой копии, т.е. из снапшота. Сохранение любой информации внутри дома возможно только на дополнительный виртуальный диск, информация из которого вычищается по окончании работы и перемещается в тот дом, который с сетью не работает вообще. Если для сеанса работы нужна какая-то уже имеющаяся информация, она предварительно вносится на виртуальный диск. Если такая информация нужна постоянно, её можно сделать частью снапшота (чистой копии). Можно реализовать и патчами к чистой копии, это зависит от задачи. Обычно требуется набор каких-то файлов. Заскриптовать команду cp -Rv не трудно.
    3. Абсолютно неанонимный дом можно обновлять как обычную ОС в реальном времени. Снапшота не будет, чистой копии тоже. Точнее, чистые копии должны быть для профилей конкретных пользователей, работающих в этом доме. Этого достаточно.
    4. Частично анонимный дом можно сделать по образцу B с какими-то поблажками. Или по образцу C с какими-то усилениями.
  4. Пусть D делается так же, как B, тогда можно оценить сверху число нужных машин: A — 1, B — 2, C — 1, D — 2. Итого имеем 6 домов, из которых 2 вспомогательных. Число разных ОС: B, C и D должны иметь разные ОС; опционально для С и D можно использовать одну ОС, в крайнем случае. Остальные могут иметь ОС, совпадающие с какой-то (например, какая разница, что в A, если доступ в сеть дом А не имеет?). Итак, регулярно нужно обновлять где-то 3 разных ОС, из которых только 2 через вспомогательные чистые копии, а одну — напрямую без заморочек.
  5. Там, где нужно клонирование снэпшотов или конкретных профилей, увы, этого не избежать, зато это даёт небывалую гибкость и защиту. Надо приучить себя к амнезии, т.е. не копить мусор. Всё, что важно, после работы переносить в статичную БД, остальное сносить. Всё браузерное, что работает с интернетом, должно иметь амнезию либо на уровне всего дома, либо на уровне конкретного пользователя.


Не совсем так всё же. По возможности все нужные статические настройки софта вносятся в саму чистую копию, в снапшот. Далее команды сноса текущего дома rm -R и восстановления его из копии rdiff-backup -v5 -r now /снапшот /дом выполняются за секунды, поэтому большой проблемы не вижу. Да, есть вопрос дисциплины, надо себя приучить помнить, что любые изменения надо вносить в снэпшот или в него и в текущую версию сразу.


После каждого обновления TBB — да, безусловно. Кстати, чистой копии с TBB можно давать поработать в сети, чтобы она обросла свежей статистикой и сменила при необходимости guard'ы. По каким-либо сайтам из-под неё ходить, конечно, не надо.


При правильной инфраструктуре это как раз не страшно. Не обновили вы сейчас, не сделали амнезию в этой конкретной сесиии — не страшно. Главное — что есть готовая инфраструктура, и в любой момент времени позже вы можете навести порядок в системе, сделав всё, как надо. Когда же инфраструктуры нет вообще, сделать нельзя ничего. Если у вас утекли серийники, что мы можете сделать? Менять железо либо устанавливать гипервизор с набором осей, где и то и то — затратные действия, а если гипервизор с домами есть, достаточно обновить лишь проблемый дом. Если вы подозреваете взлом системы, что можно сделать, если система одна? Полностью переустанавливать, затрагивая вообще всё и все данные, останавливая всю работу со всем. Если же у вас подозрения по поводу конкретных жильцов конкретного дома, вы решаете эту проблему только с ним, а остальное продолжает работать, как работало даже без перезагрузки. Ну разве не удобно? Хостинги бы давно померли, если б все работали в одной ОС.


Так и я о том же: один раз помучаться с настройками для установки гипервизора и базовых домов, после чего можно менять системы, вносить обновления, и всё это не будет так накладно. То, что я предлагаю, не противоречит тому, что хотите вы. Вам никто не запрещает, если есть недостаток времени, держать временно один дом U с SELinux'ом и той его внутренней инфраструктурой, к которой вы привыкли. Но если вы хотите что-то поменять, какие-то программы или задачи переселить в другой дом, гипервизор у вас уже есть. Если же его нету, устанавливать его и настраивать (да ещё и с пробросом PCI-устройств) — занятие не для слабонервных.


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


В наш век место дешевеет быстрее, чем растут реальные потребности в нём. Терабайтный HDD лёгок и умещается в полладони. Куда вам больше? Для лишних домов можно использовать внешние диски.


Запрет доступа к программам хорош, когда те суидны. Если же не суидны, то вопрос надо ставить не о доступе к готовым программам, а о доступе к определённым библиотечным вызовам. Например, dmesg не суиден. Кто такому пользователю запретит написать собственный dmesg, скомпилить его сорсы и запустить? Конечно, все запреты должны быть фичами ядра, а не правами доступа к исполнимым несуидным файлам (к слову, так же можно обойти и запрет просмотра списков процессов, если какой-то умный админ убрал права с ps).
— SATtva (07/08/2013 13:31)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Запрет доступа к программам хорош, когда те суидны. Если же не суидны, то вопрос надо ставить не о доступе к готовым программам, а о доступе к определённым библиотечным вызовам.

Насколько я понимаю, ограничения пользовательских привилегий в SELinux основаны на фильтрации системных вызовов.

Например, dmesg не суиден. Кто такому пользователю запретит написать собственный dmesg, скомпилить его сорсы и запустить?

Ядро.
— unknown (07/08/2013 14:37)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Верно. Свои программы написать можно, но они также не будут работать, поскольку SELinux им не выдаст соответствующих capabilities. В этом, кстати, существенное отличие SELinux от AppArmor и других ACL-решений.
— Гость (09/08/2013 11:10)   <#>
Согласен с обоими ораторами. Коммент про права к файлам и про «у таких пользователей не работает» был сделан только для большей ясности, чтобы публика не обольщалась таким закручиванием гаек, если что.
— тестерТьюринга (19/08/2013 11:25)   профиль/связь   <#>
комментариев: 301   документов: 8   редакций: 4
Ранее сообщали, что ядро не получается пересобрать полностью компилятором clang-llvm, из-ка кода по большей части связанного с криптографией(SELinux, IPSec, eCrypt). Потом появилась инфа, что пересобранное ядро удалось запустить. SELinux переписали или ядро запустили обходными путями?
— unknown (19/08/2013 12:57)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
SELinux не связан с криптографией, как и часть ещё чего-то, что мешало собрать ядро на clang. Но собирались рабочие ядра без этих фич, если они кому-то не нужны. Как там с этим сейчас — не в курсе.
— тестерТьюринга (20/08/2013 21:28)   профиль/связь   <#>
комментариев: 301   документов: 8   редакций: 4
http://www.nsa.gov/research/selinux/contrib.shtml
Network Associates Laboratories (NAI Labs) – это та компания, где Ф.Циммерманн был Senior Fellow и она специализировалась на криптографии?
— SATtva (21/08/2013 08:49)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Всё не так: NAI (ныне McAfee) не специализировалась на криптографии, Циммерманн не был акционером. Учите историю.
— тестерТьюринга (21/08/2013 09:32, исправлен 21/08/2013 09:37)   профиль/связь   <#>
комментариев: 301   документов: 8   редакций: 4
Циммерманн не был акционером

А кто утверждал, что он был акционером? Вы о чем-то о своём…

— SATtva (21/08/2013 09:48)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
А при чём тут senior fellow в Вашем посте?
— тестерТьюринга (21/08/2013 10:25)   профиль/связь   <#>
комментариев: 301   документов: 8   редакций: 4
Учите историю ;)
http://en.wikipedia.org/wiki/Phil_Zimmermann
That company was acquired by Network Associates (NAI) in December 1997, and Zimmermann stayed on for three years as a Senior Fellow.

— unknown (21/08/2013 10:53)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Похоже, ссылка старая. SELinux уже давно разрабатывает преимущественно компания Tresys Technology.
— тестерТьюринга (21/08/2013 12:16)   профиль/связь   <#>
комментариев: 301   документов: 8   редакций: 4
Вообще, к чему я веду, вопрос в том, имеет ли SElinux недокументированные возможности(backdoor, проще говоря). Их наличие без криптографии выглядело бы непрофессионально. Я далек от мысли, что руководство АНБ построило разработчиков и зачитало приказ – писать шпионскую программу. Такой код мог появиться на любой стадии разработки, но, вероятнее всего, когда она находилась под полным контролем АНБ. Само АНБ указало ключевого внедренца как NAI Labs (не McAfee или ещё как-то), история покупок/продаж/перепродаж которой какая-то мутная – по одним wiki-страницам, с ещё как-то проверяемой информацией, лично мне ничего не понятно. Очень походит на фирмы-однодневки в экономике, но это мое субъективное впечатление.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3