Resumen

  • En el modelo de Postfix con maestro privilegiado, la mayoría de los servicios abre primero los archivos necesarios y después abandona root antes de procesar solicitudes; cuatro servicios de entrega conservan una identidad root guardada para tareas acotadas.
  • El maestro sin privilegios reduce los derechos del supervisor, pero suprime parte del aislamiento interno, expone más secretos y registros si un servicio queda comprometido y solo se admite en un conjunto reducido de configuraciones de producción.

Preguntar si un servidor de correo «se ejecuta como root» simplifica demasiado el problema. Postfix permite formular preguntas más concretas: qué proceso necesita qué privilegio, en qué momento de una solicitud y sobre qué archivos o recursos de otros usuarios.

Un mensaje que llega por SMTP o QMQP pasa primero por un servicio expuesto a la red. Este valida la entrada y entrega el sobre y el contenido a cleanup(8). Esa etapa realiza el último procesamiento antes de encolar el mensaje, lo escribe en la cola de entrada y avisa a qmgr(8). El gestor de colas decide qué agentes completan la entrega. Mantiene una cola activa limitada; por eso, un retraso grande no obliga al proceso a abrir todos los mensajes pendientes. El proceso residente master(8) supervisa los servicios, los inicia bajo demanda y aplica los límites configurados.

El supervisor y los servicios que atienden solicitudes cumplen funciones distintas. En el modelo de maestro privilegiado de Postfix, un servicio puede arrancar con privilegios de root, abrir archivos sensibles —por ejemplo, claves privadas TLS o contraseñas de bases de datos— y abandonarlos de forma irreversible antes de procesar solicitudes. La documentación de seguridad afirma que, si el servicio se compromete después de esa transición, ya no podrá abrir esos archivos, bases de datos ni registros.

Root interviene durante la inicialización y la asignación de privilegios; eso no equivale a concederle acceso permanente a cada proceso que atiende la red.

Hay excepciones. La mayoría de los servicios pierde root de forma definitiva, pero local(8), pipe(8), spawn(8) y virtual(8) conservan una identidad root efectiva guardada. La necesitan para actuar como el usuario destinatario o manejar recursos ajenos a Postfix, como un buzón o un comando externo. Postfix distingue dos funciones: root puede separar privilegios entre sus servicios y confinar Postfix cuando alguno accede a archivos de usuario o ejecuta software que no pertenece al sistema. La etiqueta general «proceso root» oculta esas fronteras distintas.

En una presentación de LISA de 2010, Wietse Venema describió Postfix como una arquitectura segmentada de mínimo privilegio. Citó como influencia un diseño de cortafuegos que separaba la recepción y la entrega de correo mediante procesos de bajo privilegio dentro de un chroot. También explicó por qué los programas pequeños pueden facilitar el mantenimiento una vez construida la infraestructura de comunicación. Es un testimonio histórico sobre el diseño, no un recuento actual de demonios ni una medición de resultados de seguridad. La documentación vigente explica el flujo entre recepción, limpieza, gestión de colas y entrega.

El cambio reciente no afirma que quitar root al supervisor vuelva automáticamente más seguro todo el sistema. Según la documentación de Postfix, Venema implementó primero el funcionamiento de master(8) sin privilegios para pruebas de integración no publicadas en 2025. Tras una consulta de un cliente en 2026, lo adaptó para un uso limitado en producción y añadió documentación. En esta modalidad, master opera con la identidad fija postfix, en vez de root. Los servicios usan los mismos privilegios de Postfix durante la inicialización y al atender solicitudes. El proyecto señala que así no se conserva la separación interna de privilegios ni el confinamiento habitual al acceder a archivos ajenos a Postfix, entregar a buzones o ejecutar comandos externos.

La diferencia aparece en los permisos cotidianos. Los archivos de claves secretas de Postfix deben ser legibles por el usuario postfix; por ello, un servicio comprometido puede leerlos. Los registros opcionales de Postfix deben pertenecer a postfix, de modo que un servicio comprometido puede consultarlos, modificarlos o borrarlos. La configuración no debe quedar bajo la propiedad de ese usuario. En una instalación con varias instancias, todas deben operar con maestro privilegiado o todas con maestro sin privilegios: no se pueden mezclar los dos modos.

El límite de producción es acotado. Postfix permite el maestro sin privilegios en despliegues que reenvían todos los mensajes mediante SMTP o LMTP. Prohíbe usarlo en producción cuando los servicios locales ejecutan programas externos o entregan mensajes en archivos de buzón. Uno de los riesgos descritos es que un comando incluido en el archivo .forward de un usuario se ejecute con los privilegios de postfix, en vez de los del usuario destinatario, y permita que este controle el sistema de correo. La advertencia se aplica a configuraciones concretas, pero es inequívoca.

La lección arquitectónica no es «root es seguro» ni «root es inseguro». Cambiar privilegios desplaza el riesgo de una frontera a otra. Un maestro sin root puede resultar adecuado para un relé acotado, pero sus servicios comparten el acceso a secretos y registros que el modelo privilegiado puede proteger tras la inicialización y la renuncia a privilegios. Antes de cambiar la identidad del maestro, los operadores deben clasificar sus rutas de entrega y comprobar que el modo elegido coincide con los archivos y comandos que puede alcanzar cada servicio.

La documentación pública define el intercambio; no demuestra qué modalidad se usa más ni cuáles son sus resultados en instalaciones reales.

Fuentes