Ежедневная рутина

Пересоберём Nginx с патчем CVE-2026-9256 согласно Debian-way.

Критическая уязвимость в nginx, позволяющая удалённо добиться выполнения кода с правами рабочего процесса nginx через отправку специально оформленного HTTP-запроса.
Но дело не в этом.
А дело в том, что мейнтейнеры Debian не торопятся выкатывать новый пакет с патчами.

• Security Bug Tracker CVE-2026-9256
• NGINX ngx_http_rewrite_module vulnerability CVE-2026-9256

1
2
3
4
5

apt --no-install-recommends \
    --no-install-suggests install \
    build-essential \
    fakeroot \
    devscripts

nano /etc/apt/sources.list

1
2
3
4

# trixie sources
deb-src https://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware
deb-src http://security.debian.org/debian-security/ trixie-security main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian/ trixie-updates main contrib non-free non-free-firmware

Прошло всего-навсего пол года, но новостная лента не переставала приносить новые забавные уязвимости.
Как обычно, я не акцентирую внимание на системных уязвимостях в snapd / Rust Coreutils / Flatpak, ядре (Copy Fail, Dirty Frag, Fragnesia, pidfd, PinTheft, GRO Frag) или AppArmor.

Какими бы опасными они не были - они “условно” пассивные, то есть при их наличии необходим ряд факторов и активных действий изнутри или извне для успешной эксплуатации.

Мне гораздо интереснее следить за внедрениями вредоносного кода в системы распространения пакетов, библиотеки и прочие репозитории.

Потому что это относится к “активным” и непосредственным атакам, им почти не надо сочетания определённых факторов, после загрузки они сразу же поразят репозиторий разработчика, далее соберут его персональную/финансовую/авторизационную информацию, а после этого продолжат действовать по цепочке на всех серверах, к которым у него был доступ.

Продолжая предыдущие скучные опусы на тему изоляции окружений, самое время вспомнить про wayland.
Конечно же, это не призыв к действию, а просто примеры и размышления.
Сам я придерживаюсь философии, где центр системы это пользователь, и он в праве настраивать всё так, как он считает нужным, а не так как это навязывается общими тенденциями, или как это реализовано в конкретном дистрибутиве, вместе с этим понимая и принимая все риски и последствия этих действий.
Как говорится, “If you know what you are doing”.

И прежде чем приступить, опять стоит написать, что:

• Да, я понимаю, что это всё очень поверхностно.
• Да, никакие подключения к локальной графической оболочке не допустимы для чего-то опасного, и надо использовать vnc или virt-viewer/spice.
• Непривилегированный LXC надо заменить на Xen / KVM
• И да, я знаю, что из KVM изоляции тоже можно выйти.
• И про Flatpak я тоже знаю.
• И, наконец, да, я знаю о Qubes OS и её архитектуре, можно сказать, с момента её появления, а это 2010 год.

И, несколько упрощая и адаптируя идеи QubesOS под свои повседневные задачи, я предпочитаю в основном использовать или других локальных пользователей, или достаточно легковесные окружения LXC.

И да, в них я запускаю не что-то потенциально опасное, а то, что многие из вас используют непосредственно под своим аккаунтом в системе, например:

• Firefox для повседневного использования и просмотра “чего попало”.
• Несколько проектов использующих пакеты из PyPI, RubyGems.
• Отдельно то, что я собираю из исходников с того же GitHub.
• Сторонние программы element-desktop, Telegram, Zoom.