Arret violent quand la clef USB est retiré

Bonjour,

J’essaie de mettre en place une solution pour sécuriser une installation debian sur une clef usb.
Je m’explique :

  • Sur une clef usb (standard) j’ai installé une debian wheezy 3.2.0-4-686-pae
  • Sur cette clef se trouve une partition boot en ext4 et une partition LVM crypté contenant la partition / et swap.

ce que je souhaiterai faire c’est arrêter complètement l’ordinateur si la clef usb est retirée (intentionnellement ou pas).

Pour ce faire j’ai tenté de créer un fichier : /etc/udev/91-cle-usb.rules :
SUBSYSTEM==“block”, ACTION==“remove”, ATTRS{serial}=="…", RUN="/sbin/halt -m -d -f -i -p"

Mais il ne se passe rien.
je me suis rendu compte que l’ID ATTRS{serial}==“xxx” ou xxx correspond à l’idée récupéré avec udevadm info --name=/dev/sdb --attribute-walk du port usb et non de la clef.

De plus je ne suis pas sure que le system soit capable de lancer halt si la clef est retiré.

Quelqu’un a-t-il une idée ?
Merci

Excellente remarque. Soit mettre tout /sbin en RAM soit utiliser un appel direct du noyau pour éteindre même si perso, je ne vois pas.

EDIT
Un outil qui peut servir : udisks

EDIT 2
Tant qu’à être violent, autant faire poweroff -f. Ah pardon, pareil que halt -p -f. Il n’existe pas de -m. Était-ce -n ?

Si tu retires la clef, les systèmes de fichiers de cette clef ne pourront être fermés donc de toute façon il y aura un souci au démarrage suivant. Par aileurs, un arrêt correct arrête correctement les programmes et il est probable que des fichiers de /usr ou /lib soient lus. Enfin, les processus dormant risquent d’être en swap, celle ci étant enlevée, ils ne peuvent s’arrêtéer correctement. Bref, ton problème me parait insoluble sauf à mettre tout le système en RAM.

+1

Ou, dit plus simplement (même si c’est moins complet que la réponse de fran.b) : comment veux-tu lancer des programmes se trouvant sur la clé alors que ladite clé est déjà retirée ? :wink: (même si ces programmes ne servent “qu’à” éteindre la machine ça ne change rien, il faut quand même les lancer)

Par contre, dans le cas où tu montes ta clef en synchrone (sync), tu peux peut être modifier le noyau pour que l’arrêt soit associé au retrait de la clef, mais les objections ci dessus restent valables.

Effectivement si il est possible de mettre des binaires en mémoire ça m’intéresse (la détection de montage ou démontage et le halt), mais je ne sais pas comment on fait …

Pour le halt je pensais à un halt -n -d -f -i -p : ce qui a pour effet un arrêt immédiat électrique de l’ordinateur.

Ce n’est pas l’utilisation normal, c’est sur. Mais sachant qu’à partir du moment ou la clef est “arrachée” le system ne sert plus à rien, en vrac et irrécupérable (et on ne veut pas le récupérer). C’est pour des raisons de sécurités que je souhaite arrêter le PC. et il n’y a pas spécialement de soucis au démarrage, j’ai déjà testé l’arrachage une bonne dizaine de fois.

Justement c’est la question … :wink: Mais on peut peut-être forcer le montage de certains binaire en mémoire, ce qui permet leurs exécution même si le disque est absent. Je me dis que ce n’est pas parce que je ne sais pas le faire qu’on ne peut pas le faire…

As tu des pistes ou des liens vers des docs la-dessus ?
Le fait de l’arrêter en cas d’arrachage n’est que pour un souci de sécurité et pas pour un arrêt normalisé de la machine.

Tu es en train de réinventer les distributions live, qui montent un système minimal en RAM.
regarde à utiliser debian live directement
cdimage.debian.org/debian-cd/cur … 6/usb-hdd/

Oui mais non :slightly_smiling:
Sur cette clef où le FS est crypté via LVM, on install des softs pour une utilisation bureautique (libreoffice, openvpn, et j’en passe …) quotidienne. un live CD n’est absolument pas ce que l’on souhaite. Par contre mettre en mémoire un ou deux utilitaires pour des questions de sécurité n’est pas vraiment réinventer le livecd.

Il existe déja un projet qui fait ça, mais impossible de me rappeler le nom.
Ils mettent sur une clefs quelques softs libre, avec comme objectif la confidentialité des données et de ne laisser aucune trace sur la machine hote.
Si quelqu’un voit de quel projet il s’agit …

trouvé !
pendriveapps.com/
il y a aussi celui là, mais ne m’inspire pas confiance à priori (site trop flashy)
portableapps.com/

Note: Sur clefagreg, tout est en RAM et les données sont cryptées.

Sinon, mon idée est simple, il te suffit de faire un appel noyau à emergency_restart ou encore machine_power_off lors du retrait de la clef USB. Un petit programme C plus un évènement udev liée à ta clef devrait faire l’affaire.

Pour faire un appel noyau à emergency_restart ou machine_power_off je ne sais pas comment on fait … et pour la détection du retrait de la clef, j’ai pas pu vérifier que ça fonctionne.

Pour le programme en C ça va être dur, très dur …

Là je m’acharne sur un bug de camllight donc je ne peux t’aider… Peut être plus tard…

J’ai résolu une partie du problème :
Pour tout ce qui se trouve dans /sbin je le monte en ramfs :

  • J’ai créé un répertoire /ramfs qui se monte au démarrage (via fstab).
  • A chaque démarrage j’ai mi dans l’init un script qui copie tout ce qu’il y a dans /sbin dans /ramfs
  • J’ai changé l’ordre des paths en mettant /ramfs avant /sbin

Maintenant tout se lance via /ramfs qui est en mémoire.
je pourrai donc lancer (/ramfs/)halt -n -d -f -i -p

Il me reste à détecter l’arrachage de la clef (si quelqu’un à des idées… ??? )
… To be continued

Et bien je viens de finir …
j’ai ajouté un fichier dans /etc/udev/rules.d/XX-cle.rules :
ACTION==“remove”, ATTRS{serial}==“le_serial_de_la_clef_usb”, RUN+="/ramfs/halt -n -d -f -i -p"

Pour trouver le serial il faut faire : udevadm -a -n /dev/le_bon_disque
et dans la bonne partie récupérer le : AATRS{serial}==“xxxxxxxxxxxx”

Résultat arrêt immédiat de l’ordinateur après retrait de la clef.
Mission accomplie.

Merci de votre aide.

Bravo. Ça va sans doute inspirer d’autres personnes sur ce forum.

et en plus, c’est lié au numéro de série de la clef. On peux voir ça comme un avantage, … ou un inconvénient.

Les avantages je les vois :

  • possibilité d’utiliser d’autres clefs usb et de les enlever sans que ça s’arrête (testé)
  • Possibilité de travailler sur plusieurs ordinateurs avec la même clef sans changer la conf.

Par contre les avantages je les vois pas …
Si t’en as en exemple ? ça peut toujours servir.

tu veux dire inconvénients ?
Par exemple, si tu veux diffuser ce type d’application , il te faudra trouver une solution pour t’adapter automatiquement à la clef que tu es en train de programmer.
Et rien ne dis que toutes les clefs remontent bien un numéro de série, et si c’est le cas, qu’il est effectivement différent d’une clef à l’autre (certains fabricants font ce type d’impasse pour économiser quelques fractions de yen …)

Comment identifier de manière unique une clé USB ? Vaste question.

En gros tu as développé un Dongle pour un logiciel propriétaire qui oblige à acheter autant de fois le logiciel qu’il y a de users …