Разумеется, дополнительное ПО может привнести дополнительные уязвимости. От этого полностью не уйти и это надо учитывать (сисадмину).На Owl, риск от таких уязвимостей снижается hardening'ом базовой системы. Например, для каждого пользователя создается отдельный $TMPDIR каталог (средствами pam_mktemp) и, если программа использует переменную $TMPDIR, то уязвимости, связанные с некорректной работой с временными файлами, оказываются нейтрализованы (такие программы и уязвимости нам встречались). Другой пример - glibc с нашими изменениями при запуске SUID/SGID программ сбрасывает ряд переменных окружения, которые были бы небезопасны для самого glibc при "повторном" запуске какой-либо программы из уже запущенной. Это может "спасти", например, от атак на sudo (принципиально не входящий в Owl) при некоторых опасных его настройках.
Что, пожалуй, более важно и более эффективно, базовая система Owl (здесь я говорю о нашем userland'е) в большей степени разграничивает Unix-пользователей (а также псевдо-пользователей) чем многие другие дистрибутивы. У нас меньше SUID/SGID программ (а каждая такая программа представляет риск "локальных" атак), они меньше объемом, мы были осторожны в их выборе, и мы подвергли их аудиту и правке (см. слайды презентации об Owl). В итоге, если дополнительные программы запускать только под отдельными пользователями (которым эти программы нужны) или псевдо-пользователями (для сервисов), то возможная "компрометация" будет ограничена этими пользователями (их уровнем доступа).
Разумеется, уязвимости, позволяющие все же получить доступ другого пользователя или root'а на Owl, все же наверняка существуют - в ядре. Оно монолитное и слишком большое и сложное, чтобы их там совсем не было, сколько ни исправляй. Но на Owl, в сравнении с другими дистрибутивами, гораздо лучше ситуация с подобными уязвимостями в userland (возможно, что их нет и вовсе, если говорить об "активных" атаках, при том что "за ядро" у меня уверенность, увы, противоположная), да и из тех, что наверняка есть в ядре, значительная доля (возможно, бОльшая часть) недоступны для атак с Owl userland (не такие "расслабленные" права на /dev/*, нет авто-загрузки модулей ядра и т.п.)
Кстати, общедоступная SUID программа в стандартной установке осталась только одна - это ping. Ведь это не вещь первой необходимости на большинстве серверов и контейнеров, правда? Так что ее можно ограничить, сказав "control ping restricted". После этого на ping станет mode 700 - доступ только root'у (и эта настройка, кстати, будет сохраняться при обновлениях системы). Другие программы, такие как passwd и crontab, используют SGID под выделенные им группы, и доступ этих групп, без какой-либо другой уязвимости, не расширяется до root-доступа, благодаря нашим правкам этих программ и библиотек. Полный отказ от SUID-программ нейтрализует некоторые классы потенциальных уязвимостей в ядре.
И, наконец, да - контейнеры. В какой мере и в каких случаях их использовать - выбор сисадмина. Конкретный пример "из жизни" - несколько экземпляров разных wiki (один и тот же набор доп. программ - Apache, PHP, DokuWiki) на разных доменах "идут" в один контейнер (т.к. все равно потенциальные уязвимости общие). В то время как другой веб-сайт, не требующий PHP, размещается на том же сервере в другом контейнере. Для почты может быть создан еще один контейнер без доп. программ (Postfix, popa3d, procmail, Mutt входят в базовую поставку Owl) или же с соответствующими этой задаче программами.
