Image Docker XWINDOW en coréen accessible via RDP Windows

Je publie une image Docker XWINDOW (Wayland) en coréen, basée sur la toute dernière Debian 13 (Trixie).

Beaucoup de personnes utilisent Windows, et il arrive qu’on ait envie de lancer de temps en temps un X Window Linux avec prise en charge du coréen dans Docker pour travailler.
Donc !
J’ai créé un environnement GUI en coréen basé sur Debian, accessible via le Bureau à distance Windows.

Cette image inclut par défaut les principaux outils nécessaires à un environnement de développement, comme Visual Studio Code, Chromium, Vim, Git, Node.js + npm, et peut donc être utilisée immédiatement comme environnement de dev. (Elle est donc assez volumineuse.)

Parmi les principales caractéristiques :

• connexion via le Bureau à distance Windows (RDP) possible
• conservation des données et des volumes : en reliant /home/(nom d’utilisateur) à un volume Docker, les données peuvent être persistantes

À noter :
Comme cela s’exécute dans Docker, VSCode et Chromium n’utilisent pas le mode sandbox. Merci d’être vigilant sur le plan de la sécurité. La fonction audio a été retirée en raison de nombreux conflits et bugs. J’ai estimé que, dans la plupart des cas, vous écoutez probablement déjà la musique sur votre PC Windows, donc elle a été exclue.

C’est une image particulièrement utile pour les utilisateurs coréanophones qui souhaitent mettre en place rapidement un environnement de développement.

Le code source est disponible sur https://github.com/lancard/x11-korean, n’hésitez pas à y jeter un œil, et si vous avez besoin d’une fonctionnalité, envoyez un ticket ou une PR à tout moment !

[chcv0313]

Dans le vscode interne, il est possible de créer de nouveaux fichiers, mais pas de modifier les fichiers existants. Même en changeant les fichiers existants avec chmod 777. Il semble que ce soit un problème d’autorisations ou de propriété de groupe, donc je vais encore essayer quelques pistes.

[chcv0313]

Il semble que le problème ait été surmonté en modifiant le fichier sh dans l’entry point et en ajustant XWINDOW_USER_ID sur l’ID du dossier de travail.

[chcv0313]

définir le nom d’utilisateur

XWINDOW_USER="${XWINDOW_USER:-user}"
if ! id -u $XWINDOW_USER >/dev/null 2>&1; then
useradd -m -s /bin/bash $XWINDOW_USER
echo "user '$XWINDOW_USER' generated."
fi

j’ai remplacé cette partie par

XWINDOW_USER="${XWINDOW_USER:-user}"
XWINDOW_USER_ID="${XWINDOW_USER_ID:-1000}" # 1000 par défaut
if ! id -u $XWINDOW_USER >/dev/null 2>&1; then
useradd -m -s /bin/bash -u $XWINDOW_USER_ID $XWINDOW_USER
echo "user '$XWINDOW_USER' generated with UID $XWINDOW_USER_ID."
else
echo "user '$XWINDOW_USER' already exists."
fi

afin de définir USER_ID avec le même identifiant de compte que sur la machine hôte.

[shakespeares]

Peut-on l’utiliser à la place de WSL ?

[lancard]

Oui, c’est utilisable. Personnellement, je n’aime pas WSL / WSL2, donc j’ai installé Docker sur Hyper-V et j’utilise ça.

[shakespeares]

Est-ce que je pourrais vous demander, avec précaution, pourquoi vous ne l’aimez pas ?

[lancard]

Je n’aime pas mélanger deux systèmes d’exploitation. On ne sait pas quels effets de bord cela peut avoir. Je pense que chaque OS devrait être isolé dans un sandbox ou occuper à lui seul un serveur physique. En plus, j’ai déjà eu par le passé une expérience où WSL se comportait de façon étrange.

[doovooda]

Comme je ne comprends pas très bien ce que vous voulez dire au vu des connaissances que j’ai, est-ce que ce n’est pas similaire à la structure logique de base de WSL ou de Docker ? Y a-t-il un point que j’ai mal compris ?

[lancard]

On peut dire que WSL2 est un peu similaire, mais la structure de WSL est assez différente. Fondamentalement, ça fonctionne au-dessus du noyau Windows. Pour WSL2, il est vrai que ça tourne au-dessus d’un hyperviseur, mais je pense que le niveau d’isolation est un peu différent. Comme le montage automatique se fait dans les deux sens, les OS peuvent accéder au système de fichiers l’un de l’autre. Cela peut donc produire des résultats indésirables. Par exemple, Windows peut créer automatiquement $RECYCLE.BIN sur de l’ext4, et si l’un des OS est compromis par un hacker, cela devient critique pour les deux. Ce que j’ai fait, si on le souhaite, peut fonctionner sans rien monter du tout. On peut le faire tourner seul, sans connexion avec Windows.
Et puis il y a aussi un impact sur la vitesse d’installation... Avec la méthode de mon image, si elle ne vous plaît pas, il suffit de supprimer l’image Docker et d’en recopier une nouvelle. Pour les mises à jour aussi, il suffit simplement de récupérer l’image. Il me semble aussi qu’il y avait quelques problèmes côté réseau avec WSL2. En outre, le noyau Linux n’est pas un noyau Linux pur, c’est à ma connaissance une version personnalisée par MS.
Cela correspond donc assez mal à ma recherche d’un Linux pur (c’est-à-dire avec une vraie isolation entre les deux).

J’ai surtout énuméré les inconvénients, mais au fond cela relève aussi en partie des préférences personnelles, donc vous pouvez choisir ce qui vous convient.

[doovooda]

Je confirme tardivement.
Merci pour votre réponse si attentionnée !

[lancard]

Et Docker lui-même est quasiment réservé à Linux, et si l’on considère aussi le fait de faire tourner Docker sur un NAS, la distinction entre majuscules et minuscules, etc., on peut dire que cela a été créé parce qu’utiliser Docker présente beaucoup d’avantages.

[lancard]

En mode privileged, j’ai modifié le fonctionnement pour qu’il s’exécute dans le sandbox. En mode privileged, il est possible de connecter des ressources locales (lecteur C, etc.). Elles sont montées dans $HOME/thinclient_drives.

[lancard]

Si vous voulez connecter des ressources locales (C:, D:, etc.), exécutez-le en mode privileged. (Dans ce cas, le copier-coller de fichiers avec CTRL + C / V fonctionne.)

[po5678]

Oooh... VS Code ne se lance pas :)

[po5678]

Je me réponds à moi-même : comme il n’y avait pas de réaction, j’ai essayé plusieurs choses, puis en lançant code --no-sandbox dans le terminal, ça s’ouvre.

[lancard]

Hum ? Peut-être que ce qu’il y a sur le bureau ne s’est pas ouvert ?

[po5678]

Ah non, ça ne marchait pas. Je ne sais pas ce que j’ai mal fait...

[lancard]

Comme je modifie constamment l’image, il se peut que ce soit une image intermédiaire.
Vérifiez d’abord que la commande de l’icône vscode sur le bureau est bien /usr/bin/code %F,
puis ouvrez le fichier /usr/bin/code et vérifiez que l’avant-dernière ligne est bien
ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --no-sandbox --disable-gpu "$@"
.

[chcv0313]

Je me suis mis à étudier Docker récemment. J’ai analysé les vulnérabilités de cette image avec trivy et il en a trouvé 1053. Elles ne me semblent pas toutes importantes, on dirait plutôt qu’il détecte un peu tout et n’importe quoi, mais pourriez-vous me donner quelques conseils sur la manière de vérifier et d’assurer concrètement la sécurité d’une image en pratique ?

[lancard]

En réalité, il y a tellement de façons d’éliminer les vulnérabilités qu’il n’existe pas de réponse unique.
Dans mon cas, j’utilise autant que possible les versions les plus récentes et les plus stables, et lorsque j’utilise GitHub Actions, j’active au maximum les bots de sécurité. En fait, comme vous pouvez le voir, cette image xwindow ne contient aucune partie programmée, donc il ne devrait y avoir que les vulnérabilités de base propres aux programmes installés.

[grollcake]

Je me demandais pourquoi l'absence de mode sandbox était considérée comme un point d'attention en matière de sécurité.
Est-ce que cela signifie que Docker ne fournit pas de fonctionnalité de sandboxing pour les processus internes ? Et que, de ce fait, le conteneur n'a pas d'autre choix que de s'exécuter en root, avec le risque que, même dans un environnement isolé par Docker, un malware puisse s'infiltrer dans les volumes mappés avec l'hôte ? Ou bien cela veut-il dire que les fichiers créés par l'utilisateur dans le système de fichiers interne de Docker peuvent ne pas être sûrs ?

[lancard]

À ma connaissance, que ce soit sous Windows ou Linux, Chrome fonctionne en mode sandbox. Donc... même si quelqu’un créait un exploit via JavaScript ou autre pour attaquer une vulnérabilité, cela n’affecterait pas réellement l’OS.

Mais en mode conteneur, il faudra probablement activer le mode privileged pour pouvoir utiliser cette fonctionnalité.

Bien sûr, on peut indiquer qu’il faut activer ce mode, mais pour ma part, je considérais que le conteneur était lui-même une sandbox. Un peu comme une sorte de fenêtre qu’on ouvre et qu’on ferme facilement, si vous voulez...

C’est pourquoi Chromium et VS Code basé sur Electron sont configurés pour fonctionner dans un mode sans sandbox.

Autrement dit, cela peut être risqué dans l’hypothèse où Chromium et VS Code auraient des vulnérabilités, et qu’un attaquant soit capable de créer un exploit en les utilisant.

[lancard]

Le nom de l’image Docker est lancard/xwindow-korean.

[lancard]

Comme c’est du Wayland, j’ai changé le nom du dépôt en https://github.com/lancard/xwindow-korean ~

[lancard]

Comme Ubuntu appartient à la famille Debian, vous pouvez aussi utiliser facilement apt et autres outils. Au final, j’ai trouvé Debian meilleure que l’image de base Ubuntu.