Postfix et sécurité - Historique des versions

imported>SylvainBeucler : vérifications

2008-06-09T10:44:50Z

vérifications

imported>SylvainBeucler le 19 décembre 2007 à 17:30

2007-12-19T17:30:58Z

imported>SylvainBeucler : fote

2006-01-18T17:38:58Z

fote

imported>SylvainBeucler le 18 janvier 2006 à 17:38

2006-01-18T17:38:12Z

imported>SylvainBeucler : prés.

2006-01-18T17:37:23Z

prés.

imported>SylvainBeucler le 18 janvier 2006 à 17:37

2006-01-18T17:37:01Z

Nouvelle page

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
** 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):
<blockquote>
for security reasons, the virtual(8) delivery
agent disallows table lookup through the proxymap(8)
server, because that would open a security hole.
<blockquote>

J'adore ce style d'explication claire, constructive et fondée; après cela on n'a plus aucune doute sur les principles 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.

@@ Ligne 21 : / Ligne 21 : @@
 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.
+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: il semble que les versions ultérieures de Postfix (par exemple, 2.3.8 dans Debian Etch) lèvent cette limitation. À bon entendeur...
+Addendum: les versions ultérieures de Postfix (par exemple, 2.3.8 dans Debian Etch) lèvent cette limitation. À bon entendeur...

← Version précédente		Version du 19 décembre 2007 à 17:30
Ligne 22 :		Ligne 22 :

	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.		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.
		+
		+	Addendum: il semble que les versions ultérieures de Postfix (par exemple, 2.3.8 dans Debian Etch) lèvent cette limitation. À bon entendeur...

@@ Ligne 19 : / Ligne 19 : @@
 </blockquote>
-J'adore ce style d'explication claire, constructive et fondée; après cela on n'a plus aucune doute sur les principles 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).
+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.

@@ Ligne 7 : / Ligne 7 : @@
 * 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
+** à un processus qui a chroot()-é d'utiliser une resource à la racine (notamment: la socket Unix de MySQL)
 ** de réutiliser les connexions MySQL

@@ Ligne 17 : / Ligne 17 : @@
 agent disallows table lookup through the proxymap(8)
 server, because that would open a security hole.
-<blockquote>
+</blockquote>
 J'adore ce style d'explication claire, constructive et fondée; après cela on n'a plus aucune doute sur les principles 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.