Перезберемо 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 не підтримує ні режим сну, ні режим очікування (s2ram/s2disk).
І зробити я з цим нічого не зміг, а перепробував багато чого.

Без режиму очікування абсолютно неможливо користуватися ноутбуком, так як після транспортування необхідно по новому все завантажувати, включати, відкривати.
Та й перезавантажую робочі станції лише після оновлень, які цього вимагають.

З багатьох приємних дрібниць, які є у Фряхі, і які відсутні в 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/*

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