Безопасность: Linux - Postfix / dovecot - Roundcube - разрешения unix для пользователя почты
История вопроса:
Я использую рабочий почтовый сервер с postfix / dovecot на debian buster как в этом руководстве .Как и в руководстве, я установил roundcube на фронтенд.
В последней главе руководства обсуждается шифрование, и если вы последуете ему, вы получите шифрование для каждого пользователя (в dovecot'sh это называется «папка encr.» В отличие от «global encr.» ).
Это аккуратная установка, и я очень доволен всем, кроме одного момента:
Что меня беспокоит:
После того, как пользователь изменит свой пароль, администратор должен будет войти на сервер и также измените ключ шифрования (поскольку плагин mail_crypt настроен на использование пароля пользователя ... да).
У этого есть два недостатка: во-первых, очевидная часть «кто-то должен вручную войти в систему на удаленном компьютере для выполнения команды», что может немного раздражать растущую базу пользователей. Во-вторых, это беспокоит меня из точки зрения безопасности. - должен ли админ знать старый и новый пароли пользователя. Имхо это запрещено.
Уровень моей техники:
Каким бы я ни был умен, я создал крошечный небольшой плагин поверх плагина пароля, который должен запускаться при изменении пароля. Затем он запускает команду doveadm для настройки криптографических ключей.
Пока все хорошо ...
Очевидно, roundcube (и, следовательно, плагин) работает с другим пользователем, чем dovecot. Это без дальнейшей настройки приведет к ошибкам с отказом в разрешении (на самом деле сообщения об ошибках гораздо более загадочные, но вы поняли идею).
Я изменил dovecot user_query для использования веб-пользователя (вместо этого пользователя почты), и на этом этапе также сменил владельца Maildirs.
-> Плагин работает нормально, поскольку веб-пользователь теперь имеет полный доступ к Maildir.
Проблема / Мой вопрос:
Поскольку все письма теперь принадлежат тому же пользователю, на котором работает веб-сервер, я не могу спать спокойно, зная, что какая-то ошибка или неправильный символ в неправильном поле ввода может привести к .. ну .. только неправильные результаты. (Хотя письма зашифрованы и никто - даже root - не может их прочитать, веб-пользователь может, например, удалить файлы ..).
Я делаю регулярное резервное копирование системы, чтобы опередить этот наихудший сценарий. Однако просто из любопытства, вы, ребята, видите лучший способ справиться с этим делом?Могу ли я каким-то образом перейти от веб-пользователя, запускающего плагин, к почтовому пользователю, запускающему doveadm, без необходимости того, чтобы веб-пользователь владел (и, надеюсь, не использовал) Maildir?
Заранее спасибо - надеюсь, это правильная SE-страница в любом случае задать этот вопрос и оставаться здоровым!
Happy codin '
посмотрите здесь - https://gist.github.com/yajrendrag/203b0172fee96a8b002a026362d27bf2 - вы можете игнорировать все, что связано с postfixadmin (я модифицировал его для работы с руководством ISPMail, включая шифрование), но посмотрите на "вторую половину" руководства, где конкретно говорится о шифровании. но в шагах & 7 я решил ситуацию с изменением пароля в roundcube. Я добавил следующее:
/* added to update crypto password when user changes password */
system ('sudo /usr/bin/doveadm mailbox cryptokey password -u '.escapeshellarg(self::username()).' -n '.escapeshellarg($passwd).' -o '.escapeshellarg($curpass));
в
/usr/share/roundcube/plugins/password/password.php в приватной функции _save сразу после строки case PASSWORD_SUCCESS.
Также добавил $config['password_confirm_current'] = true; в конфигурацию в /etc/roundcube/plugins/password/config.inc.php, чтобы пользователь вводил свой текущий пароль для его изменения.
Предполагаю, что я, вероятно, сделал что-то похожее на то, что вы сделали в своем плагине... но в дополнение, в шаге 9, я также добавил
www-data ALL=(root) NOPASSWD: /usr/bin/doveadm в /etc/sudoers.d/local, чтобы www-data мог выполнять doveadm как root без пароля. Вы можете посчитать это слишком небезопасным, но таким образом мне не пришлось менять права собственности на файлы, а сервер предназначен только для меня, так что меня это устроило.
Я нашел этот вопрос поучительным:
Другой лучший подход, измените /etc/sudoers.d/myOverrides на:
ALL = (<фиктивный пользователь>) NOPASSWD: / path / to / chromium-browser это позволяет запускать / path / to / chromium-browser без запроса пароля .
sudo -u-i / path / to / chromium-browser
Я изменил права владения почтовыми ящиками с www-data на vmail и выполнил приведенные выше инструкции.
Я почти уверен, что это PAM-подобное решение является наиболее безопасной установкой, которую я могу придумать по двум причинам: A: Мы минимизируем поверхность атаки, отделяя сервер веб-почты от реальных почтовых ящиков ( Нет, я не параноик) B: Мы все еще запускаем оба процесса в непривилегированной среде (без root)
Вы можете доказать, что я ошибаюсь. (На самом деле, я бы даже хотел полностью отключить sudo для всех других случаев. Возможно? ... Может быть)
Я оставляю этот вопрос «открытым» для тех, кто найдет время, чтобы сделать его более всеобъемлющим и поучительным и заработать тег "лучший ответ". Однако это работает как решение для меня и, возможно, других :)