Ce fichier décrit les buts de conception et les raisons derrière quelques unes des décisions de conception pour mon petit démon POP3, popa3d. Pourquoi popa3d ? Il y a de nombreux serveurs POP3 différents -- avec différents ensembles de fonctionnalités, performances et fiabilités. Toutefois, autant que je sache, avant que je commence le travail dans popa3d, il n'y en avait seulement qu'un avec la sécurité comme l'un de ses buts de conception primaires : qmail-pop3d. Malheureusement, il ne fonctionne qu'avec qmail, et seulement avec son nouveau format maildir. Alors que qmail et maildirs ont vraiment quelques avantages, beaucoup de personnes continuent d'utiliser d'autres MTA, et/ou utilisent le vieux format mailbox, pour différentes raisons. Beaucoup d'entre eux ont besoin d'un serveur POP3. Les buts de conception. Bien, les buts eux-mêmes sont évidents; ils sont probablement les mêmes pour la plupart des autres serveurs POP3 aussi. Ce sont leurs priorités qui diffèrent. Pour popa3d, les buts sont : 1. Sécurité (dans la mesure du possible avec POP3 et autres, bien sûr). 2. Fiabilité (encore, comme limité par le format mailbox et le protocole). 3. Conformité aux RFC (légèrement relâchée pour fonctionner avec les clients POP3 du monde réel). 4. Performance (limitée par les buts les plus importants, ci-dessus). Évidemment, comme les commentaires l'indiquent, aucun des buts ne peut être satisfait complètement, et des décisions équilibrées doivent être prises. Sécurité. D'abord, il est important qu'aucun des utilisateurs de popa3d ait un faux sens de la sécurité juste parce que c'était le but primaire de la conception. Le protocole POP3 transmet les mots de passe en clair, et ainsi, si vous vous intéressez à la sécurité de vos comptes utilisateurs individuels, ne devrait être utilisé seulement soit dans des réseaux de confiance, ou tunnelisé dans des canaux chiffrés. Il existe des extensions au protocole qui sont supposées fixer ce problème. Je ne les supporte pas encore, partiellement parce que ceci ne va pas fixer pleinement le problème. En fait, APOP et les mécanismes SASL plus faiblement définis tels que CRAM-MD5 peuvent potentiellement être moins sécurisés que la transmission de mots de passe en clair à cause du besoin que des équivalents de textes en clairs soient stockés sur le serveur. Il est également important de comprendre que rien ne peut être parfaitement sécurisé. Je peux commettre des fautes. Alors que la conception de popa3d rend plus difficile à celles-ci de devenir des trous de sécurité, c'est pourtant toujours possible. Cela étant dit, allons aux décisions de conception critiques pour la sécurité. Gestion des privilèges. Initialement, popa3d est démarré en tant que root pour traiter une connexion. Toutefois, il fait très peu de travail en tant que root : changer vers des UID moins privilégiés, communiquer avec les processus fils, et vérifier les informations d'authentification (qui implique souvent d'accéder aux fichiers shadow ou master.passwd). Les changements de privilèges suivants se produisent durant un session POP3 réussie, avec authentification /etc/shadow : démarrage en tant que root | ----------------- |fils |père v v passer l'utilisateur popa3d, toujours en tant que root, traiter l'état d'AUTHORIZATION, attendre de lire écrire les résultats - - > les informations et sortir d'authentification | ----------------- |fils |père v v getspnam(3), crypt(3), attendre de lire vérifier, écrire les - - > les résultats résultats et sortir d'authentification (pour tout nettoyer) | | v passer l'utilisateur authentifié, traiter l'état TRANSACTION, UPDATE peut-être la boite à lettres, et sort Confiance. Aucune partie de popa3d ne fait confiance à toute information obtenue depuis des sources externes (c.-à-d., il n'est jamais assumé que les données sont au format espéré, et sont traitées comme étant sujettes à des vérifications d'autorisation). Ceci inclus les commandes POP3, les contenus des boites à lettres, et même le propre processus fils non-privilégié de popa3d pour le traitement de l'état AUTHORIZATION. Attaques en dénis de services. Juste comme avec les autres logiciels, il existe plusieurs façons de causer des dénis de services, en fournissant à popa3d une quantité énorme de données autrement valides. Je suis conscient des attaques suivantes sur popa3d lui-même : 1. Inondation de connexions. En s'exécutant en mode standalone, popa3d effectue quelques vérifications pour réduire de façon significative l'impact de telles attaques en limitant la consommation de ressources (les processus fils et le rythme de journalisation), tout en fournissant toujours un service complet aux autres adresses IP sources et en journalisant tout ce qui peut être important. Toutefois en s'exécutant depuis un clone inetd, le traitement de ces attaques est laissé à votre inetd et au noyau. 2. Les tailles de boites à lettres énormes, soit en nombre de messages ou en octets. Il y a des limites dans popa3d (voir params.h) qui sont destinées à prévenir cette attaque d'arrêter le service entier. Selon votre disque et d'autres quotas, il peut être toujours possible d'arrêter des utilisateurs individuels d'obtenir leurs messages. Fiabilité. En citant Dan Bernstein, "le format mbox ... est non fiable de façon inhérente". Alors que popa3d, comme d'autres logiciels de messagerie qui s'occupent de boites à lettres, ne garantie pas la fiabilité lors de plantages systèmes, il y a toujours du sens de parler à propos de son fonctionnement sur un système par ailleurs stable. Interaction avec les autres MUA. Similairement à cucipop (mais contrairement à qpopper), popa3d travaille sur le fichier mailbox original, sans le copier. Toutefois, contrairement à cucipop, popa3d est capable de s'assurer que le boite à lettres ne soit pas corrompue si un autre MUA la modifie durant une session POP. Avant chaque accès à une boite à lettres, popa3d vérifie son heure de modification et, si celle-ci a changé, détermine si ceci est dû à un nouveau mail qui vient juste d'être délivré, ou d'autres changements dans la boite à lettres. Dans ce dernier cas, la session POP est avortée en silence (ce qui ne viole pas le RFC). popa3d est attentif de faire en sorte que l'heure de modification changera si la boite à lettres est écrite, en gardant le verrou jusqu'à une seconde si nécessaire. Accès à la boite à lettres. Excepté pour les limites en taille totale et en nombre de messages mentionnées ci-dessus (et vous pouvez même désactiver celles-ci), il n'y a pas d'autre limite artificielle sur les contenus des boites à lettres. En particulier, il n'y a pas de limite de longueur de lignes; contrairement à qmail-pop3d, les lignes n'ont même pas besoin de tenir dans la mémoire disponible. Les octets NUL sont autorisés dans les messages également. Verrouillages. À cause de l'abaissement "complet" vers l'utilisateur (c.-à-d., sans même garder un GID de mail comme quelques autres serveurs POP3 le font), popa3d n'utilise que fcntl(2) ou flock(2) pour les verrouillages. Comme résultat, il peut ne pas être sûr au dessus de NFS. C'est où je choisi la sécurité au dessus des fonctionnalités ou de la fiabilité. Conformité à la RFC. J'ai essayé que popa3d soit aussi strictement conforme à la RFC 1939 que possible. La plupart des autres serveurs POP3 ont des "fonctionnalités" supplémentaires qui violent la RFC. Les exemples incluent : découper les commandes longues (sans importer qu'elles soient valides ou non) et ainsi générer de multiples réponses -ERR (quand ce n'est pas pire : traiter quelque chose du milieu d'une ligne comme une commande) à une seule commande, traiter "LIST 4294967297" comme "LIST 1" au lieu de reporter une erreur, ignorer après un octet NUL jusqu'à la fin de la ligne et ainsi mal interpréter la commande. Alors que ceux-ci sont pour la plupart sans danger, ils peuvent théoriquement empêcher le client POP3 de détecter la non disponibilité d'une extension de protocole. Il y a toutefois un endroit où la conformité de popa3d à la RFC est relâchée délibérément : popa3d accepte les commandes terminées par un seul LF, même si le RFC dit que les commandes sont terminées par une paire CRLF. Performance. Malgré les deux appels à fork(2) supplémentaires pour des raisons de sécurité, popa3d semble se conduire assez efficacement : le code efficace d'analyse de boite à lettres et le manque de copie de boite à lettres compensent les fork supplémentaires. Voici quelques données réelles de performances que j'ai collectées (popa3d s'exécutant via inetd; les sites plus grands utiliseraient plutôt le mode standalone) : 24864 295.50re 16.92cp popa3d* 12749 4578.88re 15.50cp popa3d C'est-à-dire, 12749 sessions POP3 ont pris 32,42 minutes de temps CPU (sur un Pentium II à 350 Mhz); de celles-ci, plus de la moitié furent passées dans le processus fils temporaire. Ce n'est quand même pas si mauvais, puisque le système exécutait une fonction crypt(3) (intentionnellement) coûteuse qui était comptabilisée au processus fils d'authentification /etc/shadow. Avant de mettre à jour vers popa3d, la même machine exécutait qpopper (depuis inetd, aussi) : 12025 3169.38re 35.56cp popper Il utilisait un peu plus de CPU pour moins de sessions POP3. -- Solar Designer