Разработчик показал, как запустить браузер в изолированном LXC-контейнере, чтобы уязвимость в Electron-приложении не положила всю домашнюю директорию. Система — Arch Linux, но инструкция легко переносится на другие дистрибутивы.
Сначала ставим пакеты lxc и lxcfs. Включаем сетевой мост lxcbr0 через сервис lxc-net.service. Контейнер будет непривилегированным: для этого в /etc/lxc/www.conf прописываются lxc.idmap — UID и GID внутри контейнера (начиная с 0) маппятся на диапазон 100000–165535 на хосте. Если процесс сбежит из контейнера, у него не будет прав за пределами этого диапазона. В /etc/subuid и /etc/subgid добавляем строку root:100000:65536.
Сам контейнер создаётся из образа debian:trixie, в него ставится firefox-esr и заводится пользователь www.
Дальше — проброс X11. На хосте есть сокет /tmp/.X11-unix. Но просто смонтировать его недостаточно: файл .Xauthority привязан к hostname, который внутри контейнера другой. Решение — сгенерировать новый cookie с полем FamilyWild (код ffff), он подходит для любого хоста. Создаём /tmp/lxc.Xauthority командой с xauth nlist и sed. В конфиг контейнера добавляем переменные XAUTHORITY и DISPLAY, а также bind-mount для сокета и cookie-файла.
Нюанс: поскольку контейнер непривилегированный, файл .Xauthority на хосте принадлежит вашему пользователю, а внутри контейнера его UID не совпадает с маппингом — файл видится как nobody. Простейший выход — chmod 644 /tmp/lxc.Xauthority, чтобы любой мог его читать. Либо меняем владельца на UID 101000 (соответствует пользователю www внутри контейнера).
Звук настраивается по той же схеме, но через PipeWire. Хост создаёт отдельный PulseAudio-сокет (/tmp/pulse-socket-0), он монтируется в контейнер, а переменная PULSE_SERVER указывает на него. Внутри контейнера ставим pulseaudio и pipewire-pulse. Проблем с правами нет — сокет и так доступен всем.
После запуска браузер работает как обычно: окно появляется на хосте, звук идёт через твой динамик. Если его взломают, злоумышленник окажется внутри контейнера с фейковыми UID — до домашней папки и остальной системы он не доберётся. Каждый проброшенный ресурс (X11, звук, GPU через /dev/dri) расширяет возможный урон, поэтому подключать стоит только то, что реально нужно приложению.