Хорошее пополнение коллекции.
Новостям надо дать настояться, после чего смаковать детали.
- Red Hat, RED HAT, КАРЛ!
- GitHub Actions, как обычно.
- NPM, к этому уже привыкли.
- Arch User Repository, уже интересней.
Хорошее пополнение коллекции.
Новостям надо дать настояться, после чего смаковать детали.
Что-же тут может быть не так?
Критическая уязвимость в nginx, позволяющая удалённо добиться выполнения кода с правами рабочего процесса nginx через отправку специально оформленного HTTP-запроса.
Но дело не в этом.
А дело в том, что мейнтейнеры Debian не торопятся выкатывать новый пакет с патчами.
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”.
И прежде чем приступить, опять стоит написать, что:
И, несколько упрощая и адаптируя идеи QubesOS под свои повседневные задачи, я предпочитаю в основном использовать или других локальных пользователей, или достаточно легковесные окружения LXC.
И да, в них я запускаю не что-то потенциально опасное, а то, что многие из вас используют непосредственно под своим аккаунтом в системе, например:
Не так давно опять настальгировал во FreeBSD, всё прекрасно, всё привычно, всё удобно.
Один только момент полностью исключает её из использования на десктопе, по крайней мере у меня.
Почти на всех моих ноутбуках FreeBSD не поддерживает ни спящий, ни ждущий режимы (s2disk/s2ram).
И сделать я с этим ничего не смог, а уж перепробовал многое.
Без ждущего режима совершенно невозможно пользоваться ноутбуком, так как после транспортировки необходимо по новой всё загружать, включать, открывать.
Да и перезагружаю рабочие станции только после обновлений, этого требующих.
Из многих приятных мелочей, которые есть во Фряхе, и которые отсутствуют в Debian это ZFS Boot Environments, это несколько удобней чем, скажем, снапшоты LVM.
А второе это GEOM_ELI, который поддерживает не только, как LUKS, режим ИЛИ пароль, ИЛИ ключ, но так же поддерживает режим И пароль, И ключ.
Подумал, подумал, да и решил развернуть Debian с нуля с учётом всех инструментов, которые использую, опыта, и, что немаловажно, привычек.
Debian пока что остаётся основной моей системой, следовательно единственный способ получения хардварного (физического) ключа шифрования в дополнение к паролю - это сделать его из хедера и разместить на загрузочной USB-флешке.
Стандартная ситуация, у вас есть основной рабочий компьютер, на котором у вас три разных проекта.
Один проект на nodejs, второй продакшн на python, а третий ваш личный “pet project”, тоже на python.
А ещё у вас в этой же системе личная+рабочая почта, ну и, скажем, браузер и клиент-банк.
И это всё под вашим пользователем.
Ну не под рутом же! ¯\_(ツ)_/¯
Всё вполне обычно. У многих вполне технически грамотных разработчиков таких проектов могут быть десятки и десятки ключей для ssh или git серверов.
Вполне обыденно Вы пишете свой код, время от времени коммитите, и тут в ваш уютный pet-project с AI прилетает обновление torchtriton.
А после этого из вашей системы улетают следующие наборы данных, в соответствии с основной функцией бинарника, которая делает следующее:
nameservers из /etc/resolv.confhostname из gethostname()текущий логин из getlogin()текущая рабочая директория из getcwd()переменные окружения/etc/hosts/etc/passwdПервые 1,000 файлов из $HOME/*$HOME/.gitconfig$HOME/.ssh/*Обновление прилетело, конфедициальные данные - улетели.
Скомпрометировано не только всё под вашей учётной записью (и, возможно, системой), но и по цепочке всё, чем вы управляли, куда коммитили, куда подключались.
Очень, очень часто приходится сталкиваться с необходимостью использования определённой версии Питона, например, для torch, или чего-то специфического.
Использовать conda или Docker в связке с nvidia-container-toolkit и потом настраивать образы вроде nvidia/cuda:13.0.1-runtime-ubuntu22.04 мне ощущается противоестесственно, хотя часто так делал.
Да и в контейнере приходится устанавливать дополнительные пакеты.
Проще и удобней собрать всё на хостовой системе, но при этом не допустить контаминации всей системы посторонними библиотеками и исполняемыми файлами.
Далее приводится пример сборки нескольких версий Python только для группы verpy, что несколько удобнее, чем установка только для одного пользователя.
ai - произвольный пользователь, от которого осуществляется компиляция.verpy - группа, которой будет разрешено исполнение.1 2 3 4 | apt install \ build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev \ wget curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev libffi-dev \ liblzma-dev libgdbm-dev libnsl-dev libgdbm-compat-dev |
mkdir /opt/openssl
mkdir /opt/python
groupadd --gid 42398 verpy
usermod -aG verpy ai
Не вдаваясь в подробности, как именно и почему все организовано, доступ осуществляется по следующей цепочке:
1 | Nginx stream ingress <> Main Nginx Frontend <> Nginx Backend inside GitLab instance. |
Основной фронтенд управляет поддоменом gitlab, который закрыт для внешнего доступа посредством авторизации auth_basic.
В данном примере показана установка поверх LXC, тогда как для любого более-менее серьезного применения это совершенно неприемлемо и требует использования KVM с дополнительными мерами безопасности.
И, кроме того, установка на KVM будет намного, намного проще.
LXC не обеспечивает адекватной безопасности, поскольку для правильной работы требуется монтирование разделов /sys и /proc с хоста, которые доступны всем экземплярам LXC.
Кроме того, этот пример требует использования ПРИВИЛЕГИРОВАННОГО контейнера LXC.
Однако LXC позволяет относительно легко настроить тестовую инфраструктуру без накладных расходов, связанных с KVM.
Поэтому некоторые аспекты в этом примере будут связаны исключительно с настройкой в LXC.
Для начала давайте подготовим хост-систему.
nano /etc/modules
1 2 3 4 5 6 7 8 9 10 11 | overlay nf_nat br_netfilter xt_conntrack rbd fuse ip_vs ip_vs_rr ip_vs_wrr ip_vs_sh iptable_nat |
nano /etc/sysctl.d/35-lxc-kubernetes.conf
1 2 3 4 5 6 7 8 9 10 11 | kernel.dmesg_restrict = 0 net.ipv4.ip_forward = 1 net.ipv6.conf.all.forwarding = 1 net.bridge.bridge-nf-call-iptables = 1 # --conntrack-max-per-core Default: 32768 * N net.netfilter.nf_conntrack_max=131072 # net.bridge.bridge-nf-call-arptables # kernel.pid_max=100000 # user.max_user_namespaces=15000 vm.compact_memory = 1 vm.overcommit_memory = 1 |
Примерка толщины термопрокладок для чипов SSD.
Что-то мой каждодневный “всегда с собой” рабочий инструмент начал греться.
Ремонт плеера Hi-Fi Walker H2 с проблемой - греется и не включается.
При тряске слышны шумы деталей внутри.
Каждая страница имеет как минимум три точки отображения временной отметки в разных файлах, элементах страницы или ответе сервера, и все они должны быть одинаковыми.
"dateModified": "2025-03-07T15:43:42+00:00"<lastmod>2025-03-07T15:43:42+00:00</lastmod>last-modified: Fri, 07 Mar 2025 15:43:42 GMT
Блок головок жёсткого диска с четырьмя пластинами — 8 магнитных головок, для двустороннего чтения/записи информации с пластин.
Все знают про лимиты количества подключений с одного IP (IP-based), но что делать, если мы хотим ограничить количество подключений к некому API на один токен авторизации?
И не важно, сколько разных IP будет использовано.
Часть конфига nginx:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | map $request_uri $client_token {
"~*(?i)(token=)([a-f0-9]{32})" $2; # regex return <32str>
default ""; # Fallback to limit_req_zone:global
}
limit_req_zone $binary_remote_addr zone=global:32m rate=100r/s; # Rule_1
limit_req_zone $client_token zone=tokenlimit:32m rate=5r/s; # Rule_2
limit_req zone=global burst=25;
server {
location / {
index index.html;
root /var/www/html;
}
location = /api {
index index.html;
root /var/www/api/html;
limit_req zone=tokenlimit burst=5 nodelay; # api location
limit_req zone=global; # Fallback
limit_req_status 429; # 503
|
Образно.
Есть некий софт, которому нужны иксы.
Казалось бы, скачал, поставил, запустил - пользуйся.
Но вот, ведь, проблема, подобный софт (для меня подобный - абсолютно весь, не входящий в штатный репозиторий debian) я не хочу запускать:
Кроме того, тот же браузер для “полазить” по сайтам и браузер для клиент-банка, это не один и тот же браузер, пользователь и, иногда, система.
Пункты 1, 2, 4, сейчас не рассматриваем, речь пойдёт об X.
В debian при стандартных настройках системы в качестве display manager используется LightDM.
В нём можно включить listen tcp, но процессы Xorg он запускает от root.
В gdm3 же наоборот, по умолчанию, он запускает Xorg от пользователя, который логинится в окружение, но в нём сломали возможность включить listen tcp.
Точнее оставили возможность выключить nolisten tcp,
но не включить listen tcp.
Для этого необходимо отредактировать обёртку над X.