ports:

- "127.0.0.1:5432:5432"

Docker будет слушать только на loopback, и порт останется доступным только с хоста.

Почему сканеры не помогут

Паттерн "5432:5432" без явного 127.0.0.1: - это слепое пятно для Trivy, Checkov, Semgrep и Snyk. Ни один из них не флагует такой биндинг как эксплойт, потому что это мисконфиг а не уязвимость. Рассчитывать на CI-сканеры в этом случае нельзя - проверять нужно глазами или кастомным правилом.

Вводная

Эмм с чего бы такого начать, чтобы не испугать раньше времени и не заставить устанавливать *BSD.

Есть на свете одна компания, которой мы помогаем с ИТ и есть у нее несколько виртуальных серверов на Ubuntu Linux, используемых для половых утех разработки и тестирования.

Ubuntu там использовалась нормальной (для сервера) LTS‑версии, но в какой‑то момент — в погоне за патчами безопасности ее обновили до текущей.

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

Все происходило летом 2025 года, поэтому речь про версию 25.04 Ubuntu Linux, которая использует ядро 6.14 (запомните этот важный момент):

Баг

Однажды сисадмин компании-заказчика заметил слишком частую и сильную нагрузку на CPU, создаваемую процессом snapd, который является частью пакетного менеджера Snap.

Эта проблема с перегрузкой CPU для snapd мягко говоря не нова — «проклятый snapd» гадил линуксоидам с момента своего появления на свет и вообще видимо был не придуман а ниспослан свыше, в качестве кары за грехи.

Но в этот раз 100% загрузка CPU происходила.. строго по расписанию:

Разумеется первым делом были опробованы стандартные методы решения, вроде снижения частоты проверок обновлений или полного отключения проклятого сервиса:

Отдельно порадовал ответ ИИ:

Дословно «снести и использовать что-то другое» — первый разумный совет от машины за всю историю развития искусственного интеллекта.

Дальнейшие изыскания привели в багтрекер snapd к упомянутому багу, где уже третий комментарий от разработчика snapd, с приложенной трассировкой вызовов показал что проблема именно в ядре:

Тут стоит добавить, что почти сразу встал вопрос проверки бага на локальной машине, поскольку на момент изучения ситуации локально все успело неоднократно обновиться, а отлаживать ядро Linux на сервере заказчика все же не очень хорошая затея.

Чуть ниже по переписке видно, что баг особо ярко проявляется на ноутбуке, работающем от батареи:

Так что решено было пробовать отловить именно в таких условиях.

На счастье, на машине осталась сборка 6.14 версии ядра с патчами от Xanmod, которая использовалась для статьи про l9ec.

В последние годы в проекте ядра Linux выпускается сильно много промежуточных релизов, поэтому на какой именно версии внутри 6.14 ветки что-то пошло не так еще пришлось выяснять:

Наконец источник проблем был найден:

Чуть ниже по переписке обнаружился и тестовый код на C, демонстрирующий проблему, вот такой:

#include <sys/epoll.h>
#include <sys/time.h>
#include <sys/wait.h>

int main() {
int e = epoll_create1(0);
struct epoll_event event = {.events = EPOLLIN};
epoll_ctl(e, EPOLL_CTL_ADD, 0, &event);
const struct timespec timeout = {.tv_nsec = 1};
epoll_pwait2(e, &event, 1, &timeout, 0);
}

А так это выглядит в действии:

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

Патч целиком находится тут, место исправления выглядит как-то так:

Да, как видите ситуацию радикально исправляет буквально пара символов логической конструкции, главное знать где исправлять.

Текущее состояние

Формально проблема была решена еще летом этого года, патч попал в mainline и пакет с обновлением ядра от команды Ubuntu:

На осень 2025 года даже стабильная версия ядра Linux уже имеет версию 6.16 — т. е. паровоз разработки уехал очень далеко вперед от описываемых проблем:

Так что на момент написания данной статьи вы (по идее) не должны столкнуться с данной проблемой, а если и столкнетесь — все легко решается банальным обновлением версии ядра из пакетов дистрибутива.

При подозрении на описанный баг — попробуйте собрать тестовое приложение (см. выше) и запустить в своем окружении.

Если начнется 100% загрузка CPU запущенным процессом — проблема точно есть, поскольку в ядрах с патчем поведение тестового приложения отличается:

Что касается заказчика, поскольку решение а затем и патч были опубликованы довольно оперативно — раньше чем нам сообщили о проблеме, на время разборок с согласованиями и попаданием в mainline ядра, мы банальным образом перенесли патч вручную в ту версию ядра, которая использовалась на сервере.

Позже обновили уже штатными средствами дистрибутива до текущей актуальной версии.

Эпилог

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

1. Linux — могила, *BSD - сила

Шучу, разумеется неподготовленным пользователям в BSD-системы лучше не лезть совсем, но задуматься (или хотя-бы просто знать) о реалиях функционирования Linux все же стоит. Чтобы факт выноса мозга ядру из прикладного ПО не стал для вас неприятным сюрпризом.

2. Граница между прикладкой и системной разработкой весьма абстрактна

Проще говоря — ее нет совсем и в любой произвольный момент времени у вас есть неиллюзорный шанс наткнуться на баг ядра, даже программируя на JavaScript в браузере.

3. Любой уважающий себя сисадмин и DevOps должны знать С

Пусть на самом примитивном уровне, но хотя-бы собрать и запустить тестовое приложение, демонстрирующее проблему надо уметь. К сожалению все глубокие изыскания по теме «где оно тормозит» или «почему оно упало» рано или поздно приводят к коду на С и отладчику ядра.

И поверьте моему печальному опыту:

изучать эти штуки лучше днем и в спокойной обстановке, а не в режиме аврала и поздно ночью на работе в выходной день.

4. Считайте деньги, хотя-бы иногда

Описанная в статье проблема случилась в локализованном окружении (на собственных физических серверах компании), но точно такая же Ubuntu используется и облачными провайдерами вроде Amazon, где есть тарификация за использование ресурсов, в первую очередь CPU.

Как нетрудно догадаться, 100% загрузка процессора с интервалом в пять минут в облаке, если ее вовремя не заметить и не исправить — больно отразится на счете, который вам потом выставят.

Так что проверяйте загруженность, пиковых 100% в современных системах быть не должно, если только вы целенаправленно не занимаетесь вычислительными задачами.

P.S.

Статья была опубликована на Хабре, более вольный оригинал как обычно в нашем блоге, копия статьи — в Яндекс Дзене.

Все это — чтобы показать, насколько яркими и живыми могут быть цвета, как выглядит глубокий черный и на что способна встроенная акустика. Над экранами разместили большие художественные полотна, которые продолжали происходящее на дисплеях.

Новые модели от Hisense

На презентации продемонстрировали несколько моделей новой линейки — UR8S, UR9S и флагманский Hisense 116UX.

Особенность новинок — технология RGB MiniLED. Теперь телевизор точнее управляет цветом и светом, поэтому изображение выглядит ярче, контрастнее и естественнее.

Менеджер по продуктам ТВ- и аудиокатегории Hisense Шон Ли:

«Запуск технологии RGB Mini-LED на российском рынке является новым этапом в развитии Hisense. Мы задали новый стандарт визуального опыта, который уже получил признание на глобальном уровне».

Больше всего внимания собрал Hisense 116UX. Это телевизор с трехметровой диагональю. На таком экране особенно хорошо заметны детали: яркие сцены остаются насыщенными, темные — глубокими, а изображение выглядит объемным и живым. За качество картинки отвечает фирменный процессор Hisense, а встроенная многоканальная акустика создает эффект домашнего кинотеатра без дополнительных колонок.

Вместо лекций — живое общение

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

Организаторы отказались и от длинных технических презентаций. Гости переходили между зонами, сравнивали модели, задавали вопросы специалистам и тестировали телевизоры в удобном для себя темпе.

Линейка уже поступила в продажу. Доступны модели UR8S в нескольких размерах экрана, серия UR9S и флагманский 116UX. Телевизоры можно приобрести у крупных российских ритейлеров и на популярных маркетплейсах.

• Запретить запись в чувствительные пути хоста, даже если внутри контейнера процесс запущен от root.

• Ограничить разрешенные системные вызовы и операции с файлами сверх того, что предоставляет рантайм.

• Выдавать вам понятные человеку логи, когда что-то пытается выбраться из своей «песочницы».

В Ubuntu AppArmor включен по умолчанию, а в Debian и Arch его активация - дело пары пустяков.

Генерируем первый профиль

Для начала установим инструменты (пример для Debian/Ubuntu):

sudo apt update && sudo apt install apparmor apparmor-utils apparmor-profiles

Переведем целевое приложение в режим обучения (complain mode), чтобы понаблюдать за его реальным поведением:

sudo aa-genprof podman # или docker, или имя вашего бинарника

Утилита aa-genprof запускает программу в режиме обучения и следит за логами. Теперь запустите ваш контейнер в обычном рабочем режиме:

podman run --rm -it nginx:alpine sh

Погоняйте контейнер в хвост и в гриву (поустанавливайте пакеты, позаписывайте файлы и т.д.). Затем выйдете из него и позвольте утилите aa-logprof провести вас по процессу создания правил.

Минимальный готовый профиль (/etc/apparmor.d/podman-nginx) может выглядеть примерно так:

#include <tunables/global>

profile podman-nginx flags=(attach_disconnected,mediate_deleted) {

#include <abstractions/base>

#include <abstractions/nameservice>

capability net_bind_service,

capability setuid,

capability setgid,

network inet stream,

network inet6 stream,

/var/log/nginx/** rw,

/var/cache/nginx/** rw,

/etc/nginx/** r,

/usr/share/nginx/** r,

# Запрещаем доступ на запись к большей части /proc и /sys по умолчанию

deny /proc/** w,

deny /sys/** w,

# Разрешаем только конкретное чтение при необходимости

/proc/cpuinfo r,

/proc/meminfo r,

# Бинарник вашего приложения и библиотеки

/usr/sbin/nginx mr,

/usr/lib/nginx/** mr,

# Обработка сигналов

signal (receive) set=term,

# Запрещаем всё остальное по умолчанию

deny /** wl,

}

Инструмент aa-logprof шаг за шагом проведет вас по каждому залогированному событию и позволит выбрать: разрешить его, запретить или проигнорировать.

Принудительное применение профиля в Podman

У Podman отличная интеграция с AppArmor. Запустите контейнер следующим образом:

podman run --security-opt apparmor=podman-nginx -p 8080:80 nginx:alpine

Убедитесь, что профиль действительно загружен:

sudo aa-status | grep podman-nginx

Вы должны увидеть его в режиме enforce (принудительное исполнение).

Для Docker (если вы всё еще его используете):

docker run --security-opt apparmor=podman-nginx nginx:alpine

Отладка и итерация

Если что-то ломается, проверьте логи ядра:

sudo dmesg | grep apparmor

# или

sudo journalctl -xe | grep apparmor

Затем снова воспользуйтесь интерактивным профилировщиком:

sudo aa-logprof

Он покажет, какого именно правила не хватало. Типичный сценарий: нужно добавить конкретный путь вида /run/… или /tmp/…, который легитимно требуется вашему приложению.

В продакшене вы можете временно переключить профиль в режим обучения (complain):

sudo aa-complain /etc/apparmor.d/podman-nginx

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

sudo aa-enforce /etc/apparmor.d/podman-nginx

С чего начать изучение

• Запускайте каждый новый образ контейнера с автоматически сгенерированным профилем в режиме обучения (complain) на протяжении недели.

• Храните профили в Git рядом с вашими манифестами развертывания.

• Сочетайте это с флагом --cap-drop=ALL и строгим профилем seccomp для эшелонированной защиты.

• Периодически используйте утилиту aa-unconfined, чтобы находить процессы, которые работают без ограничений.

Что почитать по теме

• Документация Ubuntu по AppArmor: https://ubuntu.com/server/docs/how-to/security/apparmor/

• Страница AppArmor на Arch Wiki (отличные примеры): https://wiki.archlinux.org/title/AppArmor

• Параметры безопасности Podman: man podman-run (ищите по ключевому слову apparmor)

• Man-страницы для aa-genprof(8), aa-logprof(8) и apparmor(7)

Профили AppArmor относятся к той категории инструментов, которые настраиваются один раз и довольно долго не меняются (если конечно хорошо к этому подойти в первый раз). Первоначальные вложения времени в изучение aa-logprof окупятся в первый же раз, когда вы поймаете контейнер на попытке сделать то, чего он делать не должен.

Если вы уже гоняете Podman или Docker в продакшене без кастомных профилей AppArmor, то это одно из самых высокодоходных (с точки зрения ROI) улучшений безопасности, которые вы можете сделать на этой неделе. Начните с одного критически важного сервиса и двигайтесь дальше.