Релиз системы изоляции приложений Firejail 0.9.78
Обновлённая версия Firejail 0.9.78 продолжает развивать одну из самых простых и при этом мощных систем изоляции приложений в Linux. Firejail позволяет запускать графические, консольные и серверные программы в отдельной "песочнице", резко снижая риск компрометации основной системы при работе с ненадёжным или уязвимым ПО.
Проект написан на C, распространяется под лицензией GPLv2 и работает практически в любом современном дистрибутиве Linux с ядром старше 3.0. Доступны готовые пакеты в форматах deb и rpm, поэтому Firejail легко установить как в Debian и Ubuntu, так и в Fedora, CentOS и других совместимых системах.
Как Firejail изолирует приложения
Основу работы Firejail составляют механизмы ядра Linux:
- пространства имён (namespaces),
- AppArmor (при наличии и включённости в дистрибутиве),
- фильтрация системных вызовов через seccomp-bpf.
После запуска приложения через Firejail сам процесс и все его дочерние процессы оказываются в изолированном окружении, получая собственное представление:
- сетевого стека,
- таблицы процессов,
- точек монтирования,
- других ресурсов ядра.
Несколько взаимосвязанных программ можно поместить в общий sandbox и заставить их взаимодействовать друг с другом, не “видя” остальную систему. Такой подход удобен, например, для изоляции браузера и связанных с ним вспомогательных компонентов или для целых серверных стеков.
Firejail также может использоваться как инструмент для запуска контейнеров Docker, LXC и OpenVZ в дополнительной “над-изоляции”, усиливая защиту уже существующих контейнерных окружений.
Отличия от классических контейнеров
В отличие от Docker, LXC и прочих контейнерных систем, Firejail не требует подготовки отдельного системного образа. Контейнер формируется "на лету" на основе текущей файловой системы и уничтожается после завершения работы приложения. Это делает Firejail особенно удобным для десктопного использования и для быстрой изоляции уже установленных программ без изменения существующей инфраструктуры.
Система предлагает гибкий механизм ограничения доступа к файловой системе:
- можно явно разрешать или запрещать доступ к конкретным файлам и каталогам;
- монтировать временные файловые системы (tmpfs) для хранения чувствительных данных;
- делать отдельные каталоги доступными только для чтения;
- объединять директории через bind-mount и overlayfs, создавая “слой поверх” основной системы.
Таким образом, пользователь может очень точно описать, к каким данным конкретному приложению можно прикасаться, а к каким — нет.
Готовые профили и запуск приложений
Для многих популярных программ — включая Firefox, Chromium, VLC, Transmission и другие — в Firejail заранее подготовлены профили изоляции. Они содержат наборы правил, описывающих:
- какие системные вызовы разрешены или запрещены,
- какой доступ к файловой системе допустим,
- какие сетевые и IPC-возможности нужно ограничить.
Чтобы иметь возможность настраивать sandbox, исполняемый файл firejail устанавливается с флагом SUID root. Привилегии суперпользователя используются только на этапе инициализации "песочницы", после чего Firejail намеренно сбрасывает права, уменьшая потенциальный ущерб в случае эксплуатации уязвимостей.
Запуск программы в изолированном режиме предельно прост — достаточно использовать firejail в качестве префикса команды:
- `firejail firefox` — запуск браузера в sandbox,
- `sudo firejail /etc/init.d/nginx start` — запуск сервера nginx в изоляции.
Что даёт новый релиз Firejail 0.9.78
Версия 0.9.78 — это эволюционное обновление, нацеленное в первую очередь на надёжность и актуальность:
- усилена защита за счёт уточнения и расширения существующих правил изоляции;
- улучшена совместимость с новыми версиями популярных приложений и библиотек;
- доработаны готовые профили, в том числе для широко используемых браузеров и медиаплееров;
- исправлены обнаруженные ошибки, влияющие на стабильность и безопасность.
Релиз сохраняет традиционный для Firejail баланс: с одной стороны, простота настройки и запуска, с другой — использование современных механизмов безопасности ядра Linux.
Почему Firejail и bubblewrap “плохо интегрированы” с десктопом
Один из частых упрёков в адрес Firejail и низкоуровневого инструмента bubblewrap (bwrap) — отсутствие "прозрачной" интеграции с окружением рабочего стола. Под интеграцией обычно понимают следующее:
- .desktop-файлы в системе должны изначально запускать не оригинальный бинарник приложения, а обёртку с изоляцией;
- пользователь, кликая по иконке в меню, всегда должен попадать в защищённый режим, а не случайно запускать незащищённую версию программы.
bubblewrap изначально задуман как низкоуровневая утилита, и логично, что он сам по себе не решает задачи управления .desktop-файлами и не вмешивается в инфраструктуру рабочего стола. Firejail стоит чуть выше по уровню, но и он предполагает, что администратор или пользователь самостоятельно подменит системный .desktop-файл либо создаст собственный, указывающий на `firejail `. Это даёт гибкость, но требует аккуратности и понимания, чтобы не запустить случайно “голое” приложение.
Подход Flatpak: “правильная” интеграция
Для сравнения, Flatpak предлагает более жёстко структурированный подход. Приложение изначально устанавливается как sandboxed-пакет, вместе с ним появляются:
- корректный .desktop-файл, который всегда запускает именно контейнеризованную версию;
- команда в `$PATH`, автоматически перенаправляющая запуск на Flatpak-окружение.
Ошибиться при запуске сложнее: пользователь из коробки работает с изолированным вариантом программы. За это приходится платить более плотной привязкой к собственной экосистеме Flatpak и используемым репозиториям.
Репозитории и доверие к сборкам: Firejail против Flatpak
Firejail не вмешивается в цепочку поставки приложений — он работает с тем, что уже установлено в системе обычными средствами дистрибутива. Это плюс для тех, кто полностью доверяет репозиторию своего дистра и не хочет добавлять внешние источники.
Flatpak, напротив, продвигает собственную экосистему репозиториев. Для многих пользователей это преимущество:
- версии приложений обычно новее, чем в стабильных репозиториях дистрибутива;
- особенно актуально для быстро обновляющегося и критичного с точки зрения безопасности ПО, вроде Chromium, где 0-day уязвимости появляются регулярно;
- часть пакетов собирается непосредственно апстрим-разработчиками, что повышает доверие.
Однако остаётся справедливый вопрос: кто и как собирает конкретный пакет, насколько хорошо он проверен и соответствует исходному коду. Firejail в этот процесс не вмешивается: он не отвечает за упаковку и обновление программ, обеспечивая только слой изоляции поверх уже установленного софта.
Почему DAC не решает все задачи безопасности
В обсуждениях безопасности Linux часто всплывает тезис: достаточно правильно настроенного DAC (discretionary access control, стандартные права владельца/группы/other), и никаких дополнительных sandbox-систем не нужно. На практике это не так.
DAC отвечает за доступ к файлам и каталогам, но:
- он не умеет гибко ограничивать доступ к D-Bus-сервисам: одно приложение при подключении к пользовательской d-bus-сессии часто получает доступ ко всем сервисам сразу;
- он не контролирует, какие системные вызовы может делать процесс;
- он не обеспечивает изоляцию на уровне сетевых и IPC-пространств имён;
- он слабо помогает в сценариях, где нужно отделить "множество приложений одного пользователя" друг от друга.
Например, если у вас есть пользователи `user` и `app1`, и `app1` подключается к d-bus-сессии `user`, стандартные UNIX-права не дадут гибко прописать: “этот процесс может только посылать уведомления, но не имеет доступа к другим сервисам”. Namespaces, seccomp, MAC-политики и инструменты вроде Firejail здесь намного эффективнее.
hidepid, systemd и реальная видимость процессов
Опция `hidepid=1/2` при монтировании `/proc` действительно позволяет скрыть процессы других пользователей, уменьшая риск утечки информации через просмотр дерева процессов. Но это лишь один из уровней защиты и не отменяет того факта, что существуют другие каналы получения информации о состоянии системы: через systemd, журналы, служебные утилиты администратора.
Firejail и подобные инструменты не подменяют собой ни DAC, ни настройки `/proc`, ни контроль через systemd, а добавляют ещё один слой защиты:
- ограничивают, какие процессы могут увидеть друг друга;
- задают, какие системные вызовы вообще доступны;
- изолируют сетевое окружение и точки монтирования независимо от стандартных прав доступа.
Где Firejail особенно полезен
Firejail удобен в сценариях, где требуется:
- быстро и точечно усилить безопасность конкретных приложений (браузер, почтовый клиент, мессенджер);
- запускать подозрительное ПО, скрипты или бинарники без полноценной виртуальной машины;
- дополнительно укрепить уже контейнеризованные сервисы;
- разделить доверенные и недоверенные части одного и того же пользовательского окружения.
За счёт лёгкости интеграции на уровне команды запуска и готовых профилей Firejail хорошо подходит и для продвинутых пользователей, и для администраторов, которым нужно быстро навести порядок в изоляции приложений без глубокого погружения в контейнерную инфраструктуру.
Итог
Firejail 0.9.78 укрепляет позицию проекта как лёгкой, но серьёзной по возможностям системы изоляции приложений в Linux. В отличие от "тяжёлых" контейнеров, Firejail не требует создания образов и сложной оркестрации, а в отличие от Flatpak — не навязывает собственную экосистему пакетов. Он работает поверх уже установленного ПО, добавляя современную песочницу на основе namespaces, seccomp и AppArmor.
Вопрос интеграции с .desktop-файлами и удобства по сравнению с Flatpak остаётся делом вкуса и приоритетов. Тем, кому важны прозрачность интеграции и единый репозиторий, комфортнее Flatpak. Тем, кто предпочитает гибкость, контроль и независимость от внешних экосистем, Firejail в актуальной версии 0.9.78 предлагает мощный и при этом относительно простой инструмент для реального повышения безопасности Linux-систем.
