Добре поповнення колекції.
Новинам треба дати настоятися, після чого смакувати деталі.

• Red Hat, RED HAT, КАРЛ!
• GitHub Actions, як завжди.
• NPM, до цього вже звикли.
• Arch User Repository, вже цікавіше.

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

Стандартна ситуація, у вас є основний робочий комп’ютер, на якому у вас є три різних проекта.
Один проект на 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/*

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

Не вдаючись до подробиць, як саме і чому все організовано, доступ здійснюється по наступному ланцюжку:

1

Nginx stream ingress <> Main Nginx Frontend <> Nginx Backend inside GitLab instance.

Основний фронтенд управляє піддоменом gitlab, який закритий для зовнішнього доступу за допомогою авторизації auth_basic.