Перезберемо Nginx з патчем CVE-2026-9256 відповідно до Debian-way.

Debian Nginx CVE-2026-9256 1600x900 CVE-2026-9256.png

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

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

nano /etc/apt/sources.list

# 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

Критична вразливість у...

Якщо розробник, обираючи між зручністю та безпекою, вибирає зручність, він не отримає ані зручності, ані безпеки

Інженер з безпеки завантажив шкідливий скрипт у свій адмін-аккаунт 1280x1080 nice-security-engineering_exw.png

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

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

Мені набагато цікавіше стежити за поширеннями шкідливого коду в системах розповсюдження пакетів, бібліотеках та інших репозиторіях.

Тому що це стосується “активних” і безпосередніх атак, їм майже не потрібно поєднання певних факторів, після завантаження вони відразу ж вразять репозиторій розробника, далі зберуть його персональну / фінансову / авторизаційну інформацію, а після цього продовжать діяти по ланцюжку на всіх серверах, до яких у нього був доступ.

Якщо розробник, обираючи...

Підключення до ізольованих системних середовищ із використанням Waypipe

Коректний настрій 1200x1000
aluminium-tin-foil-hat_exw.jpg

Продовжуючи попередні нудні опуси на тему ізоляції оточень, саме час пригадати про 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.

Підключення до ізольованих...

Встановлення Debian на raid-масив із LUKS шифруванням, кореневою файловою системою ZFS та завантаженням з UBS із detached header

LUKS шифрование с отдельным header-файлом на USB 5504x3096 luks-encrypted-brick.jpg

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

Нещодавно знову ностальгував у FreeBSD, все чудово, все звично, все зручно.
Лише один момент повністю виключає її з використання, принаймні в мене.
Майже на всіх моїх ноутбуках FreeBSD не підтримує ні режим сну, ні режим очікування (s2ram/s2disk).
І зробити я з цим нічого не зміг, а перепробував багато чого.

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

З багатьох приємних дрібниць, які є у Фряхі, і які відсутні в Debian це ZFS Boot Environments, що зручніше, ніж, скажімо, снапшоти LVM.
А друге це GEOM_ELI, який підтримує не лише, як LUKS, режим АБО пароль, АБО ключ, але також підтримує режим І пароль, І ключ.

Подумав, подумав, та й вирішив розгорнути Debian з нуля з урахуванням усіх інструментів, які використовую, досвіду, і, що важливо, звичок.

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

Встановлення Debian на...