Admin Future

🐧 Linux: io_uring — самый быстрый и самый опасный интерфейс ввода-вывода в ядре

Коллеги, разговор о том, что активно идёт в production прямо сейчас, но о чём мало говорят в контексте безопасности. io_uring появился в ядре 5.1 в 2019 году как революция асинхронного I/O — два кольцевых буфера между ядром и userspace, работа без системных вызовов, минимальный overhead. PostgreSQL оценивает его интеграцию, Meta использует в production годами. Производительность реальная.

Проблема тоже реальная. В июне 2023 года команда безопасности Google сообщила, что 60% эксплойтов в их bug bounty программе за 2022 год были направлены против уязвимостей io_uring. Итог: io_uring отключён в Android, полностью отключён в ChromeOS и на серверах Google.

Ситуация улучшилась, но не исчезла. io_uring может обходить системные вызовы целиком — это означает, что инструменты безопасности, основанные на перехвате syscall (Falco, Tetragon в стандартной конфигурации, многие коммерческие EDR), слепы к операциям через io_uring. Rootkit, работающий через io_uring, будет невидим для большинства систем обнаружения.

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


# Проверяем, используют ли процессы io_uring прямо сейчас
# Смотрим открытые io_uring файловые дескрипторы
find /proc/*/fd -type l 2>/dev/null | xargs ls -la 2>/dev/null | grep anon_inode

# Более точно — смотрим через lsof
lsof | grep io_uring

# Проверяем, какие приложения слинкованы с liburing
ldd /usr/bin/postgres 2>/dev/null | grep uring
find /usr/bin /usr/sbin /opt -type f -name "*.so*" 2>/dev/null | \
  xargs grep -l "io_uring" 2>/dev/null | head -20

# ---- ОГРАНИЧЕНИЕ ДЛЯ КОНТЕЙНЕРОВ ----
# Запрет io_uring через seccomp (правильный способ для Docker/Podman)
cat > /etc/docker/seccomp-no-iouring.json << 'EOF'
{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["io_uring_setup", "io_uring_enter", "io_uring_register"],
      "action": "SCMP_ACT_ERRNO",
      "errnoRet": 38
    }
  ]
}
EOF

# Запускаем контейнер без io_uring
docker run --security-opt seccomp=/etc/docker/seccomp-no-iouring.json nginx

# ---- ДЛЯ systemd-сервисов ----
# В unit-файле — ограничение системных вызовов
# Добавляем в [Service]:
# SystemCallFilter=~io_uring_setup io_uring_enter io_uring_register

# ---- АУДИТ ----
# Если используете auditd — добавляем правила мониторинга io_uring
cat >> /etc/audit/rules.d/iouring.rules << 'EOF'
-a always,exit -F arch=b64 -S io_uring_setup -k iouring_activity
-a always,exit -F arch=b64 -S io_uring_enter -k iouring_activity
EOF
auditctl -R /etc/audit/rules.d/iouring.rules
# Смотрим активность:
ausearch -k iouring_activity | tail -20

Зачем это нужно:
Продакшн-системы на затронутых ядрах должны иметь мониторинг таймаутов сокетных операций и исчерпания ресурсов. Критические системы могут потребовать временного отключения некоторых функций io_uring до выхода патчей. Быть слепым к части I/O-активности в продакшне в 2026 году — это не технический нюанс, это дыра в модели угроз.

Итог: io_uring — это не плохая технология. Это мощный инструмент с расширенной поверхностью атаки. Как и у любого острого инструмента — важно знать, где он лежит и кто к нему имеет доступ.

#linux #iouring #security #kernel #sysadmin #admin_future

66 views05:30