Pour l'instant c'est optionnel mais c'est une modernisation bienvenue de la gestion des $HOME. D'ailleurs contrairement n'a ce que dit l'article systemd 245 est sorti début mars.
Par contre c'est fatiguant de toujours tout rapporter a Poettering qui serait le mal voulant….. Voulant quoi d'ailleurs ?
J'ai pas encore compris ce que systemd-homed apportait par rapport au système pam ? J'ai quand même l'impression que l'intégration dans systemd est plus importante que l'intégration de systemd avec les autres systèmes.
Avec PAM, on peut déjà faire tout un tas de truc et rien n'empêche d'écrire un module pam_systemd ?
Il y a un pam_systemd_home justement. Mais je suis comme toi, je n'ai pas encore compris l'intérêt. Deux points sont présentés, le fait de pouvoir facilement transporter son home d'un système à l'autre, ce qui me semble un cas très marginal. Et le fait d'avoir un home chiffré de manière transparente (c'est le mot de passe de l'utilisateur qui déchiffre la partition). Ce qui me semble faisable dans les même conditions sans systemd-homed.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
De ce que j'ai écouté, il ne s'intéresse pour le moment qu'aux postes perso…, mais veut pouvoir changer de poste à tout moment ! Je me demande de temps en temps s'il ne court pas après MacOSX ?
J’ai vraiment du mal à comprendre la cible : un poste personnel (au sens non professionnel) sera très majoritairement unique et avec un seul utilisateur : le besoin de passer facilement d’un ordi à l’autre et de séparation entre utilisateurs est quand même limité (par rapport à du chiffrement intégral du disque).
Et en entreprise, ne pas pouvoir utiliser les méthodes d’authentification poussées comme Kerberos ou PKCS11 est franchement dommageable.
Et j'ai pas encore finit la vidéo indiquée car c'est bien fatiguant à regarder. J'en suis au passage ou il dit qu'il faut être logué localement pour pouvoir se connecté en SSH parce sinon, hic, les clefs SSH sont chiffrées… donc non utilisable par le serveur SSH !
Je ne sais pas si je vais aller au bout. Cela me semble vraiment un fatras de truc (même s'il y a de bonnes idées) à 100 lieu d'une utilisation professionnelle en entreprise si on ne peut même plus se connecter sur un compte à distance sans être dessus localement.
À mon sens, une des force de GNU/Linux est justement qu'un serveur et un ordinateur portable, c'est exactement pareil à epsilon près. Il n'y a pas 36 version comme avec MS Windows…
Si le poste est quasi mono-utilisateur, le chiffrement de surface ne fonctionne pas si mal. Il faudrait que les 10 derniers utilisateurs par exemple puisse déchiffrer le poste au boot donc injecter leur mot de passe dans luks. Je serais plus intéressé par du boulot de ce coté là pour le moment.
Je ne sais pas si je vais aller au bout. Cela me semble vraiment un fatras de truc (même s'il y a de bonnes idées) à 100 lieu d'une utilisation professionnelle en entreprise si on ne peut même plus se connecter sur un compte à distance sans être dessus localement.
C'est pour du poste de travail bien sûr.
À mon sens, une des force de GNU/Linux est justement qu'un serveur et un ordinateur portable, c'est exactement pareil à epsilon près. Il n'y a pas 36 version comme avec MS Windows…
Il n'y a aucune différence entre les distributions ? Moi je trouve que c'est une faiblesse, un serveur et un laptop c'est différent. https://xkcd.com/1200/
Si le poste est quasi mono-utilisateur, le chiffrement de surface ne fonctionne pas si mal. Il faudrait que les 10 derniers utilisateurs par exemple puisse déchiffrer le poste au boot donc injecter leur mot de passe dans luks. Je serais plus intéressé par du boulot de ce coté là pour le moment.
Le fonctionnement actuel n'est pas mauvais non. Mais il n'y a que sur mon portable Linux que j'ai un mot de passe à entrer pour déchiffrer le disque, puis un autre pour lancer ma session.
Le fonctionnement actuel n'est pas mauvais non. Mais il n'y a que sur mon portable Linux que j'ai un mot de passe à entrer pour déchiffrer le disque, puis un autre pour lancer ma session.
Parce que si tu chiffre par défaut, le jour où l'utilisateur perd son mot de passe, il perd toutes ses données.
Et pourquoi ce n'est pas optionnel par défaut, parce que le chiffrement sur les distributions que je connais se fait par défaut sur tout le disque et donc tu ne peux pas utiliser le mot de passe de l'utilisateur vu que tu as besoin de la partition pour booter.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Sur macOS, tu n'entres qu'une fois ton mot de passe pour déchiffrer le disque (chiffrement intégral) puis te connecter.
Il y a deux écrans de logins d'aspect identique dans le système : le premier est dans l'UEFI et lancé quand le disque est chiffré, le second est sur la partition système et est lancé quand le disque n'est pas chiffré.
Un laptop, quand tu te connectes à distance, c'est un serveur… Un PC fixe, si trois personnes se connectent, c'est un serveur !
En pratique, pourquoi voudrait-on avoir des comportements vraiment différent ? Chez moi, il y a pour le moment trois différences :
- la personne peut bidouiller le réseau sur un laptop (règle polkit plus cool)
- la personne ne peut pas éteindre la machine sur un serveur
- les serveurs en rack ne sont pas encore chiffrés (mais avec IPMI++, on peut aller mettre le mot de passe à distance si besoin)
Tu utilises KDE sur Debian Sparc64 en tant que rebelz42 (uid 1042) et sur du xfs, et ça doit marcher pareil sur ton GNOME 3 sur Arch x64 en tant que rebelz42 (uid 666) sur du NFS, voire sur Windows XP en tant que rebelz42 (active directory AD\rebelz42) sur partage netbios et sur un Android ARM ou un Amstrad CPC6128, ou sur Ubuntu 22.04LTS par encore sortie. Là c'est 'vraiment portable'. En pratique ça marche(rait) pour un sous-ensemble de critères OS/CPU/endianness/gestionnaire de fenêtres/système de fichiers/UID/…
Je vais regarder tes liens, mais par exemple libpam-encfs permet déjà d'avoir un volume chiffré par personne.
Ce qui m'inquiète un peu avec systemd, c'est qu'on remplace tout un tas de système et de fichier de configuration par d'autres qui sont pas plus buvable, voir parfois moins. Donc, je n'ai pas toujours l'impression qu'on y gagne en modularité.
Autre exemple, je ne maîtrise plus bien le processus de démarrage de X à l'ouverture de session mais avant, tu glissais une variable d'environnement dans un fichier sous /etc/X11/Xsession.d/ et hop, tous les processus fils en profitait. J'ai l'impression que désormais, dans la session graphique, certains processus ne dérivent plus de ce processus maître donc n'ont pas ces variables…
Je pense que c'est un très mauvaise idée de virer le shell de partout. Soit tu te conformes à ce qu'à pensé le développement, soit tu te conformes… Pas de place à l'imagination et/ou la flexibilité. On le payera plus tard ce manque de flexibilité. Cela me rappelle un certain système cette rigidité…
Par exemple, moi j'aime bien faire des if, voir dans quel groupe est une personne, ne pas faire la même chose si c'est un utilisateur local (system) ou global (LDAP)… Là, j'ai vraiment l'impression de régresser.
Je n'ai pas très bien compris.
Si aucune information n'est externalisée du $HOME et s'il est chiffré, comment ça se passe sur l'écran de login ?
On peut lister les $HOME avec les login mais quid par exemple du prénom, nom d'utilisateur ou de l'avatar ? Ou alors une petite partie du $HOME n'est pas chiffrée ?
Il y a un fichier json dans le répertoire /home (mais pas dans le répertoire /home/user qui est lui chiffré) qui contient les informations relatives au compte : groupes, ID, potentiellement ces données, etc.).
Posté par matteli .
Évalué à 1.
Dernière modification le 03 mai 2020 à 11:56.
Tout compte fait il y a un header sur une partition chiffré avec LUKS.
Dans ce header, il y a une partie libre où on peut mettre ce que l'on veut mais ce header est limité à 4Mo si j'ai bien compris.
Ça ira pour une petite image par contre pas d'écran de connexion personnalisé.
# Fatiguant
Posté par ff9097 . Évalué à 7.
Pour l'instant c'est optionnel mais c'est une modernisation bienvenue de la gestion des $HOME. D'ailleurs contrairement n'a ce que dit l'article systemd 245 est sorti début mars.
Par contre c'est fatiguant de toujours tout rapporter a Poettering qui serait le mal voulant….. Voulant quoi d'ailleurs ?
[^] # Re: Fatiguant
Posté par Sytoka Modon (site web personnel) . Évalué à 3. Dernière modification le 03 mai 2020 à 10:37.
J'ai pas encore compris ce que systemd-homed apportait par rapport au système pam ? J'ai quand même l'impression que l'intégration dans systemd est plus importante que l'intégration de systemd avec les autres systèmes.
Avec PAM, on peut déjà faire tout un tas de truc et rien n'empêche d'écrire un module pam_systemd ?
[^] # Re: Fatiguant
Posté par claudex . Évalué à 4.
Il y a un
pam_systemd_homejustement. Mais je suis comme toi, je n'ai pas encore compris l'intérêt. Deux points sont présentés, le fait de pouvoir facilement transporter son home d'un système à l'autre, ce qui me semble un cas très marginal. Et le fait d'avoir un home chiffré de manière transparente (c'est le mot de passe de l'utilisateur qui déchiffre la partition). Ce qui me semble faisable dans les même conditions sans systemd-homed.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Fatiguant
Posté par ff9097 . Évalué à 3.
Les deux gros avantages avancés c'est la portabilité du $HOME et le (dé)chiffrement à la (dé)connexion et au (dé)verrouillage.
[^] # Re: Fatiguant
Posté par ff9097 . Évalué à 3.
Plutôt à la mise en veille qu'au verrouillage en fait pardon
[^] # Re: Fatiguant
Posté par flan (site web personnel) . Évalué à 3.
Je me demande comment ce déchiffrement va pouvoir fonctionner pour les authentifications sans mot de passe (par exemple via Kerberos).
[^] # Re: Fatiguant
Posté par Sytoka Modon (site web personnel) . Évalué à 2. Dernière modification le 04 mai 2020 à 19:15.
De ce que j'ai écouté, il ne s'intéresse pour le moment qu'aux postes perso…, mais veut pouvoir changer de poste à tout moment ! Je me demande de temps en temps s'il ne court pas après MacOSX ?
[^] # Re: Fatiguant
Posté par flan (site web personnel) . Évalué à 3.
J’ai vraiment du mal à comprendre la cible : un poste personnel (au sens non professionnel) sera très majoritairement unique et avec un seul utilisateur : le besoin de passer facilement d’un ordi à l’autre et de séparation entre utilisateurs est quand même limité (par rapport à du chiffrement intégral du disque).
Et en entreprise, ne pas pouvoir utiliser les méthodes d’authentification poussées comme Kerberos ou PKCS11 est franchement dommageable.
[^] # Re: Fatiguant
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Et j'ai pas encore finit la vidéo indiquée car c'est bien fatiguant à regarder. J'en suis au passage ou il dit qu'il faut être logué localement pour pouvoir se connecté en SSH parce sinon, hic, les clefs SSH sont chiffrées… donc non utilisable par le serveur SSH !
Je ne sais pas si je vais aller au bout. Cela me semble vraiment un fatras de truc (même s'il y a de bonnes idées) à 100 lieu d'une utilisation professionnelle en entreprise si on ne peut même plus se connecter sur un compte à distance sans être dessus localement.
À mon sens, une des force de GNU/Linux est justement qu'un serveur et un ordinateur portable, c'est exactement pareil à epsilon près. Il n'y a pas 36 version comme avec MS Windows…
Si le poste est quasi mono-utilisateur, le chiffrement de surface ne fonctionne pas si mal. Il faudrait que les 10 derniers utilisateurs par exemple puisse déchiffrer le poste au boot donc injecter leur mot de passe dans luks. Je serais plus intéressé par du boulot de ce coté là pour le moment.
[^] # Re: Fatiguant
Posté par ff9097 . Évalué à 1.
C'est pour du poste de travail bien sûr.
Il n'y a aucune différence entre les distributions ? Moi je trouve que c'est une faiblesse, un serveur et un laptop c'est différent. https://xkcd.com/1200/
Le fonctionnement actuel n'est pas mauvais non. Mais il n'y a que sur mon portable Linux que j'ai un mot de passe à entrer pour déchiffrer le disque, puis un autre pour lancer ma session.
[^] # Re: Fatiguant
Posté par claudex . Évalué à 3.
Si ce n'est que ça, c'est déjà possible https://wiki.archlinux.org/index.php/Dm-crypt/Mounting_at_login
Autant, je suis un grand fan de systemd pour la partie init. Autant, là je ne vois toujours pas l'intérêt.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Fatiguant
Posté par ff9097 . Évalué à 1.
Pourquoi ce n'est pas par défaut ? Et puis les script bash custom….
[^] # Re: Fatiguant
Posté par claudex . Évalué à 4.
Parce que si tu chiffre par défaut, le jour où l'utilisateur perd son mot de passe, il perd toutes ses données.
Et pourquoi ce n'est pas optionnel par défaut, parce que le chiffrement sur les distributions que je connais se fait par défaut sur tout le disque et donc tu ne peux pas utiliser le mot de passe de l'utilisateur vu que tu as besoin de la partition pour booter.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Fatiguant
Posté par flan (site web personnel) . Évalué à 2.
Sur macOS, tu n'entres qu'une fois ton mot de passe pour déchiffrer le disque (chiffrement intégral) puis te connecter.
Il y a deux écrans de logins d'aspect identique dans le système : le premier est dans l'UEFI et lancé quand le disque est chiffré, le second est sur la partition système et est lancé quand le disque n'est pas chiffré.
[^] # Re: Fatiguant
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Un laptop, quand tu te connectes à distance, c'est un serveur… Un PC fixe, si trois personnes se connectent, c'est un serveur !
En pratique, pourquoi voudrait-on avoir des comportements vraiment différent ? Chez moi, il y a pour le moment trois différences :
- la personne peut bidouiller le réseau sur un laptop (règle polkit plus cool)
- la personne ne peut pas éteindre la machine sur un serveur
- les serveurs en rack ne sont pas encore chiffrés (mais avec IPMI++, on peut aller mettre le mot de passe à distance si besoin)
Sinon, de mémoire, tout le reste est identique.
[^] # Re: Fatiguant
Posté par GnunuX (site web personnel) . Évalué à 3.
C'est vrai qu'il n'y avait pas pensé …
[gnunux@localhost ~]$ rpm -qa systemd-pam
systemd-pam-243.8-1.fc31.x86_64
Le chiffrement du répertoire HOME (et pas de la partition), la possibilité d'avoir un HOME vraiment portable entre plusieurs systèmes, …
Si tu es vraiment intéressé je t'invite à voir une conf de lennart sur le sujet : https://invidious.fdn.fr/watch?v=ZwjzfdLJtX4
[^] # Re: Fatiguant
Posté par ff9097 . Évalué à 2.
et une autre du FOSDEM
[^] # Re: Fatiguant
Posté par mahikeulbody . Évalué à 4.
C'est quoi un home vraiment portable entre plusieurs systèmes ?
(c'est une vraie question d'ignare sur le sujet)
[^] # Re: Fatiguant
Posté par mahikeulbody . Évalué à -1.
Bon, il suffit de regarder les liens en fait, désolé.
[^] # Re: Fatiguant
Posté par Benoît Sibaud (site web personnel) . Évalué à 6. Dernière modification le 03 mai 2020 à 11:34.
Tu utilises KDE sur Debian Sparc64 en tant que rebelz42 (uid 1042) et sur du xfs, et ça doit marcher pareil sur ton GNOME 3 sur Arch x64 en tant que rebelz42 (uid 666) sur du NFS, voire sur Windows XP en tant que rebelz42 (active directory AD\rebelz42) sur partage netbios et sur un Android ARM ou un Amstrad CPC6128, ou sur Ubuntu 22.04LTS par encore sortie. Là c'est 'vraiment portable'. En pratique ça marche(rait) pour un sous-ensemble de critères OS/CPU/endianness/gestionnaire de fenêtres/système de fichiers/UID/…
[^] # Re: Fatiguant
Posté par GnunuX (site web personnel) . Évalué à 3.
L'UID fait est forcement identique parce que associé au home : https://systemd.io/USER_RECORD/
Je ne vois pas bien le problème, puisque le home n'est qu'un fichier au final.
Mais oui, il faut homectl sur ta distribution pour que ca soit fonctionnel.
Lennard parle de "migratable home directory" si tu préfère.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Fatiguant
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Je vais regarder tes liens, mais par exemple
libpam-encfspermet déjà d'avoir un volume chiffré par personne.Ce qui m'inquiète un peu avec
systemd, c'est qu'on remplace tout un tas de système et de fichier de configuration par d'autres qui sont pas plus buvable, voir parfois moins. Donc, je n'ai pas toujours l'impression qu'on y gagne en modularité.Autre exemple, je ne maîtrise plus bien le processus de démarrage de X à l'ouverture de session mais avant, tu glissais une variable d'environnement dans un fichier sous
/etc/X11/Xsession.d/et hop, tous les processus fils en profitait. J'ai l'impression que désormais, dans la session graphique, certains processus ne dérivent plus de ce processus maître donc n'ont pas ces variables…[^] # Re: Fatiguant
Posté par Anonyme . Évalué à 3.
Si tu utilises systemd, tu as les dossiers
environment.d.[^] # Re: Fatiguant
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
Ok, je ne connaissais pas, je vais essayé. Cependant, d'après https://www.freedesktop.org/software/systemd/man/environment.d.html,
No other elements of shell syntax are supported. Donc en gros, pas de shell dans ce fichier… Cela limite quand même pas mal les choses.Je pense que c'est un très mauvaise idée de virer le shell de partout. Soit tu te conformes à ce qu'à pensé le développement, soit tu te conformes… Pas de place à l'imagination et/ou la flexibilité. On le payera plus tard ce manque de flexibilité. Cela me rappelle un certain système cette rigidité…
Par exemple, moi j'aime bien faire des if, voir dans quel groupe est une personne, ne pas faire la même chose si c'est un utilisateur local (system) ou global (LDAP)… Là, j'ai vraiment l'impression de régresser.
# Comment ça marche ?
Posté par matteli . Évalué à 1.
Je n'ai pas très bien compris.
Si aucune information n'est externalisée du $HOME et s'il est chiffré, comment ça se passe sur l'écran de login ?
On peut lister les $HOME avec les login mais quid par exemple du prénom, nom d'utilisateur ou de l'avatar ? Ou alors une petite partie du $HOME n'est pas chiffrée ?
[^] # Re: Comment ça marche ?
Posté par Renault (site web personnel) . Évalué à 3.
Il y a un fichier json dans le répertoire /home (mais pas dans le répertoire /home/user qui est lui chiffré) qui contient les informations relatives au compte : groupes, ID, potentiellement ces données, etc.).
[^] # Re: Comment ça marche ?
Posté par matteli . Évalué à 3.
Dans ce cas, le $HOME seul n'est pas portable.
[^] # Re: Comment ça marche ?
Posté par matteli . Évalué à 1. Dernière modification le 03 mai 2020 à 11:56.
Tout compte fait il y a un header sur une partition chiffré avec LUKS.
Dans ce header, il y a une partie libre où on peut mettre ce que l'on veut mais ce header est limité à 4Mo si j'ai bien compris.
Ça ira pour une petite image par contre pas d'écran de connexion personnalisé.
[^] # Re: Comment ça marche ?
Posté par ff9097 . Évalué à 1.
La configuration de l'écran de connexion est au niveau système vu qu'il s'affiche avant la connexion utilisateur
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.