Ces derniers temps, j'ai pas mal exploré des sujets de FreeRDP avec remote credential guard, Kerberos et NLA, je fais donc
un petit billet sur comment kerberossiser sa partie serveur de FreeRDP.
Toute la kerberosserie commence avec le NLA: si on se connecte sur un serveur RDP avec mstsc et que la configuration est à peu près standard.
Il y a quelques temps j'ai travaillé sur la partie Kerberos de remote credential guards, et suite à des
rapports de compatibilité avec du windows 11 et des controlleurs de domaine avec des versions
récentes, je me suis un peu intéressé à la partie NTLM.
L'idée derrière remote credential guards, c'est qu'on se connecte à une machine distante, le mot de passe n'est pas envoyé à cette machine, mais qu'on a quand même du SSO. Et donc en théorie, même si on se connecte à une machine compromise, on ne se fait pas voler son mot de passe.
Encore beaucoup d'améliorations sur Accendino, et on a cette version 0.5.10 qui est en cours de stabilisation avec cette alpha 1.
FFmpeg fait partie de ces logiciels qui sont horribles à construire de manière automatique sous windows (juste derrière OpenSSL), et un des buts recherchés pour cette version c'était de pouvoir construire FreeRDP avec le support d'FFmpeg sous windows avec la chaine de compilation de Visual Studio et tout ça de manière automatique. Pas de bidouilles à faire à la main pour que ça fonctionne, on tape
$ accendino --targets=freerdp3 freerdp.accendino
ça checkout, ça compile et c'est prêt.
Première étape pour compiler FFmpeg avec Visual Studio: il y a besoin de passer des commandes sous msys2, et donc cette
version amène le support d'installation des packages dans cet environnement. Si on met en dépendance
de packages 'msys2/yasm', accendino installera les packages correspondants dans l'environnement msys2.
Petit extrait du fichier accendino de FFmpeg:
... ffmpegPkgs = { 'Darwin': ['nasm'], 'Windows': ['choco/nasm|path/nasm', 'msys2/make', 'msys2/yasm', 'msys2/diffutils'], } ...
Ce support n'a pas été très compliqué à coder car c'est pacman qui est utilisé
J'ai fais quelque petites mises à jour sur mon script Accendino, jusqu'à en faire un petit programme à part entière avec des fonctionnalités intéressantes. Cette version 0.5.9 vient ajouter plein de choses sympatiques par rapport à la version précédente. Avec le temps, je vois plus Accendino comme un programme permettant de construire un logiciel complexe à partir de plusieurs sources logicielles, et sur plusieurs plate-formes. Pour l'instant mon cas d'école est FreeRDP, j'essaye d'avoir des fichiers accendino qui permettent de construire FreeRDP à partir de zéro sur le plus de plate-formes possibles (linux, mac, windows, mingw, ...)
Originellement accendino n'était qu'un petit script permettant de jouer les instructions d'installation d'Ogon. Il était néanmoins un peu plus complexe car on pouvait spécifier les emplacements git à descendre. Par exemple, pour utiliser les repos de Forgiare à la place des repos officiels d'Ogon. Avec la version 0.5.0, j'ai pas mal étendu ses fonctionnalités:
Une petite astuce que j'ai découvert il y a quelque temps: l'outil massif de valgrind. Il permet d'adresser des cas
où on a un programme qui mange trop de mémoire inutilement, mais comme il fait correctement le ménage à la fin, on ne
voit rien avec les outils de leak standard (valgrind ou asan)
C'est là qu'intervient l'outil massif de valgrind ainsi que l'outil de visualization massif-visualizer. Cet
outil va permettre de régulièrement faire des snapshots des allocations mémoires, et de voir les callstacks
des endroits de nos programme qui font ces allocations.
Dans (le futur) FreeRDP 3.0, il y a le support pour le smartcard logon, sur lequel j'ai pas mal travaillé, voyons un petit peu ce qu'il en est.
On commence par vérifier qu'on voit bien la smartcard, dans mon cas il s'agit d'un yubikey(TM):
$ opensc-tool -l # Detected readers (pcsc) Nr. Card Features Name 0 Yes Yubico YubiKey OTP+FIDO+CCID 00 00
Intéressons nous un peu plus au protocole RDPUDP qui va transporter les données RDP au
dessus d'UDP.
Pour commencer, on se souviendra que seules les données de canaux virtuels (virtual channels) peuvent être transportées
au dessus d'UDP, donc ça ne concerne pas les ordres graphiques anciens (donc si vous comptiez sur UDP pour accélérer
des bitmapUpdates c'est perdu), par contre ça fonctionnera avec un rendu egfx. De même la migration de TCP à UDP se
fait au travers du canal dynamique, donc le drdynvc est obligatoire. Ce mécanisme permet aussi aux
canaux statiques d'être migrés vers UDP en mettant le flag TRANSPORTTYPE_UDP_PREFERRED dans le paquet gcc
de multi-transport channel data.
J'ai fais quelque modifications dans winPR pour corriger un bug dans les timers avec completion, et
je suis tombé sur un soucis qui pourrait intéresser d'autres personnes que moi.
Ça concerne la gestion des EINTR, quand un appel système est interrompu par l'arrivée d'un signal,
la réponse va être un -1 et errno positionné à EINTR. Par exemple quand on fait un select ou un read, la manière de se
protéger de ce comportement, c'est de faire le code suivant:
#include <sys/select.h> #include <errno.h> void myFunction() { struct fd_set rset; int status, max_fd; ... do { ret = select(max_fd, &rset, NULL, NULL, NULL); } while (ret < 0 && errno == EINTR); }
Bon et bien problème résolu, il suffit d'appliquer ce schéma à chaque fois qu'on a un appel système non ?
poll
Celà fait quelques temps que je n'avais rien posté. Pour commencer, je vous souhaite une bonne année 2021, plein de
belles choses, des projets et puis la santé évidement ! Espérons que la Covid nous laissera un peu tranquille cette année.
Comme je travaille sur le support du transport UDP dans FreeRDP, je fais une petite série de posts sur ce sujet. On va commencer par un aperçu rapide de comment ça marche et ce que ça implique, et je rentrerais sans doute plus dans les détails dans des post suivants.
Le support UDP dans RDP est détaillé dans plusieurs fichiers de spécifications:
Un post après une longue période sans rien publier. Récemment j'ai fait beaucoup de choses
autour d'ogon, et j'ai dû déployer à la chaine sur plusieurs machines pour des tests.
Le guide de déploiement est bien, mais c'est long et répétitif, et puis
sutout si c'est consignable dans un manuel d'installation, c'est que c'est automatisable
par un script.
J'ai donc créé pour ça ce petit logiciel accendino (briquet en italien) qui va nous permettre d'allumer un grand feu (ogon en russe).