Postfix et sécurité
Postfix est décomposé en partie indépendantes. Je ne sais pas si chacune d'elle est un processus à part entière - cela en a l'air. Chaque partie dispose d'une page de manuel dans la section 8.
Voir le fichier master.cf.
Notamment:
- smtpd: reçoit les requêtes SMTP par le réseau; chroot() par défaut dans /var/spool/postfix
- virtual: chargé de la distribution du courrier lors de la gestion de plusieurs domaines sur une même machine
- proxymap: pour MySQL, permet:
- à un processus qui a chroot()-é d'utiliser une resource à la racine (notamment: la socket Unix de MySQL)
- de réutiliser les connexions MySQL
Problème de sécurité: virtual refuse d'utiliser proxymap pour 'virtual_mailbox_maps' (mais accepte pour ses autres tables). Pourquoi?
- d'après http://nixdoc.net/files/forum/about80646.html, "Because no external programs are executed by virtual(8)" - sachant que proxymap est un démon à part et non pas un programme à lancer (sinon il ne pourrait pas sortir d'une prison chroot())
- d'après http://www.webservertalk.com/archive281-2004-6-279926.html (une perle):
for security reasons, the virtual(8) delivery agent disallows table lookup through the proxymap(8) server, because that would open a security hole.
J'adore ce style d'explication claire, constructive et fondée; après cela on n'a plus aucune doute sur les principes de sécurité sous-jacents à Postfix. Et si vous ne comprenez toujours pas pourquoi proxy:mysql:virtual_mailbox_maps est hautement insécurisé, mieux vaut changer de métier. Pour ma part j'ensage la chirurgie (je me ferai greffer une nouvelle cervelle).
Bon, il faut surtout constater que virtual(8) ne chroot() pas par défaut, et que proxymap: n'est donc pas nécessaire de ce point de vue (sauf si on active la vérification d'expéditeur, réalisée par smtpd qui chroot() par défaut).
Addendum: les versions ultérieures de Postfix (par exemple, 2.3.8 dans Debian Etch) lèvent cette limitation. À bon entendeur...