Avec l'essor des live cd et des distributions embarquées sur de nombreux
supports, je suis à la recherche de mon bonheur de paranoïaque aigue :
un systeme d'exploitation, indépendant du système d'exploitation de
l'ordinateur qu'on utilise, entièrement stocké sur une clef usb qui
serait crypté (pour éviter un montage de la clef usb et une récupération
des données sensibles).
Dans un premier temps, j'avais pensé à une ubuntu avec true crypt. Très
vite, des problèmes se posent, le systeme d'exploitation doit lui même
etre contenu sur un conteneur encrypté, deuxièment, ubuntu, je vais
passer plus de temps à défaire leur usine à gaz en croisant les doigts
que je ne vais rien oublier.
L'utilisation de l'os serait : ofimatique/ internet et connexion réseau
wifi wpa2 et authentification aux réseaux d'entreprises des utilisateurs
lambda du produit fini.
Avez-vous déjà eu ce genre de problème? L'avez-vous résolu?
un systeme d'exploitation, indépendant du système d'exploitation de l'ordinateur qu'on utilise, entièrement stocké sur une clef usb qui serait crypté (pour éviter un montage de la clef usb et une récupération des données sensibles).
Chiffrer les données sensibles, OK. Pour ça, il y a plusieurs solutions, dont encfs et Truecrypt. Mais pourquoi diable chiffrer l'OS ? C'est un truc public, personne n'ira essayer de le chercher sur ta clé USB alors qu'on peut le télécharger librement.
Donc, la solution suivante me paraît simple et sûre : une version "clé USB" normale de Linux (ça ne manque pas), avec Truecrypt installé, et les fichiers confidentiels bien au chaud dans un volume Truecrypt.
Si tu es vraiment parano, et tu as peur que quelqu'un corrompe le système sur la clé USB, tu peux utiliser un CD-R pour le système + une clé USB pour les données.
On 22 Feb 2008 21:58:46 GMT, Fred <autit29ecu8jzug@jetable.org>:
un systeme d'exploitation, indépendant du système d'exploitation de
l'ordinateur qu'on utilise, entièrement stocké sur une clef usb qui
serait crypté (pour éviter un montage de la clef usb et une récupération
des données sensibles).
Chiffrer les données sensibles, OK. Pour ça, il y a plusieurs
solutions, dont encfs et Truecrypt.
Mais pourquoi diable chiffrer l'OS ? C'est un truc public, personne
n'ira essayer de le chercher sur ta clé USB alors qu'on peut le
télécharger librement.
Donc, la solution suivante me paraît simple et sûre : une version
"clé USB" normale de Linux (ça ne manque pas), avec Truecrypt
installé, et les fichiers confidentiels bien au chaud dans un volume
Truecrypt.
Si tu es vraiment parano, et tu as peur que quelqu'un corrompe le
système sur la clé USB, tu peux utiliser un CD-R pour le système + une
clé USB pour les données.
un systeme d'exploitation, indépendant du système d'exploitation de l'ordinateur qu'on utilise, entièrement stocké sur une clef usb qui serait crypté (pour éviter un montage de la clef usb et une récupération des données sensibles).
Chiffrer les données sensibles, OK. Pour ça, il y a plusieurs solutions, dont encfs et Truecrypt. Mais pourquoi diable chiffrer l'OS ? C'est un truc public, personne n'ira essayer de le chercher sur ta clé USB alors qu'on peut le télécharger librement.
Donc, la solution suivante me paraît simple et sûre : une version "clé USB" normale de Linux (ça ne manque pas), avec Truecrypt installé, et les fichiers confidentiels bien au chaud dans un volume Truecrypt.
Si tu es vraiment parano, et tu as peur que quelqu'un corrompe le système sur la clé USB, tu peux utiliser un CD-R pour le système + une clé USB pour les données.
Fred
Bonsoir,
Chiffrer les données sensibles, OK. Pour ça, il y a plusieurs solutions, dont encfs et Truecrypt. Mais pourquoi diable chiffrer l'OS ? C'est un truc public, personne n'ira essayer de le chercher sur ta clé USB alors qu'on peut le télécharger librement.
Pour deux raisons : premièrement, car j'ai peur que l'utilisateur lambda aille enregistrer des données dans des répertoires exotiques (son home serait moins exotique bien sur mais possible),
Pour la raison deux : je vous voudrais éviter d'utiliser un cd + une clef usb, trop lourd donc, moins accessible à tous,
Fred
Bonsoir,
Chiffrer les données sensibles, OK. Pour ça, il y a plusieurs
solutions, dont encfs et Truecrypt.
Mais pourquoi diable chiffrer l'OS ? C'est un truc public, personne
n'ira essayer de le chercher sur ta clé USB alors qu'on peut le
télécharger librement.
Pour deux raisons : premièrement, car j'ai peur que l'utilisateur lambda
aille enregistrer des données dans des répertoires exotiques (son home
serait moins exotique bien sur mais possible),
Pour la raison deux : je vous voudrais éviter d'utiliser un cd + une
clef usb, trop lourd donc, moins accessible à tous,
Chiffrer les données sensibles, OK. Pour ça, il y a plusieurs solutions, dont encfs et Truecrypt. Mais pourquoi diable chiffrer l'OS ? C'est un truc public, personne n'ira essayer de le chercher sur ta clé USB alors qu'on peut le télécharger librement.
Pour deux raisons : premièrement, car j'ai peur que l'utilisateur lambda aille enregistrer des données dans des répertoires exotiques (son home serait moins exotique bien sur mais possible),
Pour la raison deux : je vous voudrais éviter d'utiliser un cd + une clef usb, trop lourd donc, moins accessible à tous,
Fred
Fabien LE LEZ
On 22 Feb 2008 22:49:12 GMT, Fred :
Pour deux raisons : premièrement, car j'ai peur que l'utilisateur lambda aille enregistrer des données dans des répertoires exotiques
Dans ce cas, la solution est simplissime : lambda n'a de droits en écriture que sur les répertoires chiffrés. Et, bien sûr, pas le droit de monter une partition du disque dur de la machine.
Mébon, un lambda non éduqué trouvera toujours le moyen de balancer des documents confidentiels n'importe où sur Internet...
Pour la raison deux : je vous voudrais éviter d'utiliser un cd + une clef usb, trop lourd donc, moins accessible à tous,
J'imagine que tu veux un chiffrage de l'OS pour éviter qu'un malfaisant installe un espion sur la clé ? Dans ce cas, ça me paraît voué à l'échec : il te faut au moins une partie non chiffrée (ne serait-ce que Grub), et cette partie est donc vulnérable. Chiffrer une partie de l'OS ou ne rien chiffrer du tout, ça revient au même.
Une solution alternative, mais qui dépend de la présence d'un réseau : un CD, pas de clé USB, mais un répertoire distant sur un serveur sécurisé, monté via sshfs.
On 22 Feb 2008 22:49:12 GMT, Fred <autit29ecu8jzug@jetable.org>:
Pour deux raisons : premièrement, car j'ai peur que l'utilisateur lambda
aille enregistrer des données dans des répertoires exotiques
Dans ce cas, la solution est simplissime : lambda n'a de droits en
écriture que sur les répertoires chiffrés. Et, bien sûr, pas le droit
de monter une partition du disque dur de la machine.
Mébon, un lambda non éduqué trouvera toujours le moyen de balancer des
documents confidentiels n'importe où sur Internet...
Pour la raison deux : je vous voudrais éviter d'utiliser un cd + une
clef usb, trop lourd donc, moins accessible à tous,
J'imagine que tu veux un chiffrage de l'OS pour éviter qu'un
malfaisant installe un espion sur la clé ?
Dans ce cas, ça me paraît voué à l'échec : il te faut au moins une
partie non chiffrée (ne serait-ce que Grub), et cette partie est donc
vulnérable. Chiffrer une partie de l'OS ou ne rien chiffrer du tout,
ça revient au même.
Une solution alternative, mais qui dépend de la présence d'un réseau :
un CD, pas de clé USB, mais un répertoire distant sur un serveur
sécurisé, monté via sshfs.
Pour deux raisons : premièrement, car j'ai peur que l'utilisateur lambda aille enregistrer des données dans des répertoires exotiques
Dans ce cas, la solution est simplissime : lambda n'a de droits en écriture que sur les répertoires chiffrés. Et, bien sûr, pas le droit de monter une partition du disque dur de la machine.
Mébon, un lambda non éduqué trouvera toujours le moyen de balancer des documents confidentiels n'importe où sur Internet...
Pour la raison deux : je vous voudrais éviter d'utiliser un cd + une clef usb, trop lourd donc, moins accessible à tous,
J'imagine que tu veux un chiffrage de l'OS pour éviter qu'un malfaisant installe un espion sur la clé ? Dans ce cas, ça me paraît voué à l'échec : il te faut au moins une partie non chiffrée (ne serait-ce que Grub), et cette partie est donc vulnérable. Chiffrer une partie de l'OS ou ne rien chiffrer du tout, ça revient au même.
Une solution alternative, mais qui dépend de la présence d'un réseau : un CD, pas de clé USB, mais un répertoire distant sur un serveur sécurisé, monté via sshfs.
Aris
Fred wrote:
Bonjour à vous,
Avec l'essor des live cd et des distributions embarquées sur de nombreux supports, je suis à la recherche de mon bonheur de paranoïaque aigue :
Selon des recherches récentes, l'espoir de conserver une partition cryptée face à un adversaire déterminé est complètement illusoire : http://www.nytimes.com/2008/02/22/technology/22chip.html?em&ex03915600&end01f43eefefaeb&eiP87%0A (l'investissement se résumé à une simple "bombe à froid")
les barrettes de RAM sont plus rémanentes que les softeux l'imaginent et celà permet de remonter aux clés de chiffrage du disque dur.
TfH
1- on dit CHIFFRÉE
2- suffit que l'os clean la mémoire au reboot de la machine. De toutes façons si un attaquant a un accès local il lui suffit de mettre un keylogger et d'attendre joyeusement que vous tapiez la clef
Fred wrote:
Bonjour à vous,
Avec l'essor des live cd et des distributions embarquées sur de nombreux
supports, je suis à la recherche de mon bonheur de paranoïaque aigue :
Selon des recherches récentes, l'espoir de conserver une partition cryptée
face à un adversaire déterminé est complètement illusoire :
http://www.nytimes.com/2008/02/22/technology/22chip.html?em&ex03915600&end01f43eefefaeb&eiP87%0A
(l'investissement se résumé à une simple "bombe à froid")
les barrettes de RAM sont plus rémanentes que les softeux l'imaginent et
celà permet de remonter aux clés de chiffrage du disque dur.
TfH
1- on dit CHIFFRÉE
2- suffit que l'os clean la mémoire au reboot de la machine. De toutes
façons si un attaquant a un accès local il lui suffit de mettre un
keylogger et d'attendre joyeusement que vous tapiez la clef
Avec l'essor des live cd et des distributions embarquées sur de nombreux supports, je suis à la recherche de mon bonheur de paranoïaque aigue :
Selon des recherches récentes, l'espoir de conserver une partition cryptée face à un adversaire déterminé est complètement illusoire : http://www.nytimes.com/2008/02/22/technology/22chip.html?em&ex03915600&end01f43eefefaeb&eiP87%0A (l'investissement se résumé à une simple "bombe à froid")
les barrettes de RAM sont plus rémanentes que les softeux l'imaginent et celà permet de remonter aux clés de chiffrage du disque dur.
TfH
1- on dit CHIFFRÉE
2- suffit que l'os clean la mémoire au reboot de la machine. De toutes façons si un attaquant a un accès local il lui suffit de mettre un keylogger et d'attendre joyeusement que vous tapiez la clef
Fabien LE LEZ
On 23 Feb 2008 08:35:17 GMT, Thierry Herbelot :
Selon des recherches récentes, l'espoir de conserver une partition cryptée face à un adversaire déterminé est complètement illusoire :
Non, le papier en question indique qu'il faut rajouter une mesure de sécurité : le vidage de la RAM comme partie de la procédure d'arrêt du système. (Bien évidemment, l'usage de swap est exclu sur un OS "sécurisé".)
On 23 Feb 2008 08:35:17 GMT, Thierry Herbelot :
Selon des recherches récentes, l'espoir de conserver une partition cryptée
face à un adversaire déterminé est complètement illusoire :
Non, le papier en question indique qu'il faut rajouter une mesure de
sécurité : le vidage de la RAM comme partie de la procédure d'arrêt du
système.
(Bien évidemment, l'usage de swap est exclu sur un OS "sécurisé".)
Selon des recherches récentes, l'espoir de conserver une partition cryptée face à un adversaire déterminé est complètement illusoire :
Non, le papier en question indique qu'il faut rajouter une mesure de sécurité : le vidage de la RAM comme partie de la procédure d'arrêt du système. (Bien évidemment, l'usage de swap est exclu sur un OS "sécurisé".)
Fabien LE LEZ
On 23 Feb 2008 21:35:16 GMT, Thierry Herbelot :
et si on arrache le cordon secteur (ou procédure équivalente pour un portable, bien sûr) ?
Pour un portable, il suffit de le voler allumé, avec les volumes Truecrypt montés, et on n'a même pas besoin d'aller chercher des clefs dans la RAM, "post-mortem".
Si tu veux protéger tes données, tu surveilles ta machine tant que l'OS sécurisé est lancé. Si on doit s'absenter, on démonte les volumes chiffrés, et on vide la RAM.
On 23 Feb 2008 21:35:16 GMT, Thierry Herbelot :
et si on arrache le cordon secteur (ou procédure équivalente pour un
portable, bien sûr) ?
Pour un portable, il suffit de le voler allumé, avec les volumes
Truecrypt montés, et on n'a même pas besoin d'aller chercher des clefs
dans la RAM, "post-mortem".
Si tu veux protéger tes données, tu surveilles ta machine tant que
l'OS sécurisé est lancé. Si on doit s'absenter, on démonte les volumes
chiffrés, et on vide la RAM.
et si on arrache le cordon secteur (ou procédure équivalente pour un portable, bien sûr) ?
Pour un portable, il suffit de le voler allumé, avec les volumes Truecrypt montés, et on n'a même pas besoin d'aller chercher des clefs dans la RAM, "post-mortem".
Si tu veux protéger tes données, tu surveilles ta machine tant que l'OS sécurisé est lancé. Si on doit s'absenter, on démonte les volumes chiffrés, et on vide la RAM.
Kevin Denis
On 2008-02-22, Fabien LE LEZ wrote:
un systeme d'exploitation, indépendant du système d'exploitation de l'ordinateur qu'on utilise, entièrement stocké sur une clef usb qui serait crypté (pour éviter un montage de la clef usb et une récupération des données sensibles).
Chiffrer les données sensibles, OK. Pour ça, il y a plusieurs solutions, dont encfs et Truecrypt.
dmcrypt, plutôt, mais bon.
Mais pourquoi diable chiffrer l'OS ? C'est un truc public, personne n'ira essayer de le chercher sur ta clé USB alors qu'on peut le télécharger librement.
Parceque les utilisateurs mettent des trucs partout. Et que si tu
veux être tranquille, tu chiffres tout. Qui te dit qu'il n'y a pas de mails sur /var/spool/mail ? Alors que tu chiffrais conscienceusement /home? Et /tmp ? Et /var/tmp?
Donc, la solution suivante me paraît simple et sûre : une version "clé USB" normale de Linux (ça ne manque pas), avec Truecrypt installé, et les fichiers confidentiels bien au chaud dans un volume Truecrypt.
Pourquoi s'arrêter à un seul volume alors que tu
peux chiffrer tout le disque sans effort. -- Kevin
On 2008-02-22, Fabien LE LEZ <gramster@gramster.com> wrote:
un systeme d'exploitation, indépendant du système d'exploitation de
l'ordinateur qu'on utilise, entièrement stocké sur une clef usb qui
serait crypté (pour éviter un montage de la clef usb et une récupération
des données sensibles).
Chiffrer les données sensibles, OK. Pour ça, il y a plusieurs
solutions, dont encfs et Truecrypt.
dmcrypt, plutôt, mais bon.
Mais pourquoi diable chiffrer l'OS ? C'est un truc public, personne
n'ira essayer de le chercher sur ta clé USB alors qu'on peut le
télécharger librement.
Parceque les utilisateurs mettent des trucs partout. Et que si tu
veux être tranquille, tu chiffres tout. Qui te dit qu'il n'y
a pas de mails sur /var/spool/mail ? Alors que tu chiffrais
conscienceusement /home? Et /tmp ? Et /var/tmp?
Donc, la solution suivante me paraît simple et sûre : une version
"clé USB" normale de Linux (ça ne manque pas), avec Truecrypt
installé, et les fichiers confidentiels bien au chaud dans un volume
Truecrypt.
Pourquoi s'arrêter à un seul volume alors que tu
peux chiffrer tout le disque sans effort.
--
Kevin
un systeme d'exploitation, indépendant du système d'exploitation de l'ordinateur qu'on utilise, entièrement stocké sur une clef usb qui serait crypté (pour éviter un montage de la clef usb et une récupération des données sensibles).
Chiffrer les données sensibles, OK. Pour ça, il y a plusieurs solutions, dont encfs et Truecrypt.
dmcrypt, plutôt, mais bon.
Mais pourquoi diable chiffrer l'OS ? C'est un truc public, personne n'ira essayer de le chercher sur ta clé USB alors qu'on peut le télécharger librement.
Parceque les utilisateurs mettent des trucs partout. Et que si tu
veux être tranquille, tu chiffres tout. Qui te dit qu'il n'y a pas de mails sur /var/spool/mail ? Alors que tu chiffrais conscienceusement /home? Et /tmp ? Et /var/tmp?
Donc, la solution suivante me paraît simple et sûre : une version "clé USB" normale de Linux (ça ne manque pas), avec Truecrypt installé, et les fichiers confidentiels bien au chaud dans un volume Truecrypt.
Pourquoi s'arrêter à un seul volume alors que tu
peux chiffrer tout le disque sans effort. -- Kevin
Kevin Denis
On 2008-02-22, Fabien LE LEZ wrote:
Pour la raison deux : je vous voudrais éviter d'utiliser un cd + une clef usb, trop lourd donc, moins accessible à tous,
J'imagine que tu veux un chiffrage de l'OS pour éviter qu'un malfaisant installe un espion sur la clé ? Dans ce cas, ça me paraît voué à l'échec : il te faut au moins une partie non chiffrée (ne serait-ce que Grub),
Pas obligatoirement. Tu as deux solutions: -mettre le noyau, l'initrd et les clés de chiffrement sur une clé USB bootable. L'user démarre son PC avec la clé et la range dès le PC démarré. C'est transparent au possible pour le user, il ne se rend compte de rien, il faut juste qu'il fasse très attention à ne pas stocker au même endroit la clé et le portable. Absolument tout est chiffré sur le PC. C'est une solution très élégante et très peu contraignante pour l'utilisateur.
-Planquer le noyau et l'initrd au début de la partition swap et utiliser lilo. Le swap saute suffisament d'espace après le noyau et l'initrd. Avant le noyau et l'initrd, de l'aléatoire pour troubler l'attaquant. C'est moins beau, ça oblige d'avoir à se souvenir d'un mot de passe mais ça évite d'avoir une clé USB. C'est assez acrobatique :) C'est mieux expliqué dans le linux magazine de janvier. En résumé: :/tmp# swapoff /dev/mapper/c_swap :/tmp# mke2fs /dev/hda3 <snip> :/tmp# mount -t ext2 /dev/hda3 /boot :/tmp# dd if=/dev/random of=/boot/remplissage bs24k count=2 (pour remplir 2Mo de données inutile, voir explication plus bas) :/tmp# cp bzImage initrd.gz /boot :/tmp# vi /etc/lilo.conf (adapter la configuration) :/tmp# lilo -v <snip> (le PC est capable désormais de booter) :/tmp# (il est temps d'écraser le filesystem) :/tmp# dd if=/dev/random of=/dev/hda3 bs24k count=2 (d'ou les 2Mo inutiles placés en début de partition, afin d'être certain d'écraser tout le filesystem sans toucher au noyau) :/tmp# losetup -o 20480000 /dev/loop0 /dev/hda3 (20 Mo sont sautés en tête de partition) :/tmp# cryptsetup -c aes -d /dev/random -s 128 create c_swap /dev/loop0 <snip> :/tmp# mkswap /dev/mapper/c_swap :/tmp# swapon /dev/mapper/c_swap -- Kevin
On 2008-02-22, Fabien LE LEZ <gramster@gramster.com> wrote:
Pour la raison deux : je vous voudrais éviter d'utiliser un cd + une
clef usb, trop lourd donc, moins accessible à tous,
J'imagine que tu veux un chiffrage de l'OS pour éviter qu'un
malfaisant installe un espion sur la clé ?
Dans ce cas, ça me paraît voué à l'échec : il te faut au moins une
partie non chiffrée (ne serait-ce que Grub),
Pas obligatoirement. Tu as deux solutions:
-mettre le noyau, l'initrd et les clés de chiffrement sur une clé USB
bootable. L'user démarre son PC avec la clé et la range dès le PC
démarré. C'est transparent au possible pour le user, il ne se rend
compte de rien, il faut juste qu'il fasse très attention à ne pas
stocker au même endroit la clé et le portable. Absolument tout
est chiffré sur le PC. C'est une solution très élégante et très
peu contraignante pour l'utilisateur.
-Planquer le noyau et l'initrd au début de la partition swap et utiliser
lilo. Le swap saute suffisament d'espace après le noyau et l'initrd. Avant
le noyau et l'initrd, de l'aléatoire pour troubler l'attaquant.
C'est moins beau, ça oblige d'avoir à se souvenir d'un mot de passe
mais ça évite d'avoir une clé USB. C'est assez acrobatique :) C'est
mieux expliqué dans le linux magazine de janvier.
En résumé:
root@slackintosh:/tmp# swapoff /dev/mapper/c_swap
root@slackintosh:/tmp# mke2fs /dev/hda3
<snip>
root@slackintosh:/tmp# mount -t ext2 /dev/hda3 /boot
root@slackintosh:/tmp# dd if=/dev/random of=/boot/remplissage bs24k count=2
(pour remplir 2Mo de données inutile, voir explication plus bas)
root@slackintosh:/tmp# cp bzImage initrd.gz /boot
root@slackintosh:/tmp# vi /etc/lilo.conf (adapter la configuration)
root@slackintosh:/tmp# lilo -v
<snip> (le PC est capable désormais de booter)
root@slackintosh:/tmp#
(il est temps d'écraser le filesystem)
root@slackintosh:/tmp# dd if=/dev/random of=/dev/hda3 bs24k count=2
(d'ou les 2Mo inutiles placés en début de partition, afin d'être
certain d'écraser tout le filesystem sans toucher au noyau)
root@slackintosh:/tmp# losetup -o 20480000 /dev/loop0 /dev/hda3
(20 Mo sont sautés en tête de partition)
root@slackintosh:/tmp# cryptsetup -c aes -d /dev/random -s 128 create c_swap /dev/loop0
<snip>
root@slackintosh:/tmp# mkswap /dev/mapper/c_swap
root@slackintosh:/tmp# swapon /dev/mapper/c_swap
--
Kevin
Pour la raison deux : je vous voudrais éviter d'utiliser un cd + une clef usb, trop lourd donc, moins accessible à tous,
J'imagine que tu veux un chiffrage de l'OS pour éviter qu'un malfaisant installe un espion sur la clé ? Dans ce cas, ça me paraît voué à l'échec : il te faut au moins une partie non chiffrée (ne serait-ce que Grub),
Pas obligatoirement. Tu as deux solutions: -mettre le noyau, l'initrd et les clés de chiffrement sur une clé USB bootable. L'user démarre son PC avec la clé et la range dès le PC démarré. C'est transparent au possible pour le user, il ne se rend compte de rien, il faut juste qu'il fasse très attention à ne pas stocker au même endroit la clé et le portable. Absolument tout est chiffré sur le PC. C'est une solution très élégante et très peu contraignante pour l'utilisateur.
-Planquer le noyau et l'initrd au début de la partition swap et utiliser lilo. Le swap saute suffisament d'espace après le noyau et l'initrd. Avant le noyau et l'initrd, de l'aléatoire pour troubler l'attaquant. C'est moins beau, ça oblige d'avoir à se souvenir d'un mot de passe mais ça évite d'avoir une clé USB. C'est assez acrobatique :) C'est mieux expliqué dans le linux magazine de janvier. En résumé: :/tmp# swapoff /dev/mapper/c_swap :/tmp# mke2fs /dev/hda3 <snip> :/tmp# mount -t ext2 /dev/hda3 /boot :/tmp# dd if=/dev/random of=/boot/remplissage bs24k count=2 (pour remplir 2Mo de données inutile, voir explication plus bas) :/tmp# cp bzImage initrd.gz /boot :/tmp# vi /etc/lilo.conf (adapter la configuration) :/tmp# lilo -v <snip> (le PC est capable désormais de booter) :/tmp# (il est temps d'écraser le filesystem) :/tmp# dd if=/dev/random of=/dev/hda3 bs24k count=2 (d'ou les 2Mo inutiles placés en début de partition, afin d'être certain d'écraser tout le filesystem sans toucher au noyau) :/tmp# losetup -o 20480000 /dev/loop0 /dev/hda3 (20 Mo sont sautés en tête de partition) :/tmp# cryptsetup -c aes -d /dev/random -s 128 create c_swap /dev/loop0 <snip> :/tmp# mkswap /dev/mapper/c_swap :/tmp# swapon /dev/mapper/c_swap -- Kevin
Thierry B\.
--{ Fabien LE LEZ a plopé ceci: }--
Non, le papier en question indique qu'il faut rajouter une mesure de sécurité : le vidage de la RAM comme partie de la procédure d'arrêt du système. (Bien évidemment, l'usage de swap est exclu sur un OS "sécurisé".)
Même un swap crypté comme peut le faire OpenBSD ?
-- MS a plutôt pour devise : nous voulons votre bien et nous l'aurons.
--{ Fabien LE LEZ a plopé ceci: }--
Non, le papier en question indique qu'il faut rajouter une mesure de
sécurité : le vidage de la RAM comme partie de la procédure d'arrêt du
système.
(Bien évidemment, l'usage de swap est exclu sur un OS "sécurisé".)
Même un swap crypté comme peut le faire OpenBSD ?
--
MS a plutôt pour devise : nous voulons votre bien et nous l'aurons.
Non, le papier en question indique qu'il faut rajouter une mesure de sécurité : le vidage de la RAM comme partie de la procédure d'arrêt du système. (Bien évidemment, l'usage de swap est exclu sur un OS "sécurisé".)
Même un swap crypté comme peut le faire OpenBSD ?
-- MS a plutôt pour devise : nous voulons votre bien et nous l'aurons.
Dominique ROUSSEAU
Le lun, 25 fév 2008 at 08:13 GMT, Thierry B. a écrit :
--{ Fabien LE LEZ a plopé ceci: }--
Non, le papier en question indique qu'il faut rajouter une mesure de sécurité : le vidage de la RAM comme partie de la procédure d'arrêt du système. (Bien évidemment, l'usage de swap est exclu sur un OS "sécurisé".)
Même un swap crypté comme peut le faire OpenBSD ?
Et s'assurer d'en écraser/vider le contenu lors de l'arret, alors.
Le lun, 25 fév 2008 at 08:13 GMT, Thierry B. <tth@prout.stex.invalid> a écrit :
--{ Fabien LE LEZ a plopé ceci: }--
Non, le papier en question indique qu'il faut rajouter une mesure de
sécurité : le vidage de la RAM comme partie de la procédure d'arrêt du
système.
(Bien évidemment, l'usage de swap est exclu sur un OS "sécurisé".)
Même un swap crypté comme peut le faire OpenBSD ?
Et s'assurer d'en écraser/vider le contenu lors de l'arret, alors.
Le lun, 25 fév 2008 at 08:13 GMT, Thierry B. a écrit :
--{ Fabien LE LEZ a plopé ceci: }--
Non, le papier en question indique qu'il faut rajouter une mesure de sécurité : le vidage de la RAM comme partie de la procédure d'arrêt du système. (Bien évidemment, l'usage de swap est exclu sur un OS "sécurisé".)
Même un swap crypté comme peut le faire OpenBSD ?
Et s'assurer d'en écraser/vider le contenu lors de l'arret, alors.
