Problèmes de sécurité avec le transfert X11
Quelles sont les préoccupations et les raisons de sécurité pour ou contre l'autorisation du transfert X11. J'ai généralement adopté une approche consistant à ne pas l'autoriser sous couvert de sécurité. Récemment, un utilisateur a indiqué qu'il pensait que les implications de sécurité résultant de l'autorisation des sessions X11 Forwarded étaient négligeables. J'étais curieux d'en savoir plus sur le mal à autoriser le transfert X11 et pourquoi on pourrait le permettre.
L'implication du transfert X11 est qu'il ouvre un canal du serveur vers le client. Dans une session SSH simple, le client est plus fiable que le serveur: toute personne contrôlant le client peut exécuter des commandes sur le serveur (en supposant un accès Shell), mais l'inverse n'est pas vrai. Avec le transfert X11, le serveur est susceptible d'obtenir un accès Shell au client.
Dans une session texte, il existe un canal limité du serveur vers le client: le serveur détermine la sortie qui est affichée sur le client, et peut notamment essayer d'exploiter des séquences d'échappement dans le terminal fonctionnant sur le client,
Dans une session X11, le serveur peut renvoyer des commandes X11 au client. Le X11 n'a pas été conçu avec la sécurité à l'esprit, il a été conçu avec l'idée que tous les programmes que vous affichez sont exécutés par vous et donc fiables de toute façon. Par défaut, SSH soumet les commandes du serveur à des restrictions via extension X11 SECURITY . L'extension SECURITY désactive certaines attaques évidentes telles que les saisies de clavier et l'injection de touches, mais permet à d'autres comme le vol de focus.
Supposons que j'ouvre une connexion SSH à someserver, avec le transfert X11 activé. Le principal risque est que si someserver est malveillant, alors someserver peut faire toutes sortes de choses désagréables aux fenêtres/applications que j'ai ouvertes sur mon propre ordinateur.
Par exemple, someserver peut ouvrir des fenêtres sur mon ordinateur, peut fermer d'autres fenêtres que j'ai ouvertes, peut espionner le contenu d'autres fenêtres que j'ai ouvertes, peut espionner les clés que je tape dans d'autres fenêtres, peut injecter usurpation de touches et événements de souris dans d'autres fenêtres que j'ai ouvertes, et généralement gâcher avec toutes les autres fenêtres que j'ai ouvertes sur ma machine - même si certaines de ces autres fenêtres sont des applications locales exécutées localement.
Une solution aux risques de transfert X sur ssh discuté dans les autres réponses serait d'utiliser ce que l'on pourrait appeler un serveur X masqué, qui n'est pas vraiment un serveur X mais présente une interface pseudo X et un écran pseudo X au logiciel client sur le conteneur, tout en transmettant du travail X au vrai serveur X derrière. L'écran pseudo X s'affiche sous la forme d'une seule fenêtre X sur le bureau X hôte réel.
Même s'il n'était pas conçu comme un outil de sécurité, Xephyr correspond à cette description.
Pour cette raison, j'ai écrit un programme javascript pour créer un conteneur lxd/lxc à partir d'une image ubuntu Vanilla et le remplir avec firefox, openvpn, Xephyr et pusleaudio.
https://github.com/craigphicks/browser-on-lxc-vpn-xephyr
https://www.npmjs.com/package/browser-on-lxc-vpn-xephyr
Je ne ferais aucune revendication de sécurité forte - c'était un exercice de preuve de concept.