containers/bubblewrapНизкоуровневый непривилегированный инструмент для песочницы, используемый Flatpak и аналогичными проектами.
Многие инструменты для работы с контейнерами, такие как systemd-nspawn, docker и т. д., ориентированы на предоставление инфраструктуры для системных администраторов и инструментов оркестрации (например, Kubernetes) для запуска контейнеров.
Эти инструменты не подходят для предоставления непривилегированным пользователям, поскольку превратить такой доступ в полностью привилегированную root-оболочку на хосте тривиально.
В ядре Linux есть функция под названием пользовательские пространства имён, которая позволяет непривилегированным пользователям использовать возможности контейнеров. Bubblewrap использует их для построения песочницы, позволяя любому пользователю использовать этот инструмент.
Исторически bubblewrap также поддерживал setuid-режим для систем, в которых не поддерживались непривилегированные пользовательские пространства имён. Однако эта возможность была удалена.
Изначальный код bubblewrap появился ещё до пользовательских пространств имён — он наследует код от xdg-app helper, который, в свою очередь, отдалённо происходит от linux-user-chroot.
Сопровождающие этого инструмента считают, что он, даже при использовании в сочетании с типовым программным обеспечением, установленным в этом дистрибутиве, не позволяет повышать привилегии. Однако он может повысить способность вошедшего в систему пользователя совершать атаки типа «отказ в обслуживании».
В частности, bubblewrap использует PR_SET_NO_NEW_PRIVS для отключения setuid-бинарных файлов, что является традиционным способом выбраться из таких ограничений, как chroot.
bubblewrap — это инструмент для создания сред песочницы. bubblewrap не является полной, готовой песочницей с определённой политикой безопасности.
Некоторые сценарии использования bubblewrap требуют наличия границы безопасности между песочницей и реальной системой; другие сценарии использования хотят иметь возможность изменять структуру файловой системы для процессов внутри песочницы, но не претендуют на роль границы безопасности. В результате уровень защиты между процессами в песочнице и хост-системой полностью определяется аргументами, переданными bubblewrap.
Какая бы программа ни формировала аргументы командной строки для bubblewrap (часто это более крупный фреймворк, такой как Flatpak, libgnome-desktop, sandwine или специальный скрипт), именно она отвечает за определение собственной модели безопасности и выбор подходящих аргументов командной строки bubblewrap для реализации этой модели безопасности.
Некоторые аспекты безопасности песочницы, требующие особого внимания, описаны в разделе Ограничения ниже.
Эта программа может использоваться совместно всеми инструментами для контейнеров, которые работают без прав root, например:
Мы также хотели бы, чтобы эта возможность была доступна в кластерах Kubernetes/OpenShift. Наличие возможности использовать функции контейнеров непривилегированным пользователям значительно упростило бы интерактивную отладку и подобные сценарии.
bubblewrap доступен в репозиториях пакетов большинства дистрибутивов Linux и может быть установлен оттуда.
Если вам нужно собрать bubblewrap из исходного кода, вы можете сделать это с помощью meson:
meson _builddir
meson compile -C _builddir
meson test -C _builddir
meson install -C _builddir
bubblewrap работает следующим образом: он создаёт новое, полностью пустое пространство имён монтирования, в котором корень находится на tmpfs, невидимой для хоста и автоматически очищаемой после завершения последнего процесса. Затем вы можете использовать параметры командной строки, чтобы сконструировать корневую файловую систему, окружение процесса и команду для запуска в этом пространстве имён.
В исходном коде есть более крупный демонстрационный скрипт, но здесь приведена урезанная версия, которая запускает новую оболочку, используя /usr хоста.
bwrap \
--ro-bind /usr /usr \
--symlink usr/lib64 /lib64 \
--proc /proc \
--dev /dev \
--unshare-pid \
--new-session \
bash
Это неполный пример, но он полезен для иллюстрации. Чаще, чем создавать контейнер с использованием дерева файловой системы хоста, вы хотите использовать chroot. В этом случае, вместо создания символической ссылки lib64 -> usr/lib64 в tmpfs, вы, возможно, уже создали её в целевой корневой файловой системе.
Цель bubblewrap — запускать приложение в песочнице, где оно имеет ограниченный доступ к частям операционной системы или пользовательским данным, таким как домашний каталог.
bubblewrap всегда создаёт новое пространство имён монтирования, и пользователь может точно указать, какие части файловой системы должны быть видны в песочнице. Любые такие каталоги, которые вы указываете, по умолчанию монтируются с опцией nodev и могут быть сделаны доступными только для чтения.
Кроме того, вы можете использовать следующие возможности ядра:
Пользовательские пространства имён (CLONE_NEWUSER): Это скрывает от песочницы всё, кроме текущих uid и gid. Вы также можете изменить значение uid/gid в песочнице.
Пространства имён IPC (CLONE_NEWIPC): Песочница получит собственную копию всех различных форм IPC, таких как разделяемая память SysV и семафоры.
Пространства имён PID (CLONE_NEWPID): Песочница не увидит никаких процессов вне песочницы. Кроме того, bubblewrap запустит тривиальный pid1 внутри вашего контейнера для обработки требований по сбору зомби-процессов в песочнице. Это позволяет избежать того, что сейчас известно как проблема Docker pid 1.
Сетевые пространства имён (CLONE_NEWNET): Песочница не увидит сеть. Вместо этого у неё будет собственное сетевое пространство имён только с loopback-устройством.
Пространство имён UTS (CLONE_NEWUTS): Песочница будет иметь собственное имя хоста.
Фильтры seccomp: Вы можете передавать фильтры seccomp, которые ограничивают, какие системные вызовы можно выполнять в песочнице. Для получения дополнительной информации см. Seccomp.
Как отмечалось в разделе Безопасность песочницы выше, уровень защиты между процессами в песочнице и хост-системой полностью определяется аргументами, переданными bubblewrap. Некоторые аспекты, требующие особого внимания, отмечены здесь.
Если вы не отфильтровываете команды TIOCSTI с помощью фильтров seccomp, аргумент --new-session необходим для защиты от выполнения команд за пределами песочницы (см. CVE-2017-5226).
Всё, что смонтировано в песочницу, потенциально может быть использовано для повышения привилегий. Например, если вы привяжете сокет D-Bus в песочницу, его можно будет использовать для выполнения команд через systemd. Вы можете использовать xdg-dbus-proxy для фильтрации обмена данными D-Bus.