Demo
Demo
База знаний PMTA›Процедура§ 1.6.3

Закрыть права на файлы конфигурации

Protecting sensitive information
Конфигурация — это хранилище секретов

Руководство отводит этому отдельный раздел, и не зря: в файлах конфигурации PowerMTA лежат пароли подачи, ключи API и закрытые ключи подписи DKIM — открытым текстом. Иначе MTA их не примет.

Основных файлов два: config с самой настройкой и config-defaults с умолчаниями. Но защищать надо не только их: главный файл может подключать другие строкой include, и руководство называет их прямо — «в них тоже бывает чувствительное», особенно там, где лежат ключи подписи.

Команды даны буквально: владелец pmta:pmta, права 640. Владелец важен не меньше прав: MTA работает от пользователя pmta и должен свою конфигурацию прочитать. Файл с правами 640 и владельцем root не прочитает никто, кроме root, — включая сам MTA.

Секреты можно вынести из файла. Руководство предлагает хранить ключи подписи в Vault и ссылаться на них из конфигурации (vault-support); тогда в файле остаётся ссылка, а не сам ключ.

Главная ловушка — защитить главный файл и забыть подключённые. Строка include вклеивает содержимое другого файла, и у нас на ней держится вся раскладка: блоки адресов отправки с ключами подписи лежат отдельным файлом. Права 640 на главном при 644 на подключённом не защищают ничего — секреты как раз во втором. То же с каталогом ключей: закрытый ключ с правильными правами в каталоге, открытом на чтение, доступен по имени.
Что делает Хаб. Ставит права сам, при каждой доставке файла, и строже, чем требует руководство: главному файлу и файлу адресов — владельца pmta:pmta и права 640; файлу с токеном приёма телеметрии — 600, его читает только MTA; сертификату для подачи по TLS — владельца каталога и 600; каталогу ключей подписи — 700, а самим ключам внутри — 600.

Оператору делать нечего: файлы кладёт Хаб, и права на них — его ответственность, а не операторская.

⚠️ Одна тонкость в нашем коде. Смена владельца выполняется с заглушённой ошибкой, а права ставятся следом безусловно. Если на узле нет пользователя pmta — например, MTA ещё не установлен, — файл получит права 640 и владельца root, и MTA его потом не прочитает. Проявится это не при доставке, а при первом запуске.

Рекомендуемые значения

Что должно получиться на узле:

Путь Владелец Права
главный файл конфигурации pmta:pmta 640
файл с блоками адресов pmta:pmta 640
каталог ключей подписи владелец каталога MTA 700
закрытые ключи внутри тот же 600
файл с токеном телеметрии pmta:pmta 600

Права 640 — это минимум из руководства, а не потолок. Всё, что читает только сам MTA и не нужно его группе, спокойно живёт с 600. Разница существенна там, где на узле есть другие службы в той же группе.

На Windows порядок другой: владельцем ставится системная учётная запись, а группе пользователей чтение и запись запрещаются.

Таблица прав и совет про более строгие права — из практики Хаба. Из руководства здесь состав секретов в файле, команды для Linux и Windows, требование распространить их на подключённые файлы и предложение вынести ключи в Vault.
Пример в конфигурации
# права ставятся всей связке, а не одному файлу
chown pmta:pmta /etc/pmta/config /etc/pmta/config-defaults
chmod 640       /etc/pmta/config /etc/pmta/config-defaults
chown pmta:pmta /etc/pmta/virtualhost.txt && chmod 640 /etc/pmta/virtualhost.txtchmod 700       /etc/pmta/dkim && chmod 600 /etc/pmta/dkim/*
Выделенная строка — про подключённый файл, тот самый, где лежат блоки адресов отправки с ключами подписи. Забыть его проще всего, а секретов в нём больше, чем в главном.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается3 ошибки▶

Защищают главный файл, оставляя подключённые открытыми

§ 1.6.3

Чем чреватоРуководство называет подключённые файлы отдельно: в них лежат закрытые ключи подписи. У нас в подключённом файле — все блоки адресов отправки, то есть больше секретов, чем в главном. Защита главного при открытом подключённом не защищает ничего.
Как заметитьУ главного файла права 640, у файла с блоками адресов — 644 или владелец root.
Как правильноСтавить права всей связке разом, включая каталог ключей. Находить подключённые файлы поиском строки подключения, а не по памяти.

Ставят права, не проверив владельца

§ 1.6.3

Чем чреватоПрава 640 без владельца pmta означают, что файл не читает никто, кроме root, — MTA в том числе. Конфигурация выглядит защищённой, а узел не стартует.
Как заметитьПосле правки прав MTA не запускается либо запускается с прежней конфигурацией; в журнале запуска отказ по доступу.
Как правильноМенять владельца и права одной командой и проверять результат разбором конфигурации, а не просмотром списка файлов.

Закрывают ключи, оставляя открытым их каталог

§ 1.6.3

Чем чреватоПрава на каталог решают, можно ли увидеть в нём имена файлов. Закрытый ключ с правами 600 в каталоге с правами 755 виден по имени, а имя ключа обычно содержит домен — то есть выдаёт список доменов, которыми узел подписывает.
Как заметитьУ каталога ключей права 755, у файлов внутри 600.
Как правильноЗакрывать каталог целиком правами 700. Это ровно то, что Хаб делает при выпуске ключей.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
⇄

Связанные записи

2 связи

Чем можно заменить

Внешнее хранилище секретовСпособ убрать ключи из файла вовсе — оставить в конфигурации ссылку, а не сам ключ. § 1.6.3

Где применяется

Главный файл конфигурации узлаТот самый файл, о правах на который речь: пароли и ключи лежат в нём открытым текстом. § 1.6.3

Сюда ссылаются

Ограничить, кто вообще достаёт до узлаЗдесь доступ по сети, там права на файлы. Нужны оба или ни одного. § 1.6.3Файл лицензииКлючевой материал в каталоге конфигурации — права на него такие же. § 1.6.3volume-audit-api-keyGlobalКлюч лежит в конфигурации открытым текстом; защищают его права на файл. § 1.6.3includeGlobalПодключаемые файлы — часть конфигурации, и права на них должны быть такими же. § 1.6.3http-api-keyGlobalКлюч лежит в файле открытым текстом, поэтому права на файл значат столько же, сколько сам ключ. § 1.6.3log-file-world-readableGlobalТот же вопрос о правах, что и у файла конфигурации: журнал с подробностями хранит не меньше. § 1.6.3

Как проверить на узле
Проверять надо и права, и то, что MTA после правки читает свою конфигурацию:
ls -l /etc/pmta/config /etc/pmta/config-defaults /etc/pmta/virtualhost.txt
ls -ld /etc/pmta/dkim && ls -l /etc/pmta/dkim/
pmta test config
Ожидается pmta:pmta и 640 у файлов конфигурации, 700 у каталога ключей и 600 внутри него. Третья команда важна не меньше: право чтения проверяется не глазами, а тем, что MTA разобрал файл.
◇

Что ещё почитать

3 статьи

◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Группа, дающая право управлятьЧленство в группе pmta даёт непривилегированному пользователю право звать команды узла и пользоваться подачей.◇Как узел выбирает источник и складывает его настройкиСоединение попадает под все блоки источника, чьи адреса его накрывают, и действуют они слитно — узкий перекрывает широкий; именованные блоки подключаются только по прямой ссылке.

В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Безопасность узла