Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Pages : 1
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Hors ligne
Attention : je ne me souviens pas si j'ai déjà utilisé ça sous Debian dans ce contexte. Je ne vois pas ce qui ferait que ça ne fonctionne pas, mais vérifie avant de taper ton mot de passe !
Moralité de l'histoire : la sécurité informatique commence par interdire tout accès physique aux machines par des personnes non autorisées !
Hors ligne
salut, sinon tu peux essayer ca : https://wiki.debian-fr.xyz/Modifier,_r% … s_de_perte
J'ai jamais testé (...si ca marche) mais ca devrait t'aider...
Ça marche si on n'a pas configuré GRUB pour empêcher la modification des entrées de menu ou l'entrée dans son shell. Mais personnellement je préfère mettre init=/bin/bash plutôt que /bin/sh qui pointe vers dash depuis quelques versions de Debian. bash est quand même beaucoup plus convivial que dash comme shell interactif.
Dernière modification par raleur (23-10-2019 08:44:00)
Il vaut mieux montrer que raconter.
Hors ligne
Ça marche si on n'a pas configuré GRUB pour empêcher la modification des entrées de menu ou l'entrée dans son shell.
Oui, pas pensé à ça (que je ne fais jamais - pas grand intérêt AMHA puisqu'il suffit d'utiliser un système live), merci pour la précision !
Mais personnellement je préfère mettre init=/bin/bash plutôt que /bin/sh qui pointe vers dash depuis quelques versions de Debian.
Bonne idée que je vais mettre en pratique 
Je comprends mal l'intérêt que trouvent les dev de Debian à faire pointer vers dash ?
Et du coup, on a tout intérêt à revoir tous les scripts qui débutent par
ou au moins de prendre la bonne habitude d'utiliser
même si dans un script, l'interactivité est peu importante.
Hors ligne
pas grand intérêt AMHA puisqu'il suffit d'utiliser un système live
Ça a un intérêt si combiné à la mise en place d'un mot de passe dans le BIOS/UEFI pour restreindre l'amorçage sur un support amovible.
Je comprends mal l'intérêt que trouvent les dev de Debian à faire pointer vers dash ?
Plus léger, plus rapide et plus sûr, moins de failles, meilleur respect de la norme POSIX, donc préférable en tant que shell non interactif pour exécuter des scripts. Bash reste le shell interactif par défaut associé aux utilisateurs.
Et du coup, on a tout intérêt à revoir tous les scripts qui débutent par#!/bin/sh ou au moins de prendre la bonne habitude d'utiliser #!/bin/bash
On a tout intérêt si possible à laisser #!bin/sh et à supprimer les "bashismes", ce qui assure une meilleure compatibilité avec n'importe quel shell compatible POSIX et donc une meilleure portabilité.
Il vaut mieux montrer que raconter.
Hors ligne
ton cas est loin d'être exceptionnel et le nombre de gens qui m'ont appelé au secours pour cela assez impressionnant !
Haha, je suis rassuré de ne pas être le seul alors!
Merci à tous pour vos réponses, je vais voir ça ce soir
Hors ligne
Merci pour ces observations un peu plus réfléchies que les miennes !
Hors ligne
dans /etc/initramfs-tools/initramfs.conf et reconstruire l'initramfs avec
A noter que cette option est implicitement activée quand la racine est chiffrée, ce qui permet de taper la passphrase de déchiffrement avec la bonne disposition de clavier.
Dernière modification par raleur (23-10-2019 16:24:32)
Il vaut mieux montrer que raconter.
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
jibe a écrit :pas grand intérêt AMHA puisqu'il suffit d'utiliser un système live
Ça a un intérêt si combiné à la mise en place d'un mot de passe dans le BIOS/UEFI pour restreindre l'amorçage sur un support amovible..
Effort louable démonté d'un coup de tournevis bien placé 
À priori je serai poussé à croire que la seule défense fiable serait de chiffrer le système, non ?
Dernière modification par otyugh (23-10-2019 19:18:38)
En ligne
Effort louable démonté d'un coup de tournevis bien placé
C'est-à-dire ?
À priori je serai poussé à croire que la seule défense fiable serait de chiffrer le système, non ?
Défense contre quoi ?
Il vaut mieux montrer que raconter.
Hors ligne
otyugh a écrit :Effort louable démonté d'un coup de tournevis bien placé
C'est-à-dire ?
Démonter le disque dur et le mettre dans un autre ordi.
À priori je serai poussé à croire que la seule défense fiable serait de chiffrer le système, non ?
Défense contre quoi ?
Quelqu'un qui veut changer le mot de passe / ou se logger en root, je pensais qu'on parlait de ça.
Dernière modification par otyugh (23-10-2019 20:11:04)
En ligne
À priori je serai poussé à croire que la seule défense fiable serait de chiffrer le système, non ?
Pour une solution logicielle, certainement.
Il y a aussi le bon vieux verrou interdisant l'accès aux machines à toute personne non autorisée. C'est souvent le plus simple à mettre en oeuvre (mais qui ne résiste pas à quelques kilos de TNT, effectivement. Reste à savoir dans quel état sera le disque après ).
Hors ligne
Démonter le disque dur et le mettre dans un autre ordi.
Cela nécessite que le boîtier de l'unité centrale soit physiquement accessible dans des conditions de discrétion suffisantes, et non verrouillé.
À priori je serai poussé à croire que la seule défense fiable serait de chiffrer le système, non ?
Le système ne peut pas être totalement chiffré. Dans une installation réalisée avec l'installateur Debian, /boot n'est pas chiffré donc avec un accès physique le chargeur d'amorçage, le noyau ou l'initramfs pourraient être altérés pour intercepter la passphrase discrètement. On peut chiffrer /boot après coup si le chargeur est GRUB 2, mais cela laisse encore une partie de GRUB non chiffrée donc susceptible d'être compromise. La protection contre cela passe par des métriques de boot avec puce TPM ou le secure boot.
Le verrouillage du disque par un mot de passe à taper (ATA Security Feature Set) via le BIOS est une autre protection. A double tranchant cependant : si on perd le mot de passe, le disque est définitivement inutilisable.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Pages : 1