Система ограничений

Под перечисленные требования подпадает любая система мандатного доступа, в т.ч. AppArmor и SELinux.

как организовать такую систему безопасности

Открыть доку и организовать. Обычно организация состоит из двух этапов: обучения и последующего enforcing, когда накопленная и допиленная политика безопасности используется по прямому назначению.

А AppArmor попадает под: «Запрещено все, что не разрешено» и «доступ к сети». То есть с AppArmor возможно по-умолчанию для всех исполняемых файлов поставить запрет(а не по отдельному правилу для каждого) и так же контроль за сетевыми подключениями?

То есть с AppArmor возможно по-умолчанию для всех исполняемых файлов поставить запрет(а не по отдельному правилу для каждого) и так же контроль за сетевыми подключениями?

Зачем тебе ограничивать все приложения в системе?
Ограничивать надо те, которые могут быть уязвимы.

Ограничивать надо те, которые могут быть уязвимы.

+1024

Ограничить [почти] всё можно на каком-нибудь серваке, который работает годами без каких-либо серьезных изменений. И для этого SELinux очень хорош.

На локалхосте имеет смысл ограничивать браузеры, флеши, скайпы, джабберы, торренты, dc-клиенты, биткоины и прочее решето.

А AppArmor попадает под: «Запрещено все, что не разрешено» и «доступ к сети»

Если стоит задача «огородить всё от всего», то AppArmor тут не товарищ. Во-первых, см. соседний тред, во-вторых AppArmor вроде до сих пор не умеет «историю запуска процесса» (иерархические политики). Т.е. если одну и ту же утилиту (например /bin/bash) дергает и xfce-terminal, и skype, то AppArmor это не различает, т.е. ты не можешь нормально настроить правила для /bin/bash. Выводы.

То есть с AppArmor возможно по-умолчанию для всех исполняемых файлов поставить запрет

Хз, я с AppArmor знакомился ровно две с половиной минуты, потом сразу снёс и поставил tomoyo на всех локалхостах. Как быстро настроить tomoyo я уже писал в соседнем треде по вышеупомянутой ссылке.

И да, в нём можно «по-умолчанию для всех исполняемых файлов поставить запрет». Конечно так никто не делает, но для этого достаточно обнулить всю политику и для namespace <kernel> выставить профиль enforcing. И вся система сразу упадёт)

По мне абсурд, что каждое приложение имеет полный доступ к home директории пользователя

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

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

Как мне кажется, это должно быть заботой системы

Хз, я с AppArmor знакомился ровно две с половиной минуты, потом сразу снёс и поставил tomoyo на всех локалхостах. Как быстро настроить tomoyo я уже писал в соседнем треде по вышеупомянутой ссылке.

А вы какую ветку ставили? на сколько я понял там их две

Зачем тебе ограничивать все приложения в системе?
Ограничивать надо те, которые могут быть уязвимы.

Мне интересна сама концепция построения такой системы, поэтому и ищу возможности ее реализации. Пока не на свою машину, а в виртуалке.

А вы какую ветку ставили?

Ту, которая удовлетворяла этому описанию. Да и было не вчера, а намного раньше.

Ту, которая удовлетворяла этому описанию. Да и было не вчера, а намного раньше.

Значит скорее всего первую.. во второй как я понял уже нету поддержки работы с сетью

во второй как я понял уже нету поддержки работы с сетью

А в tomoyo 2.5.x есть! Но для полного огораживания обычно используется SELinux, ибо он для этого разработан.

А в tomoyo 2.5.x есть! Но для полного огораживания обычно используется SELinux, ибо он для этого разработан.

Значит читал устаревшую информацию, ну что же попробую :)

Мне интересна сама концепция построения такой системы, поэтому и ищу возможности ее реализации.

Тогда тебе надо смотреть в сторону любой виртуализации.
Т.к пока ты даешь десктопной ОС прямой доступ к железу она будет оставаться решетом, хоть ты обвешайся правилами для песочниц.
В десктопном линуксе слишком много вещей прикручены «сбоку на скотче».

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

Если вопрос только в том, чтобы данные не были повреждены (но разглашение возможно), то используй бекапы. В случае, если и конфиденциальность важна, то запускай под другим юзером через sux, не забывай про то, что прав **7 не должно быть для большинства файлов. iptables умеет заворачивать куда хочешь все пакеты от определенного пользователя, поэтому можешь решить и вопрос с сетью. Или можно использовать контейнеры (или chroot?).

Если на мой ответ про бекапы ты подумал, что «денег нет», то «давай досвидания». Или определись, какие данные реально важны. Если ты не увлекаешься фотографией в RAW или съемкой, то объём твоей критичной информации должен измеряться в гигабайтах или мегабайтах, на флешку можешь и у мамы спросить.

Можно также посмотреть с сторону полной виртуализации, если ты не про десктоп-приложения.

Если ты не понимаешь ничего в apparmor и selinux, то я не рекомендую к ним лезть, используй более простые инструменты. Особенно это касается SELinux, у которого весьма сложная логика, а решение задачи тут явно выходит за рамки референсной политики, которая запускает все десктоп-приложения от одного selinux-пользователя с весьма большими правами.

Тогда тебе надо смотреть в сторону любой виртуализации.

Он нормально даже не может сказать, от чего именно он хочет обезопасить систему, ему явно ещё теории даже не хватает, а он уже к SELinux'y пытается лапы протянуть. Поэтому вопрос необходимости виртуализации тут может быть спорен из-за неясного ТЗ.

Т.к пока ты даешь десктопной ОС прямой доступ к железу она будет оставаться решетом, хоть ты обвешайся правилами для песочниц.

Опять же, всё зависит от сценария угрозы. Если угроза только в доступности данных, то нет. Опять же, виртуализация тоже не даёт 100% гарантии, что систему не взломают. Не однократно были взломы и openvz, и kvm, и xen, и vmware. Часть из них позволяют сразу исполнить код от гипервизора или ядра хоста.

В десктопном линуксе слишком много вещей прикручены «сбоку на скотче»

policykit или что? Его можно выпилить или поставить admin auth. Если про systemd+dbus и другие dbus сервисы от рута, то от них тоже можно избавиться (а в генте можно даже и не заводить с самого начала). Или Вы про то, что десктопные приложения недостаточно изолированы друг от друга? Это вопрос нисколько не линукса, а безграмотности пользователей, которые не создают общественную потребность в безопасности; в других осях всё куда плачевнее с этим.

Мне интересна сама концепция построения такой системы, поэтому и ищу возможности ее реализации.

Идеальной системы, которую нельзя взломать с постоянной доступностью данных?
Тогда лучше всего будет модель «один сервер (аппаратный) - одно приложение», по сети их изолировать, проводить аудит. Для доступности данных использовать аппаратное хранилище FC с выгрузкой снапшотов на касеты.

Опять же, виртуализация тоже не даёт 100% гарантии, что систему не взломают. Не однократно были взломы и openvz, и kvm, и xen, и vmware. Часть из них позволяют сразу исполнить код от гипервизора или ядра хоста.

Виртуализация позволяет сильно урезать саму возможность заливки вредоносного кода.
Т.е можно без труда собрать окружение где кроме веб сервера и интерпритатора языка вообще нет ничего, и нет прав на запись никуда где можно запустить сплоент.

policykit или что?

Ну это не тебе адресовано, не пользователю самосборной генты :)

На тех дистрибутивах которые считаются десктопных линуксом есть: иксы с тоннами подсистем, проприетарные драйвера для кучи девайсов, работающая от юзера пульса, работающий от рута bluetoothd, куча софта (типа cups) который слушает на localhost и который никак не защищен от локальных воздействий...

Или Вы про то, что десктопные приложения недостаточно изолированы друг от друга? Это вопрос нисколько не линукса, а безграмотности пользователей, которые не создают общественную потребность в безопасности;

Естественно это не вина линукса самого по себе.
Но то что текущие десктопные дистрибутивы потенциальное решето - факт.

в других осях всё куда плачевнее с этим.

Но тем не менее в «другой оси» нельзя просто так обойти UAC если он включен, и скорее всего почти невозможно обойти вайтлисты софта.
А на линуксе сделать вайтлист софта будет очень и очень сложно без адовых манипуляций.
Реально готовых и рабочих профайлов для свежего софта нету, поэтому ты либо настраиваешь SELinux/AppArmor руками, либо наслаждаешься решетом.

1. Вы, почему то, везде видите только уязвимости интерпретаторов и ошибки логики приложений, хотя в реальности основной проблемой являются ошибки работы с памятью (проблема безопасности которых полностью решена в hardened gentoo). Что касается интерпретаторов, типа пхп, то там можно вообще запретить exec в самом интерпретаторе, а от инъекций интерпретируемого кода без exec поможет mod_security + greensql proxy (и другие подобные IPS есть). Ко всему прочему многие сервисы сейчас вообще популярно форкать сразу в chroot.
Мало того можно использовать mount --bind для монтирования директории саму в себя с noexec, можно и всю партицию монтировать.

Вы не хотите понять, что виртуализация позволит лишь изолировать другие сервисы от взлома после взлома определенного сервиса, но не предотвратить взлом этого сервиса. Ваши домыслы об многоходовых атаках через разные сервисы тоже не верны (и payload, обычно, идет сразу в инъекции и не требует заливки никаких файлов), либо админ - идиот (например, он дает заливать через анонимный ftp-аккаунт в /var/www/site.com/upload, при этом не блоча пхп или цги в этой директории. Но он может дать возможность заливки (а так часто у быдлокодеров и бывает) заливку через http, что будет внутри неделимого сервиса. Поэтому тут виртуализация не поможет. Тут нужно мозг покупать админу).

Виртуализация только снижает последствия взлома, но если данные внутри сервиса (или доступность сервиса) важны (контент, финансовая информация, покупки, voip), то тут вируализация не поможет вообще (когда сервис у нас один). Необходимо использовать IPS, IDS, бекапы, аудит и правильную архитектуру. Виртуализация это лишь один из методов изоляции, позволящий провести наилучшую изоляцию без отдельного железа.

SELinux, например, позволяет запретить приложению доступ к фс, сокетам, повышению прав, доп форку, форку тредов или exec и т.д., одновременно сообщая об инцеденте. mod_secure, greensql proxy и другие IPS позволяют фильтровать паттерны исполняемого кода или других выражений, чтобы они не были переданы интерпретатору, скрывают истинные версии и нутро ПО от сканеров. PaX и харденед гцц полностью избавляют нас (с точки зрения безопасности) от проблем с памятью. Пустой chroot, куда будет форканут процесс не позволит использовать даже стандартные приложения в /bin. И т.д.
Вот это реальная безопасность, а не изоляция взломанной машины от остальных.

2. Да, не спорю. Некоторые эти проблемы есть (но решаются, если нужно) и в генте, но в других дистрибутивах объемы всякого говна, висящего на dbus впечатляют. Однако, обычно, для их использования нужно уже иметь права данного юзера и его сессию. Сетевая изоляция может делаться через SELinux и iptables. Если же касаться не десктопного ПО, а сервисов (например, блютуса) не от этого юзера, то в SELinux у них у всех есть референсные политики (включая тот же блютус), и для них проблематичны (обычно) только ошибки (уязвимости) работы с памятью при сетевом доступе или доступе через устройства, что решено в hardened gentoo, уязвиомсти логики требуют доступа к шелу юзера, что на десктопе уже означает успешный взлом. А вот эти свистоперделки на сервере могут быть реальной дырой. Но можно просто через SElinux запретить доступ к системной dbus (для многих сервисов он и так запрещен).

3. Да, на десктопе лишь потенциальное решето. Реальное решето - это проблемы памяти.

4. Ой ли? Не про оффтоп Вы ли часом? Переключите политики полкита в аус админ и будет Вам UAC, только безопаснее. На винде из обычного юзера можно даже в корень диска писать, не говоря уже про внешние устройства. На винде UAC неоднократно уже обходился, не говоря уже о внедрении дров и буткитах. Списки доступа на винде используются крайне редко и Вас никто не мешает использовать полное запрещение исполнения всех файлов, короме перечисленных через selinux, apparmor. Плюс еще в линуксе есть (IMA уже интегрирована) три системы проверки хешей и цифровых подписей бинарников. Есть даже проверка обычных файлов (конфигов обычно) перед доступом. Так что не надо мне расказывать, что ведущий производитель душлаков и дыр от бубликов начал производить бронетранспортеры. Они, конечно, пытаются вводить технологии, которые ibm 10 лет назад разработала, но их транспортер состоит больше из дыр, а остальное - рыхлое тесто. То, что они в посленее время устраивает кучу проблем юзерам с драйверами и прочими вещами, связана с желанием драть бабки за подписи, сертификаты и ОЕМ, а также дать PR отделу то, что они будут называть «прогрессивной инновационной технологией, не имеющей аналогов в мире». Хотя их UAC - это ksudo, по сути, даже не polkit. Когда ksudo использовать стали, кстати? ;) В макоси есть подобие polkit, но оно сложно расширямо и используется только в настройках системы (большая часть приложений просто требуют прав рута и все).

Реально рабочие профайлы для десктопного GUI-ПО сделать крайне сложно, т.к. юзера от системы в SELinux можно и так легко изолировать, переместив его в xuser, а разграничение доступа внутри home - это делать сугубо личное, а
конфиги, обычно, не представляют ценности. Никто не мешает использовать sux для запуска отдельного приложения от другого юзера.

Так что почитайте теорию, особенно перед тем, как говорить, что винда в XXX лучше линукса.