GuiGui's Show

Dans un annuaire LDAP genre OpenLDAP, l'attribut « userPassword » est multi-valué (plusieurs valeurs), cf le RFC 2829.

Il est donc possible d'avoir plusieurs mots de passe pour un même utilisateur.

Une application qui fait de l'authentification LDAP effectue une seule requête BIND et le serveur LDAP itère sur l'ensemble des attributs userPassword pour tester le mot de passe, donc le comportement ne dépend pas de l'application. (Évidemment, y'a toujours des applications qui tentent d'authentifier un utilisateur sur un annuaire LDAP sans faire de BIND, genre en récupérant l'attribut userPassword, dont le comportement face à plusieurs mots de passe est imprévisible).

Quand on veut diagnostiquer une authentification ou une autorisation (droits dans un logiciel / site web) sans connaître le mot de passe de l'utilisateur qui se plaint d'un problème, sans lui réinitialiser son mot de passe et sans mettre en place tout un processus pour qu'il se rende disponible pour reproduire le problème devant toi, il suffit donc d'ajouter une valeur supplémentaire l'attribut « userPassword ». L'utilisateur continuera d'utiliser son mot de passe et toi, tu utiliseras celui que t'as ajouté. Quand t'as terminé, tu retires ton mot de passe additionnel.

C'est, pour moi, l'équivalent adminsys des frameworks web genre Symfony qui permettent de se faire passer pour un utilisateur et d'obtenir ainsi les mêmes droits.

Si t'as une VM Aruba Mobility Master v8.6 (ArubaOS) sur un hyperviseur Proxmox + KVM, convertie depuis l'image disque VMWare livrée par Aruba, il faut la configurer pour utiliser le chipset q35 (au lieu de i440fx par défaut) sinon l'interface web Aruba freezera très régulièrement (affichage partiel + aucune réaction aux clics dans les menus).

J'ai aucune idée de la fonctionnalité du chipset q35 dont ArubaOS a besoin (PCI-E ? :D Secure Boot ? :D AHCI ? vIOMMU ?).

Je rappelle qu'il faut également choisir un modèle de CPU qui prend en charge les instructions SSSE3 sinon Aruba Mobility master ne démarre pas.

Sur notre parc Ubuntu 20.04, chromium ne fonctionne pas. Chromium est installé avec snap. L'ensemble pose deux problèmes :

• Le profil AppArmor livré ne prend pas en charge les homedirs situés ailleurs que dans /home/ et/ou montés en NFS (non, il ne suffit pas de configurer les variables dans /etc/apparmor.d/tunables/home.d, lire ci-dessous pour les détails) ;
  
  
• Indépendamment d'AppArmor (le désactiver ne résout pas le problème), snap ne semble pas gérer des homedirs (dossier personnel) montés en NFS. Voir : https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552 et https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1884299.

On notera également que le dossier Téléchargements se trouve dans ~/snap/chromium/current/Téléchargements. Super pratique pour un utilisateur !

Au final, on a installé Google Chrome (qui n'est pas diffusé via snap) et basta. :( On a autre chose à faire que de compiler chromium régulièrement depuis les sources et on n'a pas trouvé de dépôt apt à jour et de confiance (ce qui permettrait de nous passer de snap).

Démarche (tests effectués) et découverte d'AppArmor :

• Chemin vers homedir = /home/$uid + absence de NFS : chromium démarre ;

• Chemin vers homedir = /home/$uid + NFS : chromium ne démarre pas, erreur « cannot open path of the current working directory: Permission denied » ;

  • cd /tmp/ && chromium-browser : chromium démarre (+ snap écrit dans $HOME/snap ! Je croyais que t'arrivais pas à y accéder ?!) ;
• Chemin vers homedir = /home/$nas/$categorie/$uid + NFS : même comportement et même erreur ;
  • cd /tmp && chromium-browser : chromium ne démarre pas, erreur « cannot create user data directory: /home/$nas/$categorie/$uid/snap/chromium/1753: Permission denied ». En fonction de la configuration d'AppArmor (voir ci-dessous), l'erreur peut aussi être « cannot create user data directory: /home/$nas/$categorie/$uid/snap/chromium/1753: Stale file handle ».

Le dernier point est lié au profil AppArmor /var/lib/snapd/apparmor/profiles/snap-confine.snapd.12883.

• Si je désactive totalement AppArmor (ajouter apparmor=0 dans GRUB_CMDLINE_LINUX_DEFAULT dans /etc/default/grub puis lancer update-grub2 puis redémarrer), je n'ai plus de problème pour lancer chromium depuis /tmp (ou autre endroit sans NFS). Sur le web, on lit que la commande systemctl disable apparmor et un redémarrage permettent de désactiver AppArmor : ce n'est pas exact ;
  
  
• Si je passe le profil en mode complain (geindre dans les journaux sans rien bloquer), chromium démarre toujours quand pwd = /tmp. Comme le profil n'est pas dans /etc/apparmor.d, la commande aa-complain /snap/snapd/12883/usr/lib/snapd/snap-confine sort en erreur « Profile for /snap/snapd/12883/usr/lib/snapd/snap-confine not found, skipping » (idem avec « /var/lib/snapd/apparmor/profiles/snap-confine.snapd.12883 »). Pour passer outre : ln -s /var/lib/snapd/apparmor/snap-confine.snapd.12883 /etc/apparmor.d/ && aa-complain /snap/snapd/12883/usr/lib/snapd/snap-confine. Quid de la pérennité ? « 12883 » dans le nom du profil est la révision de snapd… qui changera lors des mises à jours… ;
  
  
• Si je passe le profil en mode complain, je m'aperçois qu'AppArmor empêche snap d'accéder à /home/ et /home/$nas en lecture ainsi que d'envoyer des messages réseau pour accéder à notre NAS en NFS. Pour débrayer le premier problème, il faut ajouter les lignes /home/ r, et /home/$nas/ r, dans le profil. Pour NFS, il faut ajouter une ligne network, dans le profil. Puis je recharge le profil avec apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap-confine.snapd.12883 (on lit souvent que systemctl reload apparmor fait le job, mais c'est incorrect). Quid de la pérennité ? « 12883 » dans le nom du profil est la révision de snapd, donc le nom du profil (et/ou son contenu) changera lors des mises à jours… ;
  
  
• Il est vain de désactiver le profil (ln -s /var/lib/snapd/apparmor/profiles/snap-confine.snapd.12883 /etc/apparmor.d/disable/ + reboot), le lancement de chromium génerera l'erreur « snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks » ;
  
  
• Il n'est pas possible de désinstaller AppArmor car snapd dépend de lui et chromium dépend de snapd…