Quand le serveur est en cours d'exécution, un utilisateur mal intentionné ne
peut pas interférer dans les communications client/serveur. Néanmoins,
quand le serveur est arrêté, un utilisateur local peut usurper le rôle du serveur
normal en lançant son propre serveur. Le serveur usurpateur pourrait lire
les mots de passe et les requêtes envoyés par les clients, mais ne pourrait
pas renvoyer de données car le répertoire PGDATA
est
toujours sécurisé grâce aux droits d'accès du répertoire. L'usurpation
est possible parce que tout utilisateur peut lancer un serveur de bases
de données ; un client ne peut pas identifier un serveur invalide
sauf s'il est configuré spécialement.
Un moyen d'empêcher les serveurs d'usurper des
connexions local
es est d'utiliser un répertoire de
socket de domaine Unix (unix_socket_directories) qui
n'a un droit en écriture que pour un utilisateur local de
confiance. Ceci empêche un utilisateur mal intentionné de créer son
propre fichier socket dans ce répertoire. Si vous craignez que
certaines applications puissent encore référencer
/tmp
pour le fichier socket et, du coup, être
vulnérable au « spoofing », créez un lien
symbolique /tmp/.s.PGSQL.5432
pointant vers le fichier
socket déplacé. Vous pourriez alors avoir besoin de modifier votre script
de nettoyage de /tmp
pour empêcher la suppression du
lien symbolique.
Une autre option pour les connexions de type local
est que
les clients utilisent requirepeer
pour indiquer un propriétaire précis du processus serveur connecté au socket.
Pour éviter l'usurpation sur les connexions TCP, utilisez des certificats SSL, et assurez-vous que les clients vérifient le certificat du serveur, ou bien utilisez le chiffrage GSSAPI (ou les deux, s'il s'agit de connexions séparées).
Pour éviter l'usurpation avec SSL, le serveur doit être configuré
pour accepter les connexions hostssl
(Section 20.1)
et avoir des fichiers SSL clé et certificat
(Section 18.9). Le client TCP
doit se connecter en utilisant sslmode='verify-ca'
ou
verify-full
et le fichier certificat root approprié
doit y être installé (Section 33.18.1).
Pour éviter l'usurpation avec GSSAPI, le serveur doit être configuré
pour n'accepter que les connexions hostgssenc
(Section 20.1) et l'authentification
gss
avec elles.
Le client TCP doit se connecter en utilisant gssencmode=require
.