65. pepsi-whitelist¶

Gérer à la main la liste blanche d’expéditeurs.

65.1. Rôle¶

pepsi-whitelist gère la table pepsi.whitelist — les ensembles nommés de motifs d’expéditeur qui marquent un message comme digne de confiance (non-spam). Il se connecte via la section partagée [pepsi-postgres] et lit la section facultative [pepsi-whitelist]. La même table est lue par pepsi-stage-check-whitelist et peuplée automatiquement par pepsi-stage-auto-whitelist ; cet outil permet à un administrateur d’ajouter, de lister et de supprimer des entrées directement, et permet à chaque utilisateur de semer sa propre liste blanche à partir du courrier qu’il a déjà envoyé. Ce n’est pas une étape. Référence : pepsi-whitelist(1).

Contrairement aux autres outils de l’opérateur, qui deviennent simplement le compte de service pepsi lorsqu’ils sont démarrés en tant que root, celui-ci conserve l’identité appelante et ne bascule que ses ids effectifs le temps de chaque appel à la base de données : import --user et --all-users ont besoin de root pour parcourir la boîte aux lettres d’un autre utilisateur sous les identifiants de cet utilisateur.

65.2. Fonctionnalités¶

add — insérer une entrée : un groupe whitelist_name et un whitelist_regex (une expression régulière étendue POSIX, stockée telle quelle — comparée sans tenir compte de la casse par l’étape de vérification à l’addr-spec extraite de l’en-tête From:, jamais au texte brut de l’en-tête). --no-dkim-required efface l’indicateur dkim_required de la ligne (activé par défaut) ; --signature-required active signature_required (désactivé par défaut) ; --sealer DOMAIN exige en outre que la chaîne ARC validée du message ait été scellée par ce domaine. Idempotent : ré-ajouter une entrée (name, match field, regex) existante est sans effet et laisse ses indicateurs inchangés.
add-list / remove-list — la même chose, pour une liste de diffusion identifiée par le List-Id que portent ses messages plutôt que par un motif From:, ce qui correspond à tout message publié quel qu’en soit l’auteur. --pattern traite l’argument comme une ERE POSIX au lieu d’un identifiant exact. Un List-Id est un en-tête que n’importe qui peut recopier : associez-le donc à --sealer.
list — lister les entrées ordonnées par nom, champ de correspondance et regex, éventuellement restreintes à un seul whitelist_name, sous forme de table ou de --json.
remove — supprimer l’entrée identifiée par ses whitelist_name et whitelist_regex exacts.
import — semer une liste blanche à partir d’une boîte aux lettres : tout message dont le From:/Sender: est à un domaine local et dont le bloc d’en-têtes ne porte aucun champ de trace de remise (Received:, Return-Path:, Delivered-To:, X-Original-To:) est un message que l’utilisateur a envoyé, donc ses adresses To:/Cc:/Bcc: sont des personnes avec lesquelles il correspond et sont ajoutées comme entrées. Le courrier reçu est ignoré (mettre en liste blanche quiconque vous a écrit irait à l’encontre du but recherché), tout comme les destinataires à un domaine local. Lit mbox, Maildir (y compris ses sous-dossiers), IMAP (--imap, avec --imap-user / --imap-password-file) et les formats propres à Dovecot (--doveadm, --doveadm-path) ; seuls les blocs d’en-têtes sont lus, jamais les corps. --dry-run signale ce qui serait ajouté et ne change rien ; --own-address restreint ce qui compte comme du courrier que vous avez envoyé ; --max-entries / --max-messages bornent l’exécution ; et --user / --all-users permettent à root de semer d’autres comptes, chacun dans son propre espace de noms. --include-delivered lit également le courrier reçu et est marquée comme non sûre pour la raison évidente : un From: falsifié sèmerait alors la liste blanche.
import –auto-wildcard — proposer de remplacer les adresses individuelles d’un domaine par une seule entrée *@domain dès qu’au moins WILDCARD_THRESHOLD (10, redéfinissable par exécution avec --threshold) adresses distinctes y ont été vues. Les propositions sont confirmées une à une sur un terminal, toutes acceptées avec --yes, et toutes refusées en l’absence de terminal — une exécution sans surveillance n’élargit jamais d’elle-même une liste blanche à un domaine entier. Les hébergeurs e-mail publics (HOSTERS_FILE, /usr/share/pepsi/hosters.txt, redéfinissable avec --hosters et désactivable avec --no-hosters) ne sont jamais proposés, quel que soit le nombre de correspondants qu’un utilisateur y a : « tout le monde chez gmail.com » n’est pas un ensemble de personnes que l’utilisateur connaît, et cela offrirait à tout spammeur disposant d’un compte gratuit un contournement de la barrière de paiement. Leurs adresses sont tout de même importées individuellement.

65.3. Espaces de noms de liste blanche¶

Un whitelist_name est soit global (un seul segment, p. ex. correspondents — celui de l’opérateur), soit détenu par un utilisateur : <login>/<segment>, p. ex. alice/correspondents. Les segments sont composés de lettres, de chiffres, de _, de . et de - (un point parce que alice.smith est un login ordinaire) ; le séparateur est / parce qu’aucun système de type POSIX ne l’autorise dans un login, alors que -, _, . et un $ final le sont tous. Un segment fait uniquement de points est refusé, de sorte que .. — et donc tout chemin relatif — n’est pas représentable.

Les utilisateurs ordinaires ne peuvent lire et écrire que leur propre espace de noms, déterminé par le login passwd de l’uid réel (jamais $USER ni un argument). Cela inclut list : la liste blanche partagée consigne avec qui l’organisation correspond, et un programme que chaque utilisateur peut exécuter ne doit pas l’imprimer. root et les comptes pepsi/pepsi-owner/ pepsi-whitelist peuvent tout gérer.

Pour qu’une liste blanche par utilisateur compte, une étape de vérification doit la consulter — voir les marqueurs {localpart} / {login} dans le WHITELIST_NAME de pepsi-stage-check-whitelist.

65.4. Modèle de privilèges¶

Atteindre la table partagée nécessite une identité de base de données que les utilisateurs ordinaires n’ont pas ; lire une boîte aux lettres nécessite la leur. pepsi-whitelist est donc installé setuid pepsi-whitelist (mode 4755) et abaisse immédiatement ses ids effectifs vers l’utilisateur appelant, ne les relevant que pendant les quelques millisecondes où il dialogue avec PostgreSQL (l’authentification peer se fonde sur l’uid effectif).

Ce compte n’est délibérément pas le compte de service pepsi : pepsi-setup accorde à son rôle SELECT/INSERT/DELETE sur pepsi.whitelist uniquement, de sorte que compromettre un binaire que chaque utilisateur local peut exécuter n’atteint ni la file d’attente des messages ni les clés de signature.

L’analyse de la boîte aux lettres — des mégaoctets de RFC 5322 contrôlés par un attaquant — a lieu dans pepsi-helper-mailbox-scan(1), lancé avec setresuid positionnant les ids réel, effectif et sauvegardé sur l’utilisateur cible. Ce processus ne conserve aucun id privilégié dans ses identifiants, il ne peut donc pas devenir pepsi-whitelist, même en principe ; c’est le seul programme pepsi-helper-* autonome sans aucun bit setuid. Enfin, -c/--config est refusé pour les appelants non privilégiés, et les variables d’environnement qui pilotent la découverte de la configuration (HOME, XDG_CONFIG_HOME), l’expansion de ${DATADIR} (PATH) et libpq (PG*) sont supprimées avant que la configuration ne soit lue.

Contrairement à pepsi-stage-auto-whitelist (qui échappe une adresse en un motif ancré), add stocke le whitelist_regex exactement tel que donné, de sorte que l’opérateur contrôle directement la correspondance.

65.5. Configuration¶

[pepsi-whitelist] (toutes facultatives) : HOSTERS_FILE (par défaut ${DATADIR}/hosters.txt), WILDCARD_THRESHOLD (par défaut 10), MAX_ENTRIES (le plafond de lignes qu’un seul import peut ajouter, par défaut 5000), SCAN_HELPER (par défaut pepsi-helper-mailbox-scan) et MAILBOX (la boîte aux lettres par défaut depuis laquelle importer), ainsi que les options de localité partagées (LOCAL_DOMAINS, TARGETS, RECIPIENT_DELIMITER) qui décident quelles adresses comptent comme les nôtres. La connexion à la base de données provient de [pepsi-postgres]. Voir pepsi-whitelist(1).

65.6. Voir aussi¶

pepsi-stage-check-whitelist, pepsi-stage-auto-whitelist, pepsi-queue, Architecture, pepsi-whitelist(1), pepsi-helper-mailbox-scan(1), pepsi.conf(5).