Forum Linux.général Volume chiffré

Posté par  . Licence CC By‑SA.
Étiquettes :
4
27
juil.
2016

Bonjour,

Je voudrais stocker quelques informations dans mon $HOME et que ces informations restent privées. Or quiconque est en mesure de se connecter en root peut bien évidemment accéder à mon $HOME. Je me suis donc dit que je pouvais créer un volume chiffré (j’ai en effet moi aussi un accès root sur cette machine). Je ne l’avais jamais fait, c’est vraiment très simple.

Je vous soumets donc la méthode à laquelle je suis arrivé, pour avoir votre avis et éventuellement pouvoir y apporter des améliorations.

Tout d’abord une chose dont j’ai bien conscience c’est qu’une fois le volume chiffré ouvert, root pourra y accéder, donc ce n’est pas terrible mais si je referme systématiquement le volume ça reste quand même une protection contre le fouineur de base.

#!/usr/bin/env bash

case "$1" in

    "open")

    sudo losetup /dev/loop5 ~/stash.img
    sudo cryptsetup luksOpen /dev/loop5 stash
    sudo mount /dev/mapper/stash ~/stash
    ;;

    "close")

    sudo umount ~/stash
    sudo cryptsetup luksClose /dev/mapper/stash
    sudo losetup -d /dev/loop5
    ;;

    "pass")

    $0 open;
    $EDITOR ~/stash/pass;
    $0 close;
    ;;

    *)

    echo "Usage: secsta [open|close|pass]"
    exit 1
    ;;

esac

Je voudrais notamment connaître votre avis sur la troisième option (pass) qui ouvre le volume chiffré, lance un éditeur sur l’un des fichiers de ce volume, puis referme le volume chiffré lorsque l’on quitte l’éditeur.

Je compte aussi appeler ce script avec l’option "close" dans ~/.bash_logout car je n’ai pas de tête.

Avec cette méthode, quelle est la probabilité que root puisse accéder au fichier ~/stash/pass ? Est-ce que root peut accéder à ce fichier lorsqu’il est ouvert dans l’éditeur (je dirais oui) ?

  • # Root est root

    Posté par  . Évalué à 2. Dernière modification le 27 juillet 2016 à 15:28.

    Root peut tout faire. Il peut enregistrer les frappes du clavier pour attraper ta clé au vol, il peut remplacer le binaire de cryptsetup pour une version qui enregistre la clé, il peut faire un dump de la mémoire,…

    Si tu fais pas confiance au gens qui ont un accès root sur la machine, il faut l'utiliser en conséquence :-)

    ajout :

    Avec cette méthode, quelle est la probabilité que root puisse accéder au fichier ~/stash/pass ?

    100%

    Est-ce que root peut accéder à ce fichier lorsqu’il est ouvert dans l’éditeur (je dirais oui) ?

    Même sans super fancy tricks, le volume est monté tant que l'éditeur tourne avec pass.

    • [^] # Re: Root est root

      Posté par  . Évalué à 2. Dernière modification le 27 juillet 2016 à 16:40.

      Même sans super fancy tricks, le volume est monté tant que l'éditeur tourne avec pass

      Merci, ça me paraissait logique, je me demande pourquoi j’ai posé cette question.

      Je sais bien que root a accès à tout, qu’il peut par exemple aller lire /proc/kcore ou installer un keylogger… je cherche juste à me protéger du fouineur lambda, qui n’a déjà pas forcément connaissance des ces manipulations et dont la motivation à aller jeter un œil là où il n’a pas à le faire ne sera pas suffisante pour tenter plus que quelques ls/less

      Pour parer à l’éventuel plombage des binaires que j’utilise je suppose que je peux embarquer leur checksum dans le script et vérifier avant d’ouvrir le LUKS. Bien sûr en cas de mise à jour normale du système je pourrais avoir un faux positif…

      Pour les keyloggers, est-ce qu’il y a des techniques pour les détecter, ou au moins certains, checkrootkit peut-être ?

      Pour le dump de la RAM, je crois qu’il n’y a rien à faire… by design… Par contre chez moi là kcore affiche 128To… je ne sais pas si c’est si facile à dumper que ça. Après peut-être que quand on connaît on a qu’à dumper que certaines plages…

    • [^] # Re: Root est root

      Posté par  . Évalué à 3.

      Même sans super fancy tricks, le volume est monté tant que l'éditeur tourne avec pass.

      En fait il faudrait carrément que j’ouvre le volume chiffré, je copie le fichier en RAM pour l’édition et je ferme le volume. Quand je quitte l’éditeur j’ouvre à nouveau le volume, j’y copie le fichier et je referme… Comme ça il n’est ouvert que le temps de la lecture du fichier et le temps de son écriture finale.

  • # EncFS

    Posté par  . Évalué à 2.

    J'utilisais EncFS pour ce que tu veux faire, et de mémoire root n'a pas accès au répertoire que l'utilisateur lambda a chiffré avec EncFS.
    Une introduction à EncFS ici :
    https://doc.ubuntu-fr.org/encfs

    • [^] # Re: EncFS

      Posté par  . Évalué à 2.

      de mémoire root n'a pas accès au répertoire que l'utilisateur lambda a chiffré avec EncFS.

      Il peut, s'y j'en crois l'avertissement quand j'installe encfs (sur debian jessie) :

      According to a security audit by Taylor Hornby (Defuse Security), the current implementation of Encfs is vulnerable or potentially vulnerable to multiple types of attacks. For example, an attacker with read/write access to encrypted data might lower the decryption complexity for subsequently encrypted data without this being noticed by a legitimate user, or might use timing analysis to deduce information.
      Until these issues are resolved, encfs should not be considered a safe home for sensitive data in scenarios where such attacks are possible.

      Après, comme dit plus haut, s'il est root il peut faire ce qu'il veut de toute façon.

    • [^] # Re: EncFS

      Posté par  . Évalué à 2.

      de mémoire root n'a pas accès au répertoire que l'utilisateur lambda a chiffré avec EncFS.

      Tout comme avec LUKS, tant que le volume n’est pas ouvert et monté…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.