Когда говорят про sandbox в Linux, обычно вспоминают gVisor, Kata Containers или seccomp-профили. А есть куда более скромный инструмент, который при этом крутится на миллионах десктопов, — bubblewrap. Это тот самый движок песочницы, на котором работает Flatpak, и живёт он в организации containers рядом с Podman и Buildah.
Ключевая идея: это container tool для непривилегированного пользователя — никакого демона и root, всё на unprivileged user namespaces. Что даёт:
- mount namespace с пустым tmpfs в качестве /, куда руками пробрасываются только нужные куски ФС
- user/IPC/PID/network/UTS namespaces
- seccomp-фильтры
- монтирование ro и nodev по умолчанию
- PR_SET_NO_NEW_PRIVS, отрубающий эскалацию через setuid-бинари
Но самое интересное — то, что честно написано в README: сам по себе bubblewrap не даёт ничего, уровень защиты полностью определяется аргументами, которые ему передал вызывающий. Пробросили внутрь сокет D-Bus — и песочницы фактически нет. Ничего не напоминает? Ровно та же история, что и с SecurityContext в Kubernetes: примитивы ядра у всех одни и те же, а итоговая защищённость зависит от того, кто и как их сконфигурировал.
И показательный момент напоследок: оба CVE за всю историю проекта — и CVE-2020-5291, и свежий CVE-2026-41163 — про один и тот же setuid-режим, который нужен ровно там, где unprivileged user namespaces в ядре запрещены. В версии 0.11.2 завезли опцию сборки вообще без setuid и объявили, что дальше поддержку уберут совсем. Тренд читается однозначно: ставка делается на unprivileged user namespaces как на базовый примитив изоляции.
Ключевая идея: это container tool для непривилегированного пользователя — никакого демона и root, всё на unprivileged user namespaces. Что даёт:
- mount namespace с пустым tmpfs в качестве /, куда руками пробрасываются только нужные куски ФС
- user/IPC/PID/network/UTS namespaces
- seccomp-фильтры
- монтирование ro и nodev по умолчанию
- PR_SET_NO_NEW_PRIVS, отрубающий эскалацию через setuid-бинари
Но самое интересное — то, что честно написано в README: сам по себе bubblewrap не даёт ничего, уровень защиты полностью определяется аргументами, которые ему передал вызывающий. Пробросили внутрь сокет D-Bus — и песочницы фактически нет. Ничего не напоминает? Ровно та же история, что и с SecurityContext в Kubernetes: примитивы ядра у всех одни и те же, а итоговая защищённость зависит от того, кто и как их сконфигурировал.
И показательный момент напоследок: оба CVE за всю историю проекта — и CVE-2020-5291, и свежий CVE-2026-41163 — про один и тот же setuid-режим, который нужен ровно там, где unprivileged user namespaces в ядре запрещены. В версии 0.11.2 завезли опцию сборки вообще без setuid и объявили, что дальше поддержку уберут совсем. Тренд читается однозначно: ставка делается на unprivileged user namespaces как на базовый примитив изоляции.