52.2 root'овые привилегии

   На бинарник exim'a, обычно, установлен бит setuid на root'a, что означает, что в начале выполнения он получает root'овые привилегии (работает от root). В некоторых специальных случаях (например, когда не используется даемон, и нет локальных доставок), возможно запускать exim с setuid на иного пользователя, чем root. Это обсуждается в следующей секции. Однако, в большинстве инсталляций, root'овые привилегии требуются по двум причинам:


52.3 Работа exim без привилегий

   Некоторые инсталляции любят запускать exim под непривилигированным пользователем, для дополнительной безопасности. Поддержка для этого режима предоставляется путём глобальной опции “deliver_drop_privilege”. Когда она установлена, uid и gid изменяются на пользователя и группу exim'a в начале процесса доставки (и, также, обработчик очереди и процесс тетстирования адресов). Это означает, что роутинг адресов не работает от root'a, и сами доставки не могут измениться на иной uid.
   Оставление на бинарнике setuid на root'a, но установка “deliver_drop_privilege” означает, что даемон всё ещё может запуститься обычным способом, и он может корректно ответить на SIGHUP, поскольку перевызов восстанавливает привилегии root'a.
   Альтернативный подход состоит в том, чтобы сделать exim setuid на пользователя exim'a, и, также, сделать его setgid на группу exim'a. Если вы сделаете это, даемон должен запускаться с root'овыми правами. (Вызов exim'a из процесса root'a заставляет его вести себя так, как он себя ведёт когда setuid на root.) Однако, даемон не может перезапуститься после сигнала SIGHUP, поскольку он не может восстановить привилегии.
   В этом случае, всё ещё полезно установить “deliver_drop_privilege”, поскольку это помещает exim'y повторно перевызвать самого себя, для проведения доставки после получения сообщения. Такой перевызов - растрата ресурсов, поскольку он не имеет эффекта.
   Если перезапуск даемона - не проблема (например, если установлен “mua_wrapper”, или вместо даемона используется “inetd”), обладание бинарником setuid на пользователя exim кажется совершенным подходом, но есть одно осложнение:
   В этом стиле действия, exim работает с реальным uid и gid, установленным к тем же что и увызывающего процесса, и эффективный uid/gid установлен в значения exim'a. Идеально, любая ассоцииация с uid/gid вызывающего процесса должан быть отброшена, т.е. реальный uid/gid должен быть сброшен в эффективные значения, чтобы отказаться от любых привилегий, которые мог иметь вызывавший. Некоторые операционные системы обладают функцией, которая разрешает это действие для не-root'ового эффективного uid, но многие её не имеют. Из-аз этой недостаточной стандартизации, exim не обращается к этой проблеме в настоящее время.
   Поэтому, рекомендованный подход для “совсем непривелигированного” запуска состоит в том, чтобы оставить бинарник exim'a setuid на root, и установить “deliver_drop_privilege”. Это, также, имеет преимущество - разрешение работы даемона прямым способом.
   Если вы конфигурируете exim не начинать процесс доставки от root'a, есть множество ограничений на то, что вы можете сделать:


52.4 Доставка в локальные файлы

   Полная детализация проверок применяемых путём “appendfile” до записи в файл даны в главе 26.



52.5 Источник роутинга IPv4

   Много операционных систем подавляют пакеты IP маршрутизации источника в ядре, но некоторые не делают этого, таким образом, exim производит свою собственную проверку. Он логгирует входящие вызовы TCP маршрутизации источника IPv4, и, затем, обрывает их. Это отличается от IPv6. В настоящее время, никакой специальной проверки не делается.



52.6 Команды VRFY, EXPN, и ETRN в SMTP

   Поддержка этих SMTP команд по умолчанию отключена. Если требуется, они могут быть включены путём задания подходящих ACL.



52.7 Привелигированные пользователи

   Exim распознаёт два набора пользователей со специальными привилегиями. Доверенные пользователи имеют возможность локально посылать новые сообщения exim'y, подставляя их собственные адреса отправителя и информацию о хосте отсылки. Для других пользователей посылающих локальные сообщения, exim устанавливает адрес отправителя из uid, и не позволяет задавать удалённый хост.
   Однако, недоверенным пользователям разрешено использовать опцию командной строки “-f”, в специальной форме “-f <>”, для индикации, что неудача доставки не должна вызвать отчёт о ошибке. Это затрагивает конверт сообщения, но не затрагивает заголовок “Sender:”. Недоверенным пользователям также может быть разрешено использовать специфическую форму адресов с опцией “-f”, путём установки опции “untrusted_set_sender”.
   Доверенные пользователи используются для запуска процессов которые получают почтовые сообщения с одних почтовых доменов и передают их exim'y для их локальной доставки, или через интернет. Exim доверяет вызывающему работающему от root'a, от пользователя exim'a, или под любым пользователем перечисленным в конфигурационной опции “trusted_users”, или под любой группой перечисленной в опции “trusted_groups”.
   Административным пользователям разрешено производить действия над сообщениями в очереди exim'a. Они могут замораживать или оттаивать сообщения, вызывать их возвращение к их отправителю, полностью удалять их, или модифицировать их различными способами. Дополнительно, административные пользователи могут запускать монитор exim'a и видеть всю информацию которую он может предоставить, включая содержимое файлов спула.
   По умолчанию, использование опций “-M” и “-q”, вызывающих exim для попытки доставить сообщения в его очереди, ограничено административными пользователями. Это ограничение может быть ослаблено путём установки опции “no_prod_requires_admin”. Точно также, использование “-bp” (и её вариантов) для получения списка содержимого очереди, также ограничено административными пользователями. Это ограничение может быть ослаблено путём установки опции “no_queue_list_requires_admin”.
   Exim распознаёт административного пользователя если вызывающий процесс запущен как root или как пользователь exim'a, или любая группа ассоциированная с процессом  - группа exim'a. Нет необходимости фактически работать от группы exim'a. Однако, если административные пользователи не являющиеся root'ом или пользователем exim'a должны получить доступ к содержимому файлов spool`a через монитр exim'a (который работает непривелигированным), exim должен быть собран с разрешением группе доступа на чтение к его файлам спула.



52.8 Файлы спула

   Директория спула exim'a, и всё что она содержит, принадлежит пользователю exim'a и его группе. Режим файлов спула задаётся в конфигурационном файле “Local/Makefile”, и по умолчанию - 0640. Это означает, что любой, кто является пользователем группы exim'a может получить доступ к этим файлам.



52.9 Использование “argv[0]”

   Exim проверяет последний компонент “argv[0]”, и если он совпадает с одной из установленных специфических строк, exim предполагает определённые опции. Например, вызов exim с последним компоненом “argv[0]” установленным в “rsmtp” - точный эквивалент его вызова с опцией “-bS”. Никаких значенией безопасности в этом нет.



52.10 Использование форматирования “%f”

   Единственное использование сделанное exim'ом с использованием “%f” - форматирование значений средней загрузки. Фактически они сохранены в цифровых переменных как 1000 времён средней загрузки. Следовательно, их диапазон ограничен, и поэтому - это длина конвертированного вывода.



52.11 Встроенные пути exim'a

   Exim использует своё собственное имя пути, которое встроенно в код, лишь когда ему необходимо перезапуститься для восстановления root'овых привилегий. Поэтому, он не работает от root'a, когда это делает. Если бы какая-то ошибка позволила перезадать путь, это привело бы к запуску произвольной программы от root'a, а не exim'a.



52.12 Использование “sprintf()”

   Большое количество “sprintf” в коде - фактические вызовы “string_sprintf()”, функции которая возвращает результат сохранения malloc. Промежуточное форматирование сделано в большой фиксированный буфер, путём функции которая запускается через непосредственное форматирование строки, и проверки длинны каждого преобразования до его выполнения, что предотвращает переполнение буфера.
   Оставшиеся использования “sprintf()” происходят при контролируемых обстоятельствах, где выходной буфер заведобо достаточной длинны, чтобы содержать конвертированную строку.



52.13 Использование “debug_printf()” и “log_write()”

   Обоим этим функциям передаются произвольные строки, но они производят их форматирование путём вызова функции “string_vformat()”, которая непосредственно обрабатывает форматируемую строку, и проверяет длину каждого преобразования.



52.14 Использование “debug_printf()” и “log_write()”

Они используются лишь когда известно, что выходной буфер достаточно большой для хранения результата.


=============
translated by lissyara
verifying by Gerk