🐧 Linux: AppArmor vs SELinux в 2026 — выбор который влияет на безопасность при следующем Copy Fail

Коллеги, Copy Fail дал нам хороший повод поговорить о вещи которую большинство откладывает. SELinux и AppArmor работали в режиме enforcing на ваших серверах в момент атаки? Или были отключены "потому что мешают"?

Одна из самых распространённых ошибок — отключить SELinux или AppArmor при первых проблемах. Вместо этого нужно использовать permissive (SELinux) или complain (AppArmor) режимы для отладки. Отключение этих слоёв оставляет систему открытой для атак повышения привилегий.

Быстрый выбор: SELinux — для RHEL/Rocky/AlmaLinux, AppArmor — для Ubuntu/Debian. Это не холивар, это дефолт дистрибутива.

# ---- APPARMOR (Ubuntu/Debian) ----
# Проверяем статус:
aa-status
apparmor_status | grep -E "profiles|processes"

# Включаем enforce для конкретного сервиса:
aa-enforce /etc/apparmor.d/usr.sbin.nginx
systemctl reload apparmor

# Смотрим нарушения в логах (complain mode — для диагностики):
aa-complain /etc/apparmor.d/usr.sbin.nginx
journalctl -k | grep apparmor | tail -20

# Создаём профиль для нового сервиса:
aa-genprof /usr/local/bin/myapp
# Запускаем сервис, делаем типичные операции, останавливаем
# aa-genprof предложит профиль на основе реального поведения

# ---- SELINUX (RHEL/Rocky/AlmaLinux) ----
# Проверяем статус:
getenforce  # Enforcing / Permissive / Disabled
sestatus

# Если Disabled — включаем через /etc/selinux/config:
sed -i 's/SELINUX=disabled/SELINUX=enforcing/' /etc/selinux/config
# Перезагрузка обязательна. Сначала переводим в Permissive:
sed -i 's/SELINUX=disabled/SELINUX=permissive/' /etc/selinux/config

# Смотрим что SELinux блокирует:
ausearch -m AVC -ts recent | tail -30
# Генерируем политику под конкретный deny:
ausearch -m AVC -ts recent | audit2allow -M mypolicy
semodule -i mypolicy.pp

# Проверяем нет ли процессов без confinement:
ps -eZ | grep unconfined_t

Начинайте с complain/permissive режима для одного конкретного сервиса, собирайте события под реальной нагрузкой, затем переводите в строгий режим. Резкое включение enforcing для всего почти гарантированно сломает что-то неочевидное — unix-сокеты, временные директории, кастомные пути логов.

Зачем именно сейчас:
Copy Fail требует локального доступа — но что если атакующий уже внутри через другую уязвимость? SELinux/AppArmor в enforcing ограничивает что может сделать скомпрометированный процесс даже с root-привилегиями.

Итог: запусти getenforce или aa-status прямо сейчас. Если не Enforcing — у тебя есть задача на эту пятницу.

#linux #apparmor #selinux #security #hardening #sysadmin #admin_future

🧠 Skills: Privilege creep — тихая дыра которая растёт годами и взрывается в инцидент

Коллеги, пятничный пост о вещи которую все знают теоретически, но мало кто делает системно на практике.

Даже самая совершенная система управления правами со временем деградирует — «дрейф привилегий». Сотрудники меняют должности, увольняются, а их старые доступы остаются активными. Систематический аудит позволяет выявить «мёртвые души» — аккаунты уволенных, избыточные права администраторов и факты несанкционированного доступа к критичным папкам.

Copy Fail, PhantomRPC, CVE-2026-32202 — все три эксплуатируют локальный или сетевой доступ. Принцип наименьших привилегий напрямую ограничивает радиус поражения каждой из них.

Практический аудит привилегий — делаем сегодня:

# ---- WINDOWS AD: кто лишний в привилегированных группах ----
# Топ-3 группы риска:
$groups = @("Domain Admins","Enterprise Admins","Schema Admins")
foreach ($g in $groups) {
    Write-Host "=== $g ===" -ForegroundColor Red
    Get-ADGroupMember $g -Recursive |
        Get-ADUser -Properties LastLogonDate, Enabled |
        Select-Object Name, Enabled, LastLogonDate |
        Sort-Object LastLogonDate
}
# Всё что не логинилось > 90 дней — под вопросом

# Ищем аккаунты уволенных (не отключены, но не логинились):
$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $cutoff} `
    -Properties LastLogonDate, Department |
    Select-Object Name, Department, LastLogonDate |
    Export-Csv "stale_accounts.csv" -NoTypeInformation

# ---- LINUX: кто имеет sudo и не должен ----
# На каждом сервере:
grep -Po '^sudo.+:\K.*' /etc/group | tr ',' '\n'
cat /etc/sudoers /etc/sudoers.d/* 2>/dev/null | \
    grep -v "^#\|^$" | grep "ALL="
# Всё что не "systemd-related" и не конкретные команды — ревью

# ---- LINUX: сервисные учётки с интерактивным shell ----
awk -F: '$7 != "/sbin/nologin" && $7 != "/bin/false" && \
    $3 >= 500 {print $1, $7}' /etc/passwd
# Сервисные аккаунты должны иметь /sbin/nologin
# Если видишь /bin/bash — это либо человек либо проблема

# ---- АВТОМАТИЗАЦИЯ РЕВЬЮ (раз в квартал) ----
# Добавляем в cron/CI:
# 0 9 1 */3 * /opt/scripts/privilege_audit.sh | \
#   mail -s "Quarterly Privilege Audit" admin@company.com

Зачем это срочно именно сейчас:
Принцип наименьших привилегий применим ко всем уровням — учётным записям пользователей, системам, процессам, сетям, базам данных и всем другим аспектам IT-инфраструктуры. Скомпрометированный аккаунт рядового сотрудника не должен открывать хакеру доступ к финансовым отчётам или ядру инфраструктуры.

Итог: один час аудита привилегий в пятницу — это несколько закрытых векторов атаки к понедельнику. Начни с Domain Admins. Обычно там уже есть сюрпризы.

#skills #security #privilegemanagement #activedirectory #linux #sysadmin #admin_future

🐧 Linux: Dirty Frag — вчера вечером раскрыли новый LPE, патчей ещё нет

Коллеги, срочная новость прямо с вчерашнего вечера. 8 мая независимый исследователь Хёнву Ким опубликовал Dirty Frag — два новых CVE в ядре Linux с публичным PoC и без патчей. Это не учебная тревога.

CVE-2026-43284 и CVE-2026-43500 — пара связанных уязвимостей в IPsec ESP и RxRPC подсистемах ядра. Любой непривилегированный локальный пользователь получает root. В отличие от Copy Fail с 4-байтовой записью, Dirty Frag позволяет полностью контролируемую запись в page cache в произвольном месте — за один выстрел. Исследователь сообщает о очень высокой надёжности без риска kernel panic.

Что делает это особенно опасным: контейнерные workloads наследуют уязвимость хоста — компрометация любого контейнера с доступом к AF_KEY, XFRM netlink или AF_RXRPC сокетам (дефолт для Docker, containerd и большинства Kubernetes pods) даёт root на хосте.

Embargo было нарушено третьей стороной, что вынудило исследователя опубликовать раньше срока — до выхода патчей дистрибутивов.

# МИТИГЕЙШН — НЕМЕДЛЕННО, пока патчей нет:
# Блокируем три затронутых модуля

sudo sh -c "printf 'install esp4 /bin/false\n\
install esp6 /bin/false\ninstall rxrpc /bin/false\n' \
> /etc/modprobe.d/dirtyfrag.conf"

# Выгружаем если уже загружены:
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true

# Проверяем что модули не загружены:
lsmod | grep -E "esp4|esp6|rxrpc"
# Пустой вывод = в безопасности

# Проверяем затронуты ли конкретные версии ядра:
uname -r
# Затронуты ВСЕ дистрибутивы с ядром 2017+ до появления патча

# Следим за патчами:
# AlmaLinux: almalinux.org/blog
# Ubuntu: ubuntu.com/security/notices
# RHEL: access.redhat.com/security/vulnerabilities

# Мониторим загрузку подозрительных модулей:
auditctl -a always,exit -F arch=b64 \
    -S finit_module -S init_module \
    -k kernel_module_load

Зачем это критично сегодня:
Dirty Frag — прямой наследник Copy Fail того же класса уязвимостей. PoC публичен, патчей пока нет ни у одного дистрибутива. Организации должны считать уязвимость валидной и эксплуатируемой прямо сейчас.

Итог: три команды — один blacklist-файл — перезагрузка. Делай это сейчас, пока читаешь пост. Патч поставишь когда выйдет.

#linux #kernel #cve #dirtyfrag #security #lpe #sysadmin #admin_future

🐧 Linux: Debian 14 «Forky» вводит обязательные воспроизводимые сборки — и это меняет supply chain security

Коллеги, 10 мая Debian Release Team объявила о решении которого ждали годами. Debian теперь блокирует пакеты, не прошедшие проверку воспроизводимой сборки, от попадания в testing. Это работает с 9 мая, во время текущего цикла разработки Forky. Правило распространяется и на уже существующие пакеты — если обновление нарушает воспроизводимость, миграция блокируется.

Что такое reproducible builds на практике:

Когда пакет собирается воспроизводимо, компиляция одного и того же исходного кода в одном и том же окружении каждый раз даёт идентичный бинарный файл. Это позволяет любому проверить, что дистрибутируемые бинари соответствуют опубликованному исходному коду. Звучит как само собой разумеющееся — но на практике это не так. Метки времени в сборке, случайные идентификаторы, порядок файлов — всё это делает бинари разными при каждой сборке.

Почему это важно именно сейчас:
Независимо верифицируемый путь от исходного кода к бинарному файлу становится всё более критичным с точки зрения безопасности цепочки поставок. XZ Utils backdoor, атаки на npm-пакеты, скомпрометированные CI/CD пайплайны — всё это атаки на supply chain. Reproducible builds делают их детектируемыми.

# Как проверить воспроизводимость пакета в Debian прямо сейчас:
# Смотрим статус на reproduce.debian.net
curl -s "https://reproduce.debian.net/api/v0/pkgset/by_name/unstable/openssh" \
    | python3 -m json.tool | grep -E "status|suite"

# Для своей системы — проверяем установленные пакеты через debsums:
apt install debsums
debsums -c  # проверяем контрольные суммы файлов

# Для разработчиков пакетов — проверяем воспроизводимость через reprotest:
apt install reprotest
reprotest -- dpkg-buildpackage -b .
# Собирает пакет дважды в разных условиях и сравнивает результат

# Смотрим общий дашборд воспроизводимости Debian:
# https://reproduce.debian.net/
# На момент анонса: >98% пакетов уже воспроизводимы на всех архитектурах

Debian 14 «Forky» также станет первым релизом с нативным rollback, undo и историей операций в APT package manager. Выход ожидается в июне-августе 2027 года.

Итог: reproducible builds — это не академия. Это инфраструктурный фундамент доверия к пакетам. Debian сделал это обязательным. Остальным дистрибутивам теперь неловко этого не делать.

#linux #debian #security #supplychain #sysadmin #admin_future

🐧 Linux: Killswitch в ядре — красная кнопка для zero-day, которая пугает всех кроме Red Hat

Коллеги, последние две недели — Copy Fail, Dirty Frag, оба с публичным PoC, оба до выхода патчей. Sasha Levin (NVIDIA, co-maintainer stable Linux) предложил системный ответ на этот хаос. И разгорелся нешуточный спор.

Предложенная фича «Killswitch» позволяет администраторам временно отключить конкретные уязвимые функции ядра прямо в runtime — вместо того чтобы сидеть и ждать патчей. Как сказал сам Левин: «когда уязвимость становится публичной, флоты остаются открытыми пока не будет собрано, распространено и перезагружено в новое ядро. Для многих проблем самый простой митигейшн — просто прекратить вызывать багованную функцию».

Как это работает: фича доступна через securityfs ядра. Привилегированный администратор включает killswitch для конкретной функции — она немедленно начинает возвращать ошибку. Эффект мгновенный, работает до отключения или перезагрузки.

Почему это спорно:

В r/cybersecurity предложение называют «ужасной идеей», «абсурдом» и «абсолютно пугающим». Аргумент против: люди будут использовать killswitch вместо патчинга.

Red Hat поддержал: «мы за включение killswitch в ядро, особенно по мере того как темп и серьёзность эксплойтов растёт благодаря LLM-сканированию. Патчи критичны, но они часто разрушительны. Организациям приходится взвешивать защиту через патч против производственного impact от рестартов».

# Что это значит СЕЙЧАС — фича ещё не в ядре, это proposal.
# Но принцип уже можно применять вручную для Copy Fail и Dirty Frag:

# Copy Fail (CVE-2026-31431) — блокируем AF_ALG путь:
echo "install algif_aead /bin/false" >> /etc/modprobe.d/killswitch.conf
rmmod algif_aead 2>/dev/null

# Dirty Frag (CVE-2026-43284 + CVE-2026-43500) — блокируем esp4/esp6/rxrpc:
echo -e "install esp4 /bin/false\ninstall esp6 /bin/false\n\
install rxrpc /bin/false" >> /etc/modprobe.d/killswitch.conf
rmmod esp4 esp6 rxrpc 2>/dev/null

# Проверяем что всё заблокировано:
lsmod | grep -E "algif_aead|esp4|esp6|rxrpc"
# Пустой вывод = хорошо

# ЕСЛИ НУЖЕН esp4/esp6 (используете IPsec) — только патч ядра:
uname -r  # нужна 7.0.6 / 6.18.29 / 6.12.87 / 6.6.138+
apt update && apt full-upgrade  # Ubuntu/Debian
dnf update kernel -y            # RHEL/AlmaLinux/Rocky

Зачем это важно как концепция: killswitch — признание факта: если окно между публичным раскрытием и выходом патчей нельзя надёжно контролировать, администраторам нужен способ снизить риск на своих условиях.

Итог: proposal ещё под ревью, в ядро не принят. Но принцип — правильный. Ручная версия через blacklist работает уже сейчас и именно это большинство из нас делало последние две недели.

#linux #kernel #security #killswitch #copyfail #dirtyfrag #sysadmin #admin_future

-🐧 Linux: Fragnesia — третья уязвимость за две недели, и у неё нет CVE

Коллеги, вчера 13 мая вышел ещё один сюрприз. Команда v12-security раскрыла «Fragnesia» — универсальный LPE-эксплойт в ядре Linux, обнаруженный Уильямом Боулингом. Fragnesia относится к семейству Dirty Frag, но это отдельная ошибка в ESP/XFRM — она получила собственный патч. Митигейшн — тот же что и для Dirty Frag.

Механика: эксплойт использует логическую ошибку в подсистеме XFRM ESP-in-TCP. Когда TCP-сокет переходит в режим espintcp ULP после того как данные уже были перемещены через splice из файла, достигается произвольная байтовая запись в page cache read-only файлов — без race condition.

Это уже третья уязвимость класса page-cache write за две недели: Copy Fail → Dirty Frag → Fragnesia.

Критическое предупреждение после эксплуатации: после запуска эксплойта /usr/bin/su в page cache остаётся изменённым и будет порождать root-шелл при каждом вызове — до принудительного сброса кэша или перезагрузки.

# МИТИГЕЙШН — тот же что для Dirty Frag
# Блокируем esp4, esp6, rxrpc:
printf 'install esp4 /bin/false\n\
install esp6 /bin/false\n\
install rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf
rmmod esp4 esp6 rxrpc 2>/dev/null || true

# Если система уже была под атакой — ОБЯЗАТЕЛЬНО сбрасываем page cache:
echo 1 | tee /proc/sys/vm/drop_caches
# Или перезагружаемся

# Проверяем что модули не загружены:
lsmod | grep -E "esp4|esp6|rxrpc"
# Пустой вывод = хорошо

# Для систем использующих IPsec — только патч ядра:
# Нужна версия с патчем Fragnesia (появится в 7.0.7+ / 6.18.30+)
# Следим: kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.0.7

# AMD CPU op-cache: отдельная уязвимость этой недели (не ядро Linux)
# Затрагивает Zen 2. Патч от AMD — через обновление microcode:
apt update && apt install amd64-microcode  # Debian/Ubuntu
dnf update microcode_ctl               # RHEL/Rocky/AlmaLinux

Зачем это важно именно сейчас:
Три LPE за две недели из одной поверхности атаки (page cache / XFRM / ESP) говорят об одном: этот класс уязвимостей ещё не исчерпан. Killswitch-proposal от Левина выглядит уже не паранойей, а инженерным реализмом.

Итог: митигейшн простой — blacklist трёх модулей. Если IPsec не используется — делать прямо сейчас. Если используется — в приоритет патч ядра как только появится.

#linux #kernel #cve #fragnesia #lpe #security #sysadmin #admin_future

🐧 Linux: Итог двух недель хаоса — что случилось, что закрыто, что делать сейчас

Коллеги, пятница — хороший момент подвести итог самого насыщенного security-периода в Linux за последние годы. Три уязвимости одного класса за две недели. Сегодня — финальный срез.

Сегодня, 15 мая — дедлайн CISA для федеральных агентств США по Copy Fail (CVE-2026-31431). Патчи выпущены всеми major дистрибутивами.

Итоговая карта угроз:

Copy Fail (CVE-2026-31431): логическая ошибка в authencesn криптографическом шаблоне. 732-байтовый Python-скрипт даёт root на всех Linux дистрибутивах с 2017 года. Эксплуатируется в дикой природе.

Dirty Frag (CVE-2026-43284 + CVE-2026-43500): две уязвимости в xfrm-ESP и RxRPC. Патч в 7.0.6 / 6.18.29.

Fragnesia (CVE-2026-46300): отдельная ошибка в XFRM ESP-in-TCP, та же поверхность атаки. Позволяет непривилегированному локальному атакующему изменять содержимое read-only файлов в page cache и получать root через детерминированный page-cache corruption primitive.

# ФИНАЛЬНЫЙ СТАТУС ПАТЧЕЙ — проверяем прямо сейчас:
uname -r

# Нужные версии (все три CVE закрыты):
# Ubuntu 24.04:  6.8.0-60+  → apt update && apt full-upgrade && reboot
# Ubuntu 22.04:  5.15.0-140+ → apt update && apt full-upgrade && reboot
# RHEL/Rocky/AlmaLinux 9: 5.14.0-611.54.3+ → dnf update kernel && reboot
# RHEL/Rocky/AlmaLinux 8: 4.18.0-553.123.2+ → dnf update kernel && reboot
# Debian 12: linux 6.1.136 → apt full-upgrade && reboot

# Если патч ещё не применён — митигейшн (пока):
cat /etc/modprobe.d/kernel-lpe-2026.conf 2>/dev/null || \
printf "install algif_aead /bin/false\n\
install esp4 /bin/false\n\
install esp6 /bin/false\n\
install rxrpc /bin/false\n" | \
tee /etc/modprobe.d/kernel-lpe-2026.conf

# Критически важно: если хост мог быть скомпрометирован —
# сбрасываем page cache ПЕРЕД тем как доверять setuid-бинарям:
echo 1 | tee /proc/sys/vm/drop_caches

# Проверяем что модули не загружены:
lsmod | grep -E "algif_aead|esp4|esp6|rxrpc"

Один итоговый вывод про архитектуру:
Все три уязвимости — один класс: page-cache write primitive. Это означает что поверхность ещё не исчерпана. Killswitch-предложение Левина обсуждается именно потому что традиционный цикл "раскрытие → патч → деплой" не справляется когда эксплойты появляются быстрее патчей.

Итог: патч + перезагрузка. Для контейнерных сред — проверить хостовое ядро, не только образ контейнера. Хороших выходных без инцидентов.

#linux #kernel #cve #copyfail #dirtyfrag #fragnesia #sysadmin #admin_future

🐧 Linux: Как работает page-cache write — механика трёх уязвимостей мая на пальцах

Коллеги, понедельник — хороший момент чтобы разобраться в механике, а не просто закрыть тикет с митигейшном. Copy Fail, Dirty Frag, Fragnesia — все три эксплуатируют один примитив. Понимание «почему» защитит от следующего.

Page cache — это буфер в памяти ядра для содержимого файлов. Когда ты читаешь файл, ядро кэширует страницы. Когда файл открыт read-only — ядро гарантирует неизменность этих страниц. Или гарантировало.

Copy Fail: ядро устанавливает req->src = req->dst и цепляет tag-страницы из source scatterlist в output scatterlist через sg_chain(). Когда userspace подаёт данные через splice(), эти tag-страницы ссылаются на page cache файла. Алгоритм authencesn записывает 4 байта в scratch space — и эта запись оказывается внутри кэшированных данных файла в памяти, минуя права доступа.

Fragnesia (CVE-2026-46300): та же поверхность, другой вектор — логическая ошибка в XFRM ESP-in-TCP subsystem. Когда TCP-сокет переходит в espintcp ULP после splice из файла — достигается произвольная байтовая запись в page cache read-only файлов без race condition.

Итог для всех трёх: запись в read-only /usr/bin/su → setuid бит → root.

# СТАТУС ПАТЧЕЙ — понедельник 18 мая:
# Все три (Copy Fail + Dirty Frag + Fragnesia) закрыты в:
# Ubuntu 24.04: linux 6.8.0-64 → проверяем
uname -r && apt-cache policy linux-image-$(uname -r)

# RHEL/AlmaLinux/Rocky 9: kernel-5.14.0-611.54.3
rpm -qa kernel | sort | tail -3

# Debian 12: linux 6.1.136 → apt-cache policy linux-image-amd64

# Если патч стоит — проверяем что перезагрузились с новым ядром:
uname -r  # должна совпадать с установленной версией

# Если НЕ перезагружались — митигейшн всё ещё нужен:
lsmod | grep -E "algif_aead|esp4|esp6|rxrpc"
# Непустой вывод + патч без перезагрузки = всё ещё уязвимы

# После патча И перезагрузки — можно убрать blacklist:
# rm /etc/modprobe.d/kernel-lpe-2026.conf && update-initramfs -u

# Проверяем AppArmor/SELinux — дополнительная защита:
# AppArmor (Ubuntu): ограничение user namespaces частично митигирует Fragnesia
aa-status | grep "user namespaces"
# SELinux (RHEL): enforcing mode ограничивает эксплуатацию
getenforce

Почему это важно как архитектурный урок:
Dirty Frag применяет две отдельные page-cache write примитивы: один в xfrm-ESP, другой в RxRPC. Оба позволяют модифицировать page-cache-backed память не принадлежащую исключительно ядру, что даёт возможность повредить чувствительные файлы и получить привилегии. Три разных пути — один класс. Следи за XFRM и splice() в следующих раскрытиях.

Итог: патч + перезагрузка = закрыто. Без перезагрузки патч не работает. Проверь uname -r прямо сейчас.

#linux #kernel #security #pagecache #copyfail #sysadmin #admin_future

🐧 Linux: ModuleJail — сисадмин из Бельгии решил проблему которую не осилил Red Hat

Коллеги, май 2026-го показал: ручной blacklist модулей на флоте из сотен серверов — это не масштабируемо. Пока мы прописывали algif_aead, esp4, esp6 и rxrpc по одному, бельгийский сисадмин и Tesla-хакер Jasper Nuyens написал инструмент который делает это за секунды — для всего флота.

ModuleJail — GPLv3 shell-скрипт который сканирует запущенную Linux-систему и автоматически создаёт blacklist для всех неиспользуемых модулей ядра — без перезагрузки. Работает на Debian, Ubuntu, RHEL, Fedora, AlmaLinux и Arch Linux.

ModuleJail делает снимок загруженных модулей (/proc/modules) и вычисляет разность с полным деревом модулей (/lib/modules/$(uname -r)). Каждый модуль из разности, за исключением встроенного baseline и whitelist администратора, попадает в директиву install в модprobe.d-совместимый blacklist-файл.

# Установка и запуск за одну команду:
curl -fsSL https://raw.githubusercontent.com/jnuyens/modulejail/main/modulejail \
    -o modulejail && chmod +x modulejail

# Запускаем с профилем для сервера (default: conservative)
# ВАЖНО: запускать только после полной загрузки всех сервисов
sudo sh modulejail -p conservative

# Три профиля:
# minimal     — только core ФС и критичные модули
# conservative — minimal + драйверы для VM/bare-metal серверов (DEFAULT)
# desktop     — conservative + WiFi, BT, audio, video

# Результат: /etc/modprobe.d/modulejail-blacklist.conf
# Смотрим сколько модулей заблокировано:
wc -l /etc/modprobe.d/modulejail-blacklist.conf

# Логирование заблокированных попыток загрузки (v1.2+):
# Каждая попытка modprobe <blocked_module> пишет в syslog:
journalctl -t modulejail -f

# Откат без перезагрузки — просто удаляем файл:
rm /etc/modprobe.d/modulejail-blacklist.conf
# Для немедленного эффекта — modprobe нужный_модуль вручную

# Ansible для флота (всё в git):
# - name: Deploy ModuleJail
#   script: modulejail -p conservative
#   args:
#     creates: /etc/modprobe.d/modulejail-blacklist.conf

Важная оговорка: ModuleJail должен запускаться только после достижения системой стабильного состояния — все сервисы запущены, ФС примонтированы, нужные драйверы загружены. Запуск слишком рано может заблокировать модули нужные позже.

Зачем это важно именно сейчас: AI-assisted security scanning делает с ядром Linux то, что массовый fuzzing сделал с userspace-кодом десять лет назад — только быстрее и в значительно большем масштабе. Много лет скрытых LPE-багов в модулях ядра вот-вот всплывут в быстрой последовательности.

Итог: не заменяет патчинг. Но пока патч не вышел — это лучший способ превратить следующий CVE в «не моя проблема» за счёт сокращения поверхности атаки.

#linux #security #kernel #modulejail #hardening #sysadmin #admin_future

🧠 Skills: CVE-2026-46333 — новый Linux LPE раскрыт сегодня, и он позволяет читать SSH-ключи

Коллеги, небольшой сдвиг формата сегодняшнего Skills-поста. Вместо soft skills — разберём как правильно реагировать на раскрытие прямо в момент его появления. Потому что сегодня именно такой момент.

Сегодня, 19 мая 2026, исследователи Qualys раскрыли CVE-2026-46333 в ядре Linux. Уязвимость позволяет непривилегированному пользователю читать файлы принадлежащие root — в том числе SSH-ключи (/etc/ssh/ssh_host_*_key) и файл /etc/shadow. PoC доступен публично как ssh-keysign-pwn и chage_pwn. Подтверждена работоспособность на Arch Linux, Debian, Ubuntu, CentOS и Raspberry Pi OS.

Механика: уязвимость в __ptrace_may_access(), которая пропускает dumpable-проверку когда task->mm == NULL. do_exit() запускает exit_mm() перед exit_files() — нет mm, но fd-ы ещё живые — и pidfd_getfd(2) успешно выполняется в этом окне когда uid вызывающего совпадает с целевым.

Это не LPE до root — это чтение приватных ключей. Для серверов с SSH-доступом — это критично.

# НЕМЕДЛЕННАЯ ДИАГНОСТИКА:
# Смотрим были ли у нас непривилегированные пользователи
# с доступом к системе за последние сутки
last | head -20
grep "Accepted" /var/log/auth.log | grep -v root | tail -20

# Если на сервере нет непривилегированных пользователей кроме root —
# риск значительно ниже (нет кому эксплуатировать)
awk -F: '$3 >= 1000 && $7 != "/sbin/nologin" && $7 != "/bin/false" \
    {print $1, $7}' /etc/passwd

# МИТИГЕЙШН пока патча нет:
# 1. Ужесточаем права на SSH host keys (уже должны быть 600):
ls -la /etc/ssh/ssh_host_*
chmod 600 /etc/ssh/ssh_host_*_key

# 2. Ограничиваем чтение shadow:
ls -la /etc/shadow  # должен быть 640 или 000
chmod 640 /etc/shadow

# 3. Если на сервере есть непривилегированные пользователи —
# временно блокируем ptrace для непривилегированных:
echo 1 | tee /proc/sys/kernel/yama/ptrace_scope
# или более жёстко:
echo 3 | tee /proc/sys/kernel/yama/ptrace_scope
# 3 = только root может ptrace (ломает некоторые отладчики)

# Делаем permanent через sysctl:
echo "kernel.yama.ptrace_scope = 1" >> /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf

# СЛЕДИМ за патчем:
# upstream: kernel.org (ветки 7.0.x, 6.18.x, 6.12.x)
# Ubuntu: ubuntu.com/security/notices
# RHEL: access.redhat.com/security

Как работает правильная реакция на fresh disclosure:

Первые 30 минут: читаем advisory, понимаем prerequisites (local? network? authenticated?), проверяем есть ли у нас этот компонент в системе.

30 минут — 2 часа: ищем временный митигейшн (не патч — его ещё нет). Применяем если риск в нашей среде реален.

После: ждём патча дистрибутива, ставим как только появится, убираем митигейшн.

Это не паника — это процесс. Разница в том, что процесс можно делегировать и автоматизировать.

Итог: ptrace_scope = 1 — это одна команда которая снижает риск не только от CVE-2026-46333, но и от всего класса ptrace-атак. Это и есть defence-in-depth в действии.

#skills #linux #cve #security #реакция #sysadmin #admin_future

🐧 Linux: DirtyDecrypt — пятый вариант page-cache атаки за три недели, и сегодня вышел PoC

Коллеги, майский марафон Linux-уязвимостей продолжается. Сегодня утром на Hacker News — DirtyDecrypt (CVE-2026-31635). Это уже пятая уязвимость одного класса за три недели.

DirtyDecrypt обнаружили исследователи Zellic и V12, но при попытке зарепортить узнали — уязвимость уже была исправлена в mainline. Это rxgk page cache write из-за отсутствующего COW-guard в rxgk_decrypt_skb(). Оценивается как вариант Copy Fail, Dirty Frag и Fragnesia — все они дают root на уязвимых системах.

Хорошая новость: патч уже в mainline. Плохая: PoC публичен прямо сейчас.

Итоговая карта всех пяти за май 2026:

Copy Fail  (CVE-2026-31431)  — 29 апреля — AF_ALG, algif_aead
Dirty Frag (CVE-2026-43284)  — 7 мая    — ESP xfrm, esp4/esp6
Dirty Frag (CVE-2026-43500)  — 7 мая    — RxRPC rxrpc
Fragnesia  (CVE-2026-46300)  — 13 мая   — XFRM ESP-in-TCP
DirtyDecrypt(CVE-2026-31635) — 20 мая   — rxgk_decrypt_skb
CVE-2026-46333               — 19 мая   — ptrace exit-race (чтение ключей)

Все шесть закрываются одним митигейшном на системах без IPsec/RxRPC:

# ПОЛНЫЙ МИТИГЕЙШН — все шесть CVE мая 2026
# (если algif_aead, esp4/esp6, rxrpc не нужны):
printf "install algif_aead /bin/false\n\
install esp4 /bin/false\n\
install esp6 /bin/false\n\
install rxrpc /bin/false\n" | \
    tee /etc/modprobe.d/may2026-kernel-lpe.conf

rmmod algif_aead esp4 esp6 rxrpc 2>/dev/null || true

# Для CVE-2026-46333 (ptrace / SSH keys):
echo "kernel.yama.ptrace_scope = 1" >> \
    /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf

# Проверяем статус патчей на всём флоте:
# Нужны ядра: 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 6.1.173 / 5.15.207
uname -r

# ModuleJail — автоматизирует это для всех неиспользуемых модулей:
# github.com/jnuyens/modulejail
sudo sh modulejail -p conservative

Зачем это важно как тренд: DirtyDecrypt обнаружили независимо, а уязвимость уже исправили — это говорит о том, что AI-assisted code analysis находит одни и те же классы ошибок быстрее чем когда-либо. Темп раскрытий этого месяца — не случайность, это новая норма.

Итог: mitigation-файл + ptrace_scope = закрыты все шесть CVE мая. Патч ядра ставим при ближайшем обслуживании. И да — это ещё не конец месяца.

#linux #kernel #cve #dirtydecrypt #security #sysadmin #admin_future

🐧 Linux: Май 2026 закрыт — финальный чеклист по ядру для тех кто ещё не всё сделал

Коллеги, четверг 21 мая — подводим итог самому насыщенному security-месяцу в Linux за несколько лет. Шесть уязвимостей, все патчи вышли, но статистика показывает: большая часть флотов ещё не обновлена.

Это четвёртая уязвимость ядра Linux требующая внимания администраторов за три недели, после Copy Fail (29 апреля), Dirty Frag (7 мая) и Fragnesia (13 мая). Если вы не хотите экстренно патчить и перезагружать несколько раз в месяц — это сигнал выстроить систему.

Финальный чеклист на сегодня:

# ШАГ 1: Проверяем версию ядра — все патчи закрыты начиная с:
# 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 6.1.173 / 5.15.207 / 5.10.256
uname -r

# ШАГ 2: Если ядро не обновлено — ставим немедленно
# Ubuntu/Debian:
apt update && apt full-upgrade -y

# RHEL/Rocky/AlmaLinux:
dnf update kernel -y

# ШАГ 3: Mitigation-файл — закрывает все page-cache CVE даже без патча
cat /etc/modprobe.d/may2026-kernel-lpe.conf 2>/dev/null || \
printf "install algif_aead /bin/false\ninstall esp4 /bin/false\n\
install esp6 /bin/false\ninstall rxrpc /bin/false\n" | \
tee /etc/modprobe.d/may2026-kernel-lpe.conf

# ШАГ 4: ptrace_scope — закрывает CVE-2026-46333 (чтение SSH-ключей)
sysctl kernel.yama.ptrace_scope
# Если 0 — ставим минимум 1:
echo "kernel.yama.ptrace_scope = 1" >> /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf

# ШАГ 5: ModuleJail — системное решение для флота
# После патча и перезагрузки — автоматически блокирует ВСЕ
# неиспользуемые модули, не только эти шесть:
# github.com/jnuyens/modulejail
sudo sh modulejail -p conservative

# ШАГ 6: Проверяем что drop_caches сброшен на хостах
# где могла быть эксплуатация (критично для Fragnesia):
echo 1 | tee /proc/sys/vm/drop_caches

Один архитектурный вывод из мая: AI-assisted code analysis нашёл несколько уязвимостей в одной и той же поверхности атаки за три недели. Вопрос для 2026 года — не будут ли продолжаться kernel-эксплойты, а будет ли ваша инфраструктура защищена когда они появятся.

Итог: патч + перезагрузка + mitigation-файл + ptrace_scope. Четыре пункта. Если не сделано — сделай прямо сейчас, это последний четверг мая.

#linux #kernel #security #patch #sysadmin #admin_future

🐧 Linux: Rust теперь в APT — и это важнее чем кажется

Коллеги, на этой неделе случилось кое-что, о чём мало кто написал — но что касается каждого администратора Debian/Ubuntu-флота напрямую.

Два события мая 2026 окончательно переместили Rust из категории «языка будущего» в load-bearing инфраструктуру. Первое: Linux 7.0 убрал пометку experimental с Rust — теперь это официальный язык ядра наравне с C. Второе: APT maintainer Julian Klode объявил что Debian's package manager начинает требовать жёсткую зависимость от Rust начиная с мая 2026.

Что это значит практически для администратора:

APT — это package manager для Debian и каждого производного дистрибутива: Ubuntu, Linux Mint, Pop!_OS, Kali Linux, Raspberry Pi OS. Rust-компилятор, стандартная библиотека и части Sequoia PGP теперь встроены в core APT — для парсинга .deb, .ar и .tar файлов, а также HTTP signature verification.

Зачем Rust именно здесь? APT обрабатывает недоверенные данные (пакеты из интернета) на уровне root. Memory corruption в парсере пакетов — это immediate root compromise. Rust устраняет целые классы уязвимостей вроде use-after-free, которые типичны для C-кода. Это интеграция снижает реальную поверхность атаки в местах где это наиболее критично.

# Проверяем Rust в APT на Ubuntu 26.04:
apt-cache show apt | grep -i rust
dpkg -l | grep -i "rust\|rustc"

# Для администраторов air-gapped сред:
# APT теперь требует rustc при сборке из исходников
# Проверяем что offline-репозиторий включает rust-пакеты:
apt-get install --dry-run apt 2>&1 | grep -i rust

# Для Debian 13 Forky (выход 2027):
# Rust будет требоваться для сборки ядра модулей через DKMS
# Уже сейчас можно подготовить offline-кэш:
apt-get download rustc cargo libstd-rust-dev

# Смотрим версию Rust в системе:
rustc --version 2>/dev/null || echo "Rust not installed"
# На Ubuntu 26.04 должно быть 1.80+ из репозитория

Для администраторов air-gapped и закрытых сред — это практическое действие сейчас: убедись что твои offline-репозитории содержат rust-пакеты. После обновления APT на системах без сети это может сломать apt upgrade если Rust недоступен.

Итог: Rust перешёл из «интересно, но не моя проблема» в «часть базовой инфраструктуры моего дистрибутива». Пятница — хороший момент проверить offline-репы.

#linux #rust #debian #ubuntu #apt #security #sysadmin #admin_future

🐧 Linux: CVE-2026-46333 — Qualys опубликовала полный advisory. Ротируй SSH-ключи.

Коллеги, свежие подробности по уязвимости, которую разбирали на этой неделе. Qualys Threat Research Unit опубликовала полный технический advisory по CVE-2026-46333, и там есть детали которые меняют оценку риска.

TRU идентифицировала узкое окно в котором привилегированный процесс, сбрасывающий свои учётные данные, остаётся доступным через ptrace-операции даже когда флаг dumpable должен был закрыть этот путь. Комбинируя это окно с системным вызовом pidfd_getfd() (добавленным в ядро в январе 2020), атакующий может перехватить открытые файловые дескрипторы умирающего привилегированного процесса и унаследовать его доступ к файлам — включая приватные SSH-ключи хоста.

На хостах где в период уязвимости были непривилегированные пользователи — SSH host keys и локально кэшированные учётные данные следует считать потенциально раскрытыми. Qualys рекомендует ротировать host keys и проверить весь административный материал находившийся в памяти setuid-процессов.

# ШАГ 1: Патч уже есть — проверяем версию ядра
uname -r
# Патч в: 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 6.1.173 / 5.15.207
# Если старше — обновляем НЕМЕДЛЕННО:
apt update && apt full-upgrade -y && reboot   # Ubuntu/Debian
dnf update kernel -y && reboot                # RHEL/Rocky/AlmaLinux

# ШАГ 2: Была ли уязвимость активна? Смотрим были ли local users:
last | grep -v "^reboot\|^wtmp" | \
    awk '{print $1}' | sort -u
# Если только root — риск ниже. Если были другие — ротируем ключи.

# ШАГ 3: Ротация SSH host keys (если есть подозрение на компрометацию):
# Генерируем новые ключи:
rm /etc/ssh/ssh_host_*
ssh-keygen -A
# Перезапускаем SSH (NOT текущую сессию — откроем новую первой):
systemctl restart sshd

# Обновляем known_hosts на всех клиентах:
ssh-keyscan -H <server_ip> >> ~/.ssh/known_hosts

# ШАГ 4: Митигейшн если патч ещё не применён:
# ptrace_scope = 2 блокирует только root может ptrace непривилегированных
echo "kernel.yama.ptrace_scope = 2" >> /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# ptrace_scope = 3 — полный запрет (ломает отладчики, gdb, strace)

Также на неделе вышла PinTheft — отдельный LPE для Arch Linux систем. Если у тебя есть Arch в продакшне (надеюсь что нет) — смотри отдельный advisory.

Итог: если на хосте были local users в мае — ротируй SSH-ключи. Это 3 минуты работы и полное закрытие вектора постэксплуатации.

#linux #cve #ssh #security #kernel #sysadmin #admin_future

🐧 Linux: CVE-2026-46333 — Qualys опубликовала четыре рабочих эксплойта. Меняем shadow.

Коллеги, вчера Qualys опубликовала полный технический разбор CVE-2026-46333 с деталями которые меняют оценку риска. Это не просто "чтение SSH-ключей" — это четыре разных вектора атаки.

Qualys построила четыре рабочих эксплойта: через chage (раскрывает /etc/shadow), ssh-keysign (раскрывает приватные host-ключи в /etc/ssh/), pkexec (выполняет произвольные команды как root), accounts-daemon (выполняет произвольные команды как root). Все подтверждены на дефолтных установках Debian 13, Ubuntu 24.04, Ubuntu 26.04, Fedora 43 и Fedora 44.

Уязвимость важна потому что современные атаки редко останавливаются на первом плацдарме. RCE работающий как www-data, скомпрометированный CI-джоб, украденный аккаунт разработчика — изначально не root. Локальный баг ядра который читает root-секреты превращает этот плацдарм в кражу учётных данных, имперсонацию хоста или lateral movement.

# ПАТЧ ЕСТЬ — проверяем прямо сейчас:
uname -r
# Патч в коммите Линуса "ptrace: slightly saner get_dumpable() logic"
# Закрыт в: 7.0.8 / 6.18.31 / 6.12.89 / 6.6.139 / 5.15.207 / 5.10.256

# Обновляем если старее:
apt update && apt full-upgrade -y && reboot   # Ubuntu/Debian
dnf update kernel -y && reboot               # RHEL/Rocky/AlmaLinux

# ЕСЛИ НА ХОСТЕ БЫЛИ ЛОКАЛЬНЫЕ ПОЛЬЗОВАТЕЛИ В МАЕ:
# 1. Ротируем SSH host keys:
rm /etc/ssh/ssh_host_*_key /etc/ssh/ssh_host_*_key.pub
ssh-keygen -A
systemctl restart sshd

# 2. Ротируем пароли учёток из /etc/shadow:
# (shadow мог быть прочитан через chage-эксплойт)
# Минимум — все системные аккаунты с shell:
awk -F: '$7 !~ /nologin|false/ && $3 >= 1000 {print $1}' \
    /etc/passwd | while read u; do passwd --expire $u; done

# 3. Митигейшн если патч ещё не применён:
echo "kernel.yama.ptrace_scope = 2" >> \
    /etc/sysctl.d/99-ptrace.conf
sysctl -p /etc/sysctl.d/99-ptrace.conf
# ptrace_scope=2: только root может ptrace непривилегированных процессов

Зачем ротировать именно shadow и SSH-ключи: в shared-hosting среде разница между раскрытием учётных данных и прямым root-доступом практически отсутствует — любого из этих файлов атакующему достаточно чтобы пройти весь оставшийся путь.

Итог: патч + перезагрузка. Если были локальные пользователи в мае — SSH host keys и пароли из shadow считай скомпрометированными. Ротация — это 10 минут работы.

#linux #cve #ssh #kernel #security #sysadmin #admin_future

🐧 Linux: LKRG 1.0 — runtime-защита ядра вышла из experimental, и вот почему это важно сейчас

Коллеги, добрый понедельник и добро пожаловать в июнь. Май 2026 дал нам шесть уязвимостей ядра за три недели. Лучший момент поговорить об инструменте который менял бы картину для всех из них.

Linux Kernel Runtime Guard (LKRG) официально достиг версии 1.0 — переход от экспериментального проекта к production-ready инструменту. После нескольких лет разработки, тестирования и реального использования релиз 1.0 сигнализирует уверенность в стабильности и долгосрочном направлении.

Что делает LKRG: это loadable kernel module который мониторит целостность ядра в runtime. LKRG выполняет runtime integrity checking ядра Linux и детектирование эксплуатации уязвимостей безопасности против ядра. Это не патч ядра — модуль, который можно собрать для широкого спектра mainline и дистрибутивных ядер без их патчинга.

Если бы LKRG стоял на серверах в мае: он бы детектировал попытки page-cache write от Copy Fail/Dirty Frag/Fragnesia и реагировал — вплоть до kernel panic или kill процесса. Это не замена патчу, но дополнительный слой.

# УСТАНОВКА:

# Rocky/AlmaLinux/RHEL (через SIG Security):
dnf install epel-release
dnf install lkrg-dkms

# Debian/Ubuntu (через Kicksecure repo):
curl -fsSL https://www.kicksecure.com/keys/derivative.asc | \
    gpg --dearmor | tee /usr/share/keyrings/derivative.asc
echo "deb [signed-by=/usr/share/keyrings/derivative.asc] \
    https://deb.kicksecure.com bookworm main" | \
    tee /etc/apt/sources.list.d/lkrg.list
apt update && apt install lkrg

# Загружаем модуль:
modprobe lkrg
dmesg | grep -i lkrg | tail -5

# Проверяем статус:
sysctl lkrg.profile_enforce
# 0=monitoring, 1=detect+log, 2=balanced, 3=heavy, 4=paranoid

# ВАЖНО: начинаем с мониторинга, не с enforce:
sysctl -w lkrg.profile_enforce=1
# Смотрим логи несколько дней — ищем false positives:
journalctl -k | grep -i lkrg | tail -20

# После проверки — включаем защиту:
echo "lkrg.profile_enforce=2" >> /etc/sysctl.d/01-lkrg.conf

# Автозагрузка:
echo "lkrg" >> /etc/modules-load.d/lkrg.conf

Важные предупреждения: performance overhead есть — около 1.7% на Intel i7, 0.1% на Ryzen. Для production-серверов это приемлемо. Опция lkrg.block_modules блокирует загрузку новых модулей — не включать если система загружает модули динамически. Начинать с profile_enforce=0 или 1 и проверять false positives несколько дней.

Итог: после мая 2026 — LKRG в production это уже не паранойя. Это разумная defence-in-depth против целого класса атак. Ставь в лабу сегодня, в прод — после тестирования.

#linux #lkrg #kernel #security #hardening #sysadmin #admin_future

🐧 Linux: CVE-2026-23111 — один лишний символ в nftables даёт root. Эксплойт публичный.

Коллеги, добрый четверг. После майского марафона LPE казалось что можно выдохнуть. Не успели.

CVE-2026-23111 сидит в коде nf_tables packet-filtering ядра и был пропатчен upstream ещё 5 февраля 2026. Exodus Intelligence выпустили полный технический разбор 8 июня, и это не первый публичный эксплойт — FuzzingLabs опубликовал независимое воспроизведение ещё в апреле. Баг свёлся к единственному лишнему символу — инвертированной проверке в nf_tables — и upstream-фикс убрал его одной строкой.

Достижимая конфигурация типична: nftables плюс unprivileged user namespaces — Linux-фича которая позволяет обычному аккаунту действовать как root внутри приватной песочницы и достигать кода ядра который иначе был бы недоступен. Оба компонента включены по умолчанию на большинстве десктопов и многих серверных сборках. Удалённого вектора нет.

Ubuntu оценивает CVSS 7.8 (high). PoC публичен с апреля.

# ПРОВЕРКА — уязвимы ли вы:
uname -r
# Патч в ядрах 7.0.6 / 6.18.28 / 6.12.87 / 6.6.138 и новее
# Если ваша версия старее — уязвимы

# Митигейшн — отключаем unprivileged user namespaces:
# (ломает некоторые приложения типа Chrome/Chromium sandbox!)
sysctl kernel.unprivileged_userns_clone
# Если 1 — включено. Отключаем:
sysctl -w kernel.unprivileged_userns_clone=0
echo "kernel.unprivileged_userns_clone=0" >> \
    /etc/sysctl.d/99-userns.conf

# Альтернатива — AppArmor restriction (Ubuntu):
# Ограничиваем user namespaces без полного отключения:
sysctl -w kernel.apparmor_restrict_unprivileged_userns=1

# Проверяем используется ли user namespaces активными процессами:
find /proc/*/ns/user -type l 2>/dev/null | wc -l
# Если > 5-10 — что-то активно использует, отключение аккуратно

# ОБНОВЛЯЕМ ЯДРО:
apt update && apt full-upgrade -y && reboot   # Ubuntu/Debian
dnf update kernel -y && reboot               # RHEL/Rocky/AlmaLinux

Зачем это важно именно сейчас: публичный PoC означает что автоматизированные атаки уже возможны. Если на вашем сервере есть непривилегированные пользователи с shell-доступом — это активный риск прямо сейчас.

Итог: один символ в коде — root на твоём сервере. Ядро обновлено — проблемы нет. Не обновлено — mitigation через sysctl за 30 секунд.

#linux #kernel #nftables #cve #security #sysadmin #admin_future

🐧 Linux: Хватит терпеть зависания при OOM. Включаем PSI и systemd-oomd

Коллеги, добрый понедельник. Знакомая ситуация: на сервере потекла память, своп забился, load average улетел в космос, и вы даже по SSH зайти не можете. Классический OOM Killer в ядре срабатывает слишком поздно, когда система уже фактически в коме.

В 2026 году мы решаем это изящнее. Мы используем PSI (Pressure Stall Information) вместе с systemd-oomd. Этот демон убивает прожорливые cgroups ДО того, как операционная система намертво повиснет.

Скрипт для проверки и активации:

# Проверяем, включен ли PSI в ядре (вывод не должен быть пустым):
cat /proc/pressure/memory

# Если включен, активируем службу systemd-oomd:
systemctl enable --now systemd-oomd

# Смотрим статус и кто сейчас под угрозой:
oomctl status

Зачем это нужно:
Сервер должен оставаться управляемым при любых утечках памяти. Лучше пусть упадет один проблемный контейнер или веб-сервис, чем вся нода уйдет в hard reset по питанию, утащив за собой соседние процессы.

#linux #systemd #oom #performance #sysadmin #admin_future

🐧 Linux: Неделя 24 закрылась — Samba, OpenSSL и ядро требуют перезагрузки. Планируем окно.

Коллеги, добрый понедельник. После июньского рекордного хаоса на стороне Windows, в Linux-мире неделя прошла относительно спокойно — но «спокойно» не значит «можно игнорировать». Разбираем что прилетело.

Эта неделя принесла обновления ядра и core-сервисов для OpenSSL, Samba и Apache. Они почти наверняка потребуют полной перезагрузки, поэтому планируйте окно обслуживания вокруг активного продакшн-трафика. Samba-обновление имеет критический рейтинг, потому что непропатченные file-sharing сервисы исторически были самой лёгкой точкой входа для ransomware-кампаний.

И AlmaLinux, и Rocky Linux выкатывают тяжёлую пачку advisory затрагивающих ядро, BIND DNS, OpenSSL и Samba. Пропуск этих патчей оставляет сети широко открытыми для RCE и кражи данных.

Важное предупреждение по процессу: сисадмины наблюдали как продакшн-кластеры зависали после применения kernel-патчей без предварительной проверки совместимости out-of-tree модулей. .NET-обновления также раскатываются по нескольким версиям — любые backend-сервисы на этих runtime потребуют быстрого рестарта для подхвата криптографических улучшений.

# ПЕРЕД kernel-апдейтом — проверяем out-of-tree модули
# (то что зависало кластеры у других):
# Смотрим какие модули НЕ из mainline:
grep -h "" /sys/module/*/taint 2>/dev/null
# Или ищем проприетарные/внешние модули:
for mod in $(lsmod | awk 'NR>1{print $1}'); do
    modinfo "$mod" 2>/dev/null | grep -q "intree:Y" || echo "OUT-OF-TREE: $mod"
done
# Типичные виновники: nvidia, vmware, zfs, virtualbox, drbd

# Проверяем что DKMS пересоберёт их под новое ядро:
dkms status

# ПОРЯДОК БЕЗОПАСНОГО ОБНОВЛЕНИЯ:
# 1. Snapshot/backup перед апдейтом (LVM/ZFS snapshot)
# 2. Обновляем но НЕ перезагружаемся:
apt update && apt full-upgrade -y --no-install-recommends  # Debian/Ubuntu
dnf update -y                                              # RHEL/Rocky/Alma

# 3. Проверяем что DKMS-модули собрались под новое ядро:
dkms status | grep installed

# 4. Перезагружаемся в окно обслуживания:
reboot

# 5. ПОСЛЕ перезагрузки — проверяем критичные сервисы:
systemctl --failed
ss -tlnp  # слушают ли нужные порты
# Для Samba:
smbclient -L localhost -N 2>&1 | head
# Для .NET:
systemctl status <ваши-dotnet-сервисы>

Итог: неделя 24 — про дисциплину процесса, не про панику. Snapshot перед апдейтом, проверка DKMS, перезагрузка в окно, верификация сервисов после. Samba — приоритет, ransomware любит непропатченный SMB.

#linux #kernel #samba #patching #security #sysadmin #admin_future

🐧 Linux: CIFSwitch — баг 2007 года даёт root одной командой. PoC опубликован.

Коллеги, добрая среда. Шестой LPE в ядре Linux за 2026 год — и снова из той же серии что Copy Fail, Dirty Frag, Fragnesia и DirtyDecrypt. На этот раз код прятался 19 лет.

CIFSwitch (CVE-2026-46243) — локальное повышение привилегий в CIFS-подсистеме ядра Linux. Уязвимость присутствовала в коде с 2007 года — 19 лет необнаруженной. На затронутых системах любой непривилегированный локальный пользователь может получить root-shell одной командой.

Исследователь Asim Manizada раскрыл баг 28 мая 2026 с рабочим PoC на GitHub в тот же день. CVE присвоен 1 июня, пропатченные ядра дошли до production-репозиториев 2 июня.

Хорошая новость — условия эксплуатации узкие: баг находится в fs/smb/client/cifs_spnego.c — коде который обрабатывает Kerberos/SPNEGO-аутентификацию для CIFS-клиента ядра. Для эксплуатации нужны два условия: установлен cifs-utils И разрешены unprivileged user namespaces.

cifs-utils не входит в дефолтную установку большинства систем, и типичные shared-hosting серверы его не несут — такие хосты не уязвимы. Проверьте флот перед действиями.

# ШАГ 1 — Проверяем уязвимы ли мы:
# Установлен ли cifs-utils:
which mount.cifs cifs.upcall 2>/dev/null
dpkg -l cifs-utils 2>/dev/null || rpm -q cifs-utils 2>/dev/null
# Если НЕ установлен — вы НЕ уязвимы, можно выдохнуть

# Разрешены ли unprivileged user namespaces:
sysctl kernel.unprivileged_userns_clone 2>/dev/null   # Debian/Ubuntu
sysctl user.max_user_namespaces                       # RHEL/CentOS

# ШАГ 2 — Патч уже в production-репах с 2 июня:
uname -r
apt update && apt full-upgrade -y && reboot   # Debian/Ubuntu
dnf update kernel -y && reboot                # RHEL/Rocky/AlmaLinux

# ШАГ 3 — МИТИГЕЙШН без перезагрузки (если cifs не нужен):
echo "install cifs /bin/false" > /etc/modprobe.d/disable-cifs.conf
rmmod cifs 2>/dev/null
# ВНИМАНИЕ: ломает монтирование SMB/CIFS шар!

# Или удаляем cifs-utils если SMB не нужен:
apt remove cifs-utils    # Debian/Ubuntu
dnf remove cifs-utils    # RHEL/Rocky/AlmaLinux
# Без cifs-utils эксплуатация невозможна

# Или отключаем user namespaces (ломает контейнеры):
sysctl -w kernel.unprivileged_userns_clone=0  # Debian/Ubuntu
sysctl -w user.max_user_namespaces=0          # RHEL/CentOS

# ШАГ 4 — Мониторинг (multi-tenant/CI/CD):
# Следим за request_key() с необычными cifs.spnego ключами:
auditctl -a always,exit -F arch=b64 -S request_key -k cifs_spnego

Зачем это важно как тренд: 19-летний возраст уязвимого кода и наличие публичного PoC означают что эксплуатация в дикой природе вероятна. Организациям не стоит ждать подтверждённых атак перед применением митигейшна.

Итог: проверь установлен ли cifs-utils. Нет — не уязвим. Есть — патч (уже в репах) или удали cifs-utils если SMB не нужен. Шестой LPE за год — паттерн очевиден.

#linux #kernel #cifswitch #cve #security #sysadmin #admin_future