SELinux, AppArmor и др. системы безопасности

По поводу SELinux, там есть медленные улучшения для рядового пользователя.

Набор стандартных модулей, согласованных с вашим дистрибутивом, отлично будет защищать сервисы, которые с ним же и поставляются (CUPS, VPN, ssh). Можно подправить правила и для системного Tor (но не TBB). Это то, как SELinux работал всегда, будучи ориентированным на серверы. Для десктопа есть немного готовых модулей для программ (gnupg, mplayer).

Чтобы не мучиться с составлением с нуля модуля для программ, можно отдельного анонимного пользователя дополнительно запускать с готовой SELinux ролью user_u, прописать, чтобы при логине эта роль автоматически накладывалась и назначались соотв. SELinux-права в хомдире. Пользователь с этой ролью может не бояться эксплойтов, которые повышают свои привилигии до рута (если не будет эксплойтов против самого SELinux или его конкретных настроек). Во-первых получить права рута сложнее: чтение и работа с некоторыми системными файлами для пользователя с такой ролью ограничены, нет возможности запускать суидные файлы, пользоваться пингом, su, sg, sudo и любой программой, меняющей UID/GID. Во-вторых, если рут даже получен, то он выглядит очень забавно (как не рут) — он практически ничего не может, т.к. находится в том же пользовательском SELinux-контексте.

В новых версиях SELinux ещё больше интересных возможностей и утилит (в плане взаимодействия с сетевыми возможностями как напрямую так и посредством iptables, совместное использование с виртуалками и "квазивиртуалками" – LXC), но вся разработка ведётся на Fedora Linux, а в другие дистрибутивы всё переходит очень медленно.

Кстати, в одной из рассылок натыкался на давний вопрос, "почему нет файрволла, работающего на уровне приложений?". Ответ от разработчиков примерно в таком же духе, что "без соответствующего контекста безопасности, накладываемого на приложение, любой локальный файрволл будет бесполезен".

Конечно, как и в курсе того, что при этом было много ругани на тему «SeLinux работает только в дефолтной поставке, а при малейшем изменении настроек под себя (ну среднестатистическому пользователю федоры зачем анонимность? А вам она может понадобиться) получается что-то такое». В итоге SeLinux превратился в средство «работает, если ничего не трогать и не менять» (по словам пользователей той же федоры — за что купил, за то и продаю).


В нативной системе защиты вектор угроз, как правило, настолько отличается от ваших, что сам вопрос доверия теряет смысл: они строят защиту от одного, а вам нужна защита от другого. Кого будет волновать утечка серийников железа, MAC-адресов сетевых? Даже разработчики целевых решений для анонимности порой прокалываются так, что должно быть совсем стыдно. Я считаю, что если вы понимаете что и как работает (а это не так сложно, как кажется) в плане анонимности, вы сделаете свою систему более безопасной, чем искаробочное решение. К тому же про правила SeLinux, защищающие от утечек информации о железе и самой ОС, на которой целевой софт работает, я не слышал. Когда будет стандартизированное решение (пока Qubes самое близкое к тому), тогда можно будет говорить о его выборе.

Ну как же, remote считают (причём даже их — только в умолчальной установке ОС), а local — нет. Уже это — прозрачный намёк. Скорее, отношение к local root у всех такое, не только у OpenBSD'шников: считается, что

1. Безопасность критична только на серверах (десктопы пока не ломают, т.к. нет чёрного рынка малваре под Linux-десктопы в силу его малой распространённости — экономически невыгодно разрабатывать зловреды).
2. Доступ к шеллу имеют только доверенные лица, потому ломать они ничего не будут (на хостингах доступ либо в виртуалку, либо на dedicated server — ни то, ни другое не является ОС'ью, из которой ведётся админское управление всем хостингом). И даже если они захотят что-то ломать, они вряд ли надёжно сотрут логи, к тому же они обычно неанонимны. А раз так, опасность получить по шапке их должна остановить.
3. Зловредная прикладная программа, эксплуатирующая дыру вида local root — фантастика (с чем трудно не согласиться), и, опять же, считается, что такая программа имеет куда больший риск появиться на десктопе, чем не на сервере (далее см. пункт 1).
4. К времени на закрытие local root дыры относятся намного более спокойно, чем к закрытию remote-дыры. Боюсь наврать, но, кажется, могли исправлять несколько дней в некоторых open source ОС.

Наверное, можно найти и конкретные цитаты, но сходу не вспоминается ничего такого.

И как у него насчёт прав к просмотру конфигурации системы и типа железа, настроек сети? Если есть два разных юзера (например, один анонимный, а другой нет), оба с правами user_u, могут ли они потенциально определить (не ограничиваем их в средствах), что запущены физически на одной и той же ОС/железе?

spinore, заканчивайте троллить и приводить цитаты из темы Юмор. Я прекрасно понимаю смысл анонимных постов, я конкретно отвечал вам на

теперь вы ссылаетесь в споре со мной на мой же пост, lol

Кого будет волновать утечка серийников железа, MAC-адресов сетевых?

Мы же начали вроде с того, что приложение запускается из-под отдельного пользователя, которому запрещён доступ в сеть? И тем более каких-то условий анонимности заявлено не было. Это вы уже о чём-то о своём, батенька, пошли.
Про утечки SELinux vs виртуалка согласен. Но виртуалки помимо спорной защищённости приносят и другие неудобства: дополнительные затраты ресурсов, оверхэд, время на разворачивание.

remote-дырки считают, потому что они наиболее опасны.

К времени на закрытие local root дыры относятся намного более спокойно, чем к закрытию remote-дыры

Спасибо, Капитан Очевидность! Но не забивают же? Серьёзная уязвимость, фиксят быстро, чего вам не хватает?

Домысливая за разработчиков в духе spinore можно в итоге придти к:

1. десктопы не популярны, не приносят дохода, да и *nix это серверная ОС вообще
2. исходя из п.1 разработчики смотрят сквозь пальцы (sic!) на все десктоп-ориентированные дыры
3. исходя из п.1 и п.2 *nix нисколько не претендуют в качестве безопасной ОС

Подытоживая всё вышесказонное: Linux и BSD на десктопе не нужны. Windows лучшая ОС, т.к. она делается для десктопов.

Да, нить разговора и контекст потерялся. С другой стороны, если не беспокоиться об анонимности, то непонятно откуда взялось требование про «запрещён доступ в сеть» (выдумать такие условия можно, но да ладно).


Если речь идёт про настоящую паравиртуализацию (Xen), то основные затраты — время на разворачивание. Оверхед, пишут, действительно есть, но он отрицательный:

With NetBSD 5, which greatly improves disk I/O and network I/O performance over NetBSD 4, some guest Operating Systems running under Xen are known to operate faster than when installed natively on the same hardware without NetBSD and Xen behind the scenes. ☭

жесткая полемика с кучей цитат.. страшно становится.
а если я задам вопрос о проекте JanusVM здесь, это будет по теме?

Не будет. Почему не задать его непосредственно в теме по JanusVM?

спасибо. там тема мертвая и видимо никому не интересная, т.к. кто специалист в Unix, тот сам себе такое сделает. а у простых пользователей стало быть не популярен.

в SE вынесена часть логики в конфигурацию. Это тоже не очень хорошо, так как в итоге всё зависит от качества конфигов каждой софтины, но гораздо лучше чем вообще ничего. Apparmor кроме этой же проблемы имеет меньшую изоляцию. Также на практике забывают маленький нюанс. Атака на сервер может быть произведена в виде перегрузки системных ресурсов(для этого хватит минимума прав), что вызовет увеличение числа ошибок работы с устройствами, что в свою очередь не сказывается на безопасности положительным образом или просто вызовет останов части или всех сервисов этого сервера, что в реальном мире вызывает не только остановку сервера, но и может опять же негативно сказаться на его безопасности из-за человеческого фактора во время попыток системных администраторов, находящихся под сильным давлением менеджеров, восстановить работоспособность системы в кратчайшие сроки. На практике атаки на отказ в обслуживании отнюдь не редкость и SE никак не решает проблему с защитой от таких атак.

Полное отделение операционной системы от реального железа – вот логичный путь дальнейшего развития изоляции. По сути опять получается инкарнация старого спора микроядерная архитектура vs монолитное ядро, только теперь каждая программа(в общем смысле слова, файрволл, firefox итд, в зависимости от задач), которой желательна полная изоляция от железа работает на собственной ОС и фактически уже не способна видеть другие изолированные программы и влиять на них через реальное железо. Раньше просто не было ресурсов для таких мероприятий. При этом идею SE отвергать не нужно ибо оно работает на ring0, а гипервизор работает на ring-1 и ничем не мешает работе SE или AppArmor

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


Это какой-то дешёвый гипервизор, раз он в ring 1:

Under Hyper-V hypervisor virtualization a program known as a hypervisor runs directly on the hardware of the host system in ring 0. The task of this hypervisor is to handle tasks such CPU and memory resource allocation for the virtual machines in addition to providing interfaces for higher level administration and monitoring tools.

Clearly, if the hypervisor is going to occupy ring 0 of the CPU, the kernels for any guest operating systems running on the system must run in less privileged CPU rings. Unfortunately, most operating system kernels are written explicitly to run in ring 0 for the simple reason that they need to perform tasks that are only available in that ring, such as the ability to execute privileged CPU instructions and directly manipulate memory. One solution to this problem is to modify the guest operating systems, replacing any privileged operations that will only run in ring 0 of the CPU with calls to the hypervisor (known as hypercalls). The hypervisor in turn performs the task on behalf of the guest system.

Опять Linux со своим kvm портит понимание пользователям, что такое настоящий (Type 1) гипервизор с паравиртуализацией?