Bonjour à tous,
Je souhaiterai mettre en place la chose suivante: lors de la saisie du mot de passe (en mode graphique idéalement, mais je n'aurai rien contre la même chose en mode console), pour un même utilisateur, que 2 mot de passe soient valides, et ouvrent 2 sessions différentes :
l'utilisateur se logue sous Paul avec le mot de passe 123456, celui ouvre son KDE, avec un /home/Paul et ces documents
l'utilisateur se logue toujours sous Paul, mais saisi un mot de passe différent (par exemple: secretaccess), cela lui ouvre un gnome (ou un kde avec une autre présentation/configuration), avec un /home/Paul différent de celui qui avait quand il avait ouvert avec le 1er mot de passe.
L'idée étant de rendre invisible le processus, et d'obtenir un fonctionnement un peu comme TrueCrypt peut le faire sur l'ouverture d'un fichier archive, en ouvrant par le début de l'archive si on fournie un mot de passe A, ou en ouvrant par la fin de l'archive si on l'ouvre en soumettant un mot de passe B.
Comment essayeriez vous de mettre ça en place ? Pensez vous que c'est réalisable ?
Je me demande si la crypto du home drive utilisateur peut servir dans ce cas a réaliser le hook (mais il me semble que le cryptage est sur l'ensemble du /home, par sur un utilisateur spécifique), si le fichier /etc/password peut contenir 2 entrée avec le même login et si le hook peut se faire à ce niveau)
Merci d'avance pour vos idées
# Oui
Posté par chimrod (site web personnel) . Évalué à 1.
Il fut un temps où GDM avait des scripts à appliquer avant/après le login. Je ne sais pas si cela existe encore, mais les scripts se trouvaient dans :
/etc/gdm/PreLogin/Default
/etc/gdm/PostLogin/Default
Je m'en étais servi pour déchiffrer la partition home au moment du login de l'utilisateur. Cela doit également être disponible sur les autres outils de connexion…
[^] # Re: Oui
Posté par snurpsss . Évalué à 1.
Je vois (et ai trouvé sur internet) les script dont tu parles, mais ca ne permet pas le hook selon le mot de passe utilisé pour le même utilisateur
[^] # Re: Oui
Posté par chimrod (site web personnel) . Évalué à 4.
En fait je pensais à mettre en place un script qui testerai le mot de passe, en fonction :
Il y a du script à faire, mais ça permet déjà d'avoir un moyen d'intercepter la demande de connexion avant qu'elle ne soit transmise au système.
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
# Gestion des droits
Posté par ptit_poulet . Évalué à 2.
Je ne vois pas trop comment le système va gérer la partie droit, car tu veux 2 comptes différents mais avec le même utilisateur… va y avoir conflit.
[^] # Re: Gestion des droits
Posté par Atem18 (site web personnel) . Évalué à 2.
Y'a pas moyen avec des alias ?
[^] # Re: Gestion des droits
Posté par ptit_poulet . Évalué à 0.
Oui mais un alias c'est par exemple pour le login "paul", je peux utiliser l'alias "julien" qui est en fait le login "paul".
[^] # Re: Gestion des droits
Posté par Atem18 (site web personnel) . Évalué à 2.
Oui, c'est vrai.
# Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: PAM
Posté par snurpsss . Évalué à 1.
merci ! en effet une lecture en diagonal du wiki français (et mon petit doigt) me dit que l'on doit pouvoir faire quelquechose… quite a modifier les sources d'un module pour obtenir une sorte de hook.
Précision, je cherche a faire cette manip pour ma machine, pas pour pirater un tier en y insérant une back door au niveau de l'autentification pam…. je vais creusé par là, peut etre qu'en jouant avec des entrées partiellements identiques coté ldap….
# ca me semble compliqué
Posté par NeoX . Évalué à 3.
pourquoi un LOGIN unique et 2 mots de passe, avec tous les problemes que cela va te creer comme :
- differencier si c'est Login/123456 ou Login/SecretPass qui est actuellement connecté
- gerer les droits qu'aura l'utilisateur Login/123456 par rapport à l'utilisateur Login/SecretPass.
alors que la logique voudrait que cela soit plutot que 2 LOGINs et 2 mots de passe.
[^] # Re: ca me semble compliqué
Posté par Yves Bourguignon . Évalué à 4.
ou 2 login et 1 mot de passe commun
[^] # Re: ca me semble compliqué
Posté par snurpsss . Évalué à 1.
Ta question amène les mêmes réponses à "pourquoi truecrypt permet selon le mot de passe fournie de donner accès a des données différentes du même container" … selon si l'on veux pouvoir cacher certaines choses à certaines personnes, ce genre de chose est forte agréable (la paranoi du demandeur est satisfaite, il a accès a ce qu'il souhaite, mais ne sait pas que vous l'avez redirigé vers une zone sans interets.
L'utilisateur aura les mêmes droits dans les 2 cas, mais les fichiers de configuration, données etc, seront séparés et cachés au quidam moyen. L'objectif idéal serait d'obtenir que l'on ne puisse même pas détecter la présence de la 2nde configuration (partition crypté / zone réservée) mais on verra toujours l espace disque utilisé….
[^] # Re: ca me semble compliqué
Posté par NeoX . Évalué à 2.
pourquoi ne pas faire un /home/user dans un container truecrypt ?
qui s'active au demarrage (avant la session graphique)
# encfs et unionfs
Posté par briaeros007 . Évalué à 2.
Bonjour,
Je dis peut être une idiotie, mais il est possible d'avoir des répertoire encfs de ne s'ouvrir au démarrage de la sessin avec le mot de passe de l'utilisateur.
Donc l'idée serait de profiter de cette possibilité
123456 -> encfs pas ouvert , unionfs /.config (ou je sais pas quoi) /.encfs/config inopérant
secretpass -> encfs ouvert unionfs /.config (ou je sais pas quoi) /.encfs/config effectif.
Ensuite je ne sais pas si c'est possible, ou si ca répond à ta question (car on utilise le même /home/ , mais l'un a des répertoire en plus)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.