Пересоберём 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.

Вступление издалека

Не так давно опять настальгировал во FreeBSD, всё прекрасно, всё привычно, всё удобно.
Один только момент полностью исключает её из использования на десктопе, по крайней мере у меня.
Почти на всех моих ноутбуках FreeBSD не поддерживает ни спящий, ни ждущий режимы (s2disk/s2ram).
И сделать я с этим ничего не смог, а уж перепробовал многое.

Без ждущего режима совершенно невозможно пользоваться ноутбуком, так как после транспортировки необходимо по новой всё загружать, включать, открывать.
Да и перезагружаю рабочие станции только после обновлений, этого требующих.

Из многих приятных мелочей, которые есть во Фряхе, и которые отсутствуют в Debian это ZFS Boot Environments, это несколько удобней чем, скажем, снапшоты LVM.
А второе это GEOM_ELI, который поддерживает не только, как LUKS, режим ИЛИ пароль, ИЛИ ключ, но так же поддерживает режим И пароль, И ключ.

Подумал, подумал, да и решил развернуть Debian с нуля с учётом всех инструментов, которые использую, опыта, и, что немаловажно, привычек.

Debian пока что остаётся основной моей системой, следовательно единственный способ получения хардварного (физического) ключа шифрования в дополнение к паролю - это сделать его из хедера и разместить на загрузочной USB-флешке.

Стандартная ситуация, у вас есть основной рабочий компьютер, на котором у вас три разных проекта.
Один проект на nodejs, второй продакшн на python, а третий ваш личный “pet project”, тоже на python.
А ещё у вас в этой же системе личная+рабочая почта, ну и, скажем, браузер и клиент-банк.
И это всё под вашим пользователем.
Ну не под рутом же! ¯\_(ツ)_/¯
Всё вполне обычно. У многих вполне технически грамотных разработчиков таких проектов могут быть десятки и десятки ключей для ssh или git серверов.

Пример с популярным фреймворком PyTorch

Вполне обыденно Вы пишете свой код, время от времени коммитите, и тут в ваш уютный pet-project с AI прилетает обновление torchtriton.
А после этого из вашей системы улетают следующие наборы данных, в соответствии с основной функцией бинарника, которая делает следующее:

• Сбор системной информации:
  • nameservers из /etc/resolv.conf
  • hostname из gethostname()
  • текущий логин из getlogin()
  • текущая рабочая директория из getcwd()
  • переменные окружения
• Чтение следующих файлов:
  • /etc/hosts
  • /etc/passwd
  • Первые 1,000 файлов из $HOME/*
  • $HOME/.gitconfig
  • $HOME/.ssh/*

Обновление прилетело, конфедициальные данные - улетели.
Скомпрометировано не только всё под вашей учётной записью (и, возможно, системой), но и по цепочке всё, чем вы управляли, куда коммитили, куда подключались.