sysadmin.su

IO devices and latency Энергонезависимая память является краеугольным камнем современных компьютерных систем. Каждая фотография, электронное письмо, банковский баланс, медицинская карта и другие важные данные хранятся на цифровых носителях, часто многократно дублируемых для повышения надежности. Энергонезависимая память, или в просторечии «диск», может хранить двоичные данные даже тогда, когда компьютер, к которому она подключена, выключен. В компьютерах существуют и другие формы энергозависимой памяти, такие как регистры CPU, кэш CPU и оперативная память, все они быстрее, но требуют постоянного питания для работы. Впечатляющая статья с интерактивом. Рассказывают об истории, функциональности и производительность энергонезависимых запоминающих устройств на протяжении всей истории вычислительной техники, используя при этом интерактивные визуальные элементы.

🌟 Nemotron-Terminal: небольшое семейство для терминальных задач. NVIDIA обучила семейство моделей Nemotron-Terminal для автономной работы в терминале Linux: устанавливать зависимости, писать и запускать код, отлаживать окружения и выполнять сквозные инженерные задачи без участия человека. Семейство построено на базе Qwen3 и специально собранном датасете Terminal-Corpus. И фишка не в архитектуре, а в данных. 🟡NVIDIA собрала пайплайн Terminal-Task-Gen с 2 потоками. Первый адаптирует готовые датасеты по математике, коду и SWE-задачам под терминальный формат (без участия LLM в процессе адаптации). Второй генерирует синтетику 2 методами: seed-based (LLM создает новые задачи на основе существующих задач из смежных областей) и skill-based (LLM комбинирует до пяти примитивных навыков из таксономии по 9 доменам: Security, Data Science, System Administration и другим). 🟡В открытый релиз вошли все три модели на 8B, 14B, 32B параметров и 2 датасета: Terminal-Corpus: около 366K траекторий выполнения задач, разбитых на два потока: ~226K адаптированных примеров из Math/Code/SWE и ~140K синтетических задач на основе skill-таксономии. Synthetic-Tasks: задачи в стандартизированном формате: инструкция, Docker-окружение из 9 преднастроенных образов и верификационный набор на pytest. 🟡Результаты прогонов на бенчах. На Terminal-Bench 2.0 все 3 модели показали кратный рост относительно базовой Qwen3: 8B - с 2.5% до 13%, 14B - с 4% до 20.2%, 32B - с 3.4% до 27.4%. Для сравнения: Qwen3-Coder на 480B параметров набирает 23.9%, GPT-5-Mini - 24.0%, Grok 4 - 23.1%. Nemotron-Terminal-32B превосходит или вплотную конкурирует с ними всеми при разнице в размере на порядок. 🟡Несколько внезапных выводов из абляции. Фильтрация неудачных траекторий вредит. Модель, обученная на всех траекториях включая ошибочные, набирает 12.4% против 5.06% у варианта только с успешными. Curriculum learning (сначала простые данные, потом сложные) не дал преимуществ перед простым смешанным обучение

🔒 Your Container Is Not a Sandbox - интересное и достаточно объёмное чтиво о том, как microvm могут стать тем самым решением для ситуаций, когда использовать контейнеры становится не так уж и безопасно... https://emirb.github.io/blog/microvm-2026/ Автор показывает и сравнивает несколько технологий, которые доступны для использования сегодня. P. S. Интерактивные элементы на странице - отдельное приятное в этой статье. 🍪 #microvm #firecracker #напочитать -- Микроблог || RSS подписка

Череда уязвимостей в ядре, приводящих к LPE и container escape продолжается. На этот раз – fragnesia. Это новая LPE уязвимость из семейства Dirty Frag/Dirty Pipe, позволяющая локальному пользователю получить root через corruption page cache в подсистеме XFRM ESP-in-TCP. Эксплойт не требует race condition и работает как deterministic logic bug, что делает эксплуатацию особенно стабильной и опасной. Интересно, что fragnesia появилась как побочный эффект одного из патчей для Dirty Frag. CVE пока не назначена, а фикс пока только в виде небольшого patchset, который ещё не успел попасть во все mainstream kernel releases. P.S. Сегодня последний день подать свой вариант на конкурс и выиграть билет на нашу конференцию БеКон 2026.

Давно не было Обновление nginx 1.31.0 с устранением RCE-уязвимости, эксплуатируемой через HTTP-запрос https://www.opennet.ru/opennews/art.shtml?num=65442 Уязвимость (CVE-2026-42945), которой присвоен критический уровень опасности, вызвана переполнением буфера в модуле ngx_http_rewrite_module, которое может быть эксплуатировано для выполнения кода с правами рабочего процесса nginx через отправку HTTP-запроса со специально оформленным URI. Проблема проявляется в конфигурациях с директивой "rewrite", в которой в регулярных выражениях используются подстановки масок при помощи неименованных переменных (например, $1 и $2), при условии, что в заменяющей строке имеется символ "?". Пример уязвимой конструкции: rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last; Выражения с именованными подстановками уязвимости не подвержены. Например, уязвимость не затрагивает конструкции: rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last; Уязвимость присутствует начиная с версии 0.6.27, выпущенной в марте 2008 года. Причиной появления уязвимости стало то, что буфер выделялся с расчётом, что в него будут записаны неэкранированные данные, а фактически копировались данные после выполнения экранирования спецсимволов, размер которых был больше, так как каждый символ "+", "%" и "&" кодировался не одним, а тремя байтами. NGINX Rift: Achieving NGINX Remote Code Execution via an 18-Year-Old Vulnerability https://depthfirst.com/research/nginx-rift-achieving-nginx-rce-via-an-18-year-old-vulnerability PoC https://github.com/depthfirstdisclosures/nginx-rift Другие уязвимости: - CVE-2026-42926 - возможность подстановки данных атакующего в проксируемый запрос при использовании в настройках директивы "proxy_set_body" и обращении к бэкенду через HTTP/2 (proxy_http_version=2). - CVE-2026-40701 - обращение к памяти после её освобождения (use-after-free) в модуле ngx_http_ssl_module, возникающее при обработке ответов от DNS-сервера в

QEMUtiny - уязвимости в QEMU, позволяющие получить доступ к хост-окружению из гостевой системы https://www.opennet.ru/opennews/art.shtml?num=65456 Исследователи, которые на днях выявили уязвимость Fragnesia в ядре Linux, опубликовали информацию об уязвимостях в QEMU, позволяющих из гостевой системы получить root-доступ к хост-окружению. Проблеме присвоено кодовое имя QEMUtiny, но CVE-идентификатор пока не назначен. Подготовлен эксплоит, в котором задействованы две уязвимости в коде эмуляции устройства CXL (Compute Express Link). Обе уязвимости присутствуют в коде cxl-mailbox-utils.c. Первая уязвимость проявляется начиная с выпуска QEMU 7.1.0 и приводит к чтению памяти из области вне выделенного буфера из-за того, что функция cmd_logs_get_log() ошибочно трактует запрошенное смещение CEL-лога как индекс в массиве, в то время как оно задаётся в байтах. Вторая уязвимость проявляется начиная с QEMU 11.0.0 и приводит к переполнению буфера в функции cmd_features_set_feature() из-за обработки смещения на структуры при записи атрибутов без проверки, что вычисленное значение "offset + bytes_to_copy" укладывается в размер выбранной структуры. Фактически атака возможна только на последнюю ветку QEMU 11.0.0. Об исправлении пока ничего не сообщается, указано только, что перед раскрытием уязвимости, информация о ней была передана разработчикам QEMU, которые ответили, что поддержка устройства CXL в QEMU реализована не для использования при виртуализации. Эксплоит проверен с кодовой базой QEMU от 11 мая с последним коммитом 5e61afe. Работа эксплоита завязана на раскладку структур в памяти каждой конкретной сборки QEMU и системной libc, но по мнению исследователей, воспользовавшись для сканирования памяти уязвимостью, приводящей к чтению из области вне буфера, можно создать универсальный эксплоит, работающий с разными версиями QEMU. PoC https://github.com/v12-security/pocs/blob/main/qemu/poc.c > CXL Много кто из подписчиков использует? 🌝 Я почему спрашиваю, потому что вообще э

Prom++: как сжать разметку метрик Prometheus и снизить расход памяти в 2,5 раза с помощью статистики данных Миллионы метрик, чистый код, но аллокатор показывает в разы больше памяти, чем должно занимать «полезное» содержимое. Профайлер светит на парсинг, а вы гадаете: куда деваются мегабайты? Prom++ — это оригинальный Prometheus, переписанный на C++ командой Флант. Оптимизированы потребление RAM (среднем в 7.8 раза меньше), CPU (среднем в 2.2 раза меньше), cобственный оптимизированный WAL, агрессивное сжатие WAL. Ну, и вишенка на торте — практически (отличается в части WAL) полная совместимость с Prometheus. К сожалению, на стоимость долговременного хранения и передачи данных в S3 Prom++ не сильно повляет. Читать статью на Хабр Читать статью о том, как устроен Prom++ Репыч Prom++ на Гитхаб (там же кратко описан механизм миграции с оригинального Prometheus) 📱 Telegram | 📲 MAX

Трансляция SPbLUG (@spblug) Тема: Синхронизация времени: история, протоколы, особенности. От первых часов до современных серверов и протоколов. Докладывает: Михаил, главный инженер ООО "Сети WEBA" Синхронизация времени: история, протоколы, особенности. https://rutube.ru/video/0c9684977690d5b9c6927cc9d9beec76/ UPD Трансляция закончилась, запись доступна по ссылке + прицепил к посту

Massimiliano Oldani (sgrakkyu) опубликовал PoC, который из непривилегированного процесса внутри изолированного по сети контейнера даёт полноценный побег на хост с root. В основе — свежезакрытая уязвимость IPv6-стека ядра Linux: при сборке UDPv6-фрагментов через splice() ядро выделяло буфер только под заголовки, забывая про перенос выровненных байтов (fraggap), и запись уходила за конец объекта прямо в служебную структуру skb_shared_info. Дальше один испорченный байт nr_frags разворачивается в page use-after-free и технику Dirty Pagetable с произвольным чтением/записью ядра: KASLR обходится через SMP-трамплин, SELinux глушится подменой пролога avc_denied(), а сам побег из контейнера делается через core_pattern. Всё срабатывает детерминированно, без heap-grooming и без каких-либо привилегий. Баг тихо жил с ядра 6.0, но эксплуатировать его стало возможно только с версии 6.6, после которой он попал во все поддерживаемые ветки и был незаметно убран коммитом в середине июня — без CVE, без advisory и без бэкпорта в stable, что автор и критикует: фикс лежит в открытом дереве, фактически раздавая рабочий 0-day. Опубликованный PoC намеренно ослаблен и работает только на ядрах без CONFIG_INIT_ON_ALLOC (RHEL/CentOS). Боевую версию обещают после выхода патчей.

Проектирование POSTGRES: как задумывалась популярная СУБД Чтиво на выходные. 8 июля у PostgreSQL юбилей — ей исполняется 30 лет. В 1996 году Марк Фурнье из компании Networking Services предоставил первый внешний сервер для разработки опенсорсного проекта Postgres. До этого СУБД разрабатывали на мощностях Калифорнийского университета в Беркли . В день рождения PostgreSQL на Хабре опубликовали перевод статьи, которая послужила основой этой СУБД. Кстати, у неё тоже юбилей — 40 лет с момента выхода. @usr_bin_linux

Kubesplaining — CLI-инструмент для анализа безопасности Kubernetes, написанный на Go. Он позиционируется как «Cloudsplaining для Kubernetes». В отличие от большинства сканеров (Kubescape, Trivy, Polaris), которые ищут отдельные misconfigurations, данный инструмент строит граф privilege escalation и показывает реальные многошаговые цепочки атаки от любого непривилегированного субъекта до критических: - cluster-admin / system:masters - node-escape (привилегированные поды + hostPath) - доступ к секретам в kube-system Он использует BFS поиск по RBAC + состоянию подов и выдаёт полную цепочку с объяснениями, evidence и remediation. Ключевые возможности: - Модули (всего ~45 правил): RBAC (wildcard, impersonation, bind/escalate и т.д.), Pod Security, NetworkPolicy, Admission Webhooks, Secrets, ServiceAccounts, Least-Privilege (на основе audit logs). - Поддержка живого кластера, snapshot (JSON) и отдельных манифестов. - Отличные отчёты: интерактивный HTML, JSON, CSV, SARIF (для GitHub Code Scanning). - CI-friendly: --baseline, --ci-mode, delta-анализ. - Полностью offline-анализ после скачивания snapshot'а. - Хорошая документация, примеры remediation (kubectl patch, Kyverno/Gatekeeper). Здесь можно посмотреть демо отчет.

Python и DevOps: Ключ к автоматизации Linux (2022) Это практическое руководство научит вас использовать Python для повседневных задач администрирования Linux с помощью наиболее удобных утилит DevOps, включая Docker, Kubernetes и Terraform. #Книга #RU #Python #DevOps #Docker #Terraform #Kubernetes #Linux