Кратко

  • В модели Postfix с привилегированным master большинство служб сначала открывает нужные файлы, а затем навсегда отказывается от root до обработки запросов; четыре службы доставки сохраняют действующий идентификатор root для ограниченных задач.
  • Непривилегированный master снижает права надзирающего процесса, но ослабляет внутреннее разделение, расширяет доступ к ключам и журналам при взломе службы и разрешён для производства лишь в ограниченном наборе конфигураций.

Вопрос «работает ли почтовый сервер от root?» плохо показывает, где именно находится риск. Архитектура Postfix подсказывает более точные вопросы: какому процессу нужны какие права, на каком этапе запроса и к каким файлам или ресурсам других пользователей?

Сообщение, поступившее по SMTP или QMQP, сначала попадает в сетевую службу Postfix. Она проверяет входные данные и передаёт конверт и содержимое в cleanup(8). Этот этап выполняет последнюю обработку перед постановкой в очередь, записывает сообщение во входящую очередь и уведомляет qmgr(8). Затем диспетчер очереди выбирает агенты доставки. Активная очередь ограничена по размеру, поэтому крупный backlog не заставляет процесс сразу открывать все ожидающие сообщения. Постоянно работающий master(8) наблюдает за службами, запускает их по запросу и соблюдает заданные пределы числа процессов.

У надзирающего процесса и служб, обрабатывающих запросы, разные функции. В модели Postfix с привилегированным master служба может запуститься с правами root, открыть чувствительные файлы — например, закрытые TLS-ключи или пароли баз данных — и затем без возможности возврата отказаться от root до обработки запросов. В актуальной документации по безопасности сказано, что после этого взломанная служба уже не сможет открыть такие файлы, базы данных или журналы. Значит, root участвует в инициализации и назначении прав, но не обязательно остаётся у каждого сетевого процесса на весь срок работы.

Есть исключения. Большинство служб отказывается от root окончательно, однако local(8), pipe(8), spawn(8) и virtual(8) сохраняют действующий идентификатор root. Он нужен, чтобы действовать от имени целевого пользователя или обращаться к ресурсам за пределами Postfix, например к почтовому ящику или внешней команде. Postfix различает две функции: разделение прав между собственными службами и ограничение доступа, когда служба обращается к пользовательским файлам или внешним программам. Общее выражение «процесс root» скрывает эту разницу.

На выступлении LISA в 2010 году Wietse Venema описал Postfix как разделённую архитектуру с минимальными привилегиями. Среди источников он назвал проект межсетевого экрана, где приём и доставка почты разделялись низкопривилегированными процессами в chroot. Он также объяснял, что небольшие программы легче сопровождать после построения коммуникационной инфраструктуры. Это историческое объяснение замысла автором, а не нынешнее число служб Postfix и не измерение результатов безопасности. В актуальной документации описано, как отдельно работают приём, подготовка, управление очередями и доставка.

Недавнее изменение не означает, что удаление root у надзирающего процесса автоматически повышает безопасность всей системы. Согласно документации Postfix, в 2025 году Venema сначала реализовал непривилегированный master(8) для неопубликованных интеграционных тестов. После запроса заказчика в 2026 году он доработал его для ограниченного применения в производстве и добавил документацию. В этом режиме master работает под фиксированной учётной записью postfix, а не root. Службы используют одинаковые привилегии Postfix и при инициализации, и при обработке запросов. Проект предупреждает, что это не позволяет сохранить внутреннее разделение привилегий или обычные ограничения при доступе к внешним файлам, почтовым ящикам и внешним командам.

Это отражается на разрешениях файлов. Закрытые ключи Postfix должны читаться пользователем postfix, поэтому взломанная служба может получить к ним доступ. Необязательные журналы Postfix должны принадлежать postfix; служба после компрометации может их читать, изменять или удалять. Файлы конфигурации, напротив, не должны принадлежать этому пользователю. При нескольких экземплярах все должны работать с привилегированным master либо все с непривилегированным: совмещать режимы нельзя.

Производственное применение ограничено. Postfix разрешает непривилегированный master для конфигураций, где все сообщения пересылаются через SMTP или LMTP. Документация запрещает такой режим в производстве, если локальные службы могут запускать программы, не относящиеся к Postfix, или доставлять сообщения в файлы почтовых ящиков. В числе рисков указан сценарий с командой из файла .forward: она выполнялась бы с правами postfix, а не целевого пользователя, и могла бы дать пользователю возможность управлять почтовой системой. Предупреждение относится к конкретной конфигурации и сформулировано прямо.

Архитектурный вывод не в том, что root безопасен или опасен сам по себе. Смена прав перемещает риск между границами. Непривилегированный master может подойти ограниченному SMTP/LMTP-реле, но его службы разделяют доступ к ключам и журналам, которые привилегированная модель способна отгородить после инициализации и отказа от root. Перед сменой идентификатора master операторам следует описать пути доставки и проверить, соответствует ли режим файлам и командам, доступным каждой службе. Открытая документация определяет условия выбора, но не сообщает, какой режим распространённее и каковы результаты его применения в реальных установках.

Источники