Bonsoir,
Je viens vers vous avec quelques petites questions.
Je vais d'abord vous présenter ce que j'aimerai réaliser et donc trouver les solutions adéquates.
J'aimerai pouvoir mettre à disposition d'utilisateur une installation toute prête pour Raspeberry Pi pour faire office de hotspot. Le problème est que je ne veux pas que les utilisateurs puissent aller fouiller dans les fichiers et donc voir et/ou modifier certaines choses.
Je me suis donc dis que chiffrer le système serait le plus simple, mais le soucis est qui dit chiffrement dit qu'au démarrage l'utilisateur va devoir rentrer un mot de passe et donc s'il a ce mot de passe le chiffrement ne sert plus à rien (ou alors il existe une astuce que je connais pas).
Autre idée, plutôt que de chiffrer le système, pourquoi ne pas chiffrer que le /home et faire pointer mes différents logiciels vers des fichiers de confs stockés sur le /home. Problème, je ne suis pas sûr que le tout soit sans faille ou combine pour réussir à récupérer ce qui est sur le /home.
Si vous avez des idées, suggestions, je suis preneur.
Merci d'avance.
# Peut-être impossible
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 6.
Salut,
À mon sens, ce que tu demandes est impossible : le système a besoin d'avoir accès en clair aux fichiers pour fonctionner. Donc l'utilisateur aura accès en clair aux fichiers, à un moment ou à un autre.
Cela dit, si on me propose une installation toute prête en me disant que ce n'est pas "open source", je refuse d'installer le truc : on ne sait pas ce que ça pourrait faire dans notre dos…
Pourquoi vouloir cacher ce que tu proposes ?
[^] # Re: Peut-être impossible
Posté par ptit_poulet . Évalué à 1.
Bonjour,
Alors je veux empêcher l'utilisateur de pouvoir modifier l'installation pour une chose toute simple.
Je ne veux pas que l'utilisateur puisse ajouter de quoi espionner les connexions des utilisateurs qui se connecteraient sur le hotspot.
Je me creuse donc la tête pour trouver une solution pour que le système garde son intégrité.
[^] # Re: Peut-être impossible
Posté par totof2000 . Évalué à 4.
Ben .. un truc tout bête : ne pas donner le mdp root à l'utilisateur ?
[^] # Re: Peut-être impossible
Posté par ptit_poulet . Évalué à 2.
Ne pas donner le mot de passe root n'empêchera pas l'utilisateur de le remplacer directement depuis un autre système en lisant la carte SD.
[^] # Re: Peut-être impossible
Posté par totof2000 . Évalué à 2.
OK, je commence à comprendre l'idée d chiffrage, et pourquoi ça ne marchera pas. Dans ce cas, tu peux peut-être essayer de mettre en place un système qui a chaque démarrage, ira downloader l'OS sur un serveur distant. Comme ça tu contrôles ce qui est downloadé et lancé. Par contre ça risque d'être un peu long ….
[^] # Re: Peut-être impossible
Posté par ptit_poulet . Évalué à 1.
J'avais pensé aussi à un système qui soit effectivement copie les données depuis un serveur externe, ou va les chercher depuis une partition chiffrée et les copie sur une partition placée dans la ram.
Comme ça à chaque démarrage il n'y a plus rien.
[^] # Re: Peut-être impossible
Posté par gouttegd . Évalué à 5.
Un tel système ne pourrait pas être libre. D’après moi ce que tu cherches contrevient directement à la « liberté 0 », la liberté d’utiliser le programme pour tous les usages.
Peu importe la cause (elle peut être noble ou abjecte), si tu interdis certains usages à tes utilisateurs, on ne parle plus de logiciels libres.
Et du coup, selon les licences de ce que tu comptes mettre dans ton « installation toute prête pour Raspberry Pi », il n’est pas sûr que tu aies le droit de la redistribuer.
[^] # Re: Peut-être impossible
Posté par ptit_poulet . Évalué à 1.
Je ne compte pas créer un logiciel. Je veux juste que les paramètres utilisés sur l'installation ne puisse pas être modifié par une personne tierce afin de détourner l'utilisation de base.
Le but étant de fournir un service que je met à disposition tout en étant sûr qu'il n'y est pas des intermédiaires frauduleux. Mais peut-être qu'il faut que je repense mon idée de base.
[^] # Re: Peut-être impossible
Posté par gouttegd . Évalué à 2.
OK, j’avais mal compris ce que tu voulais dire par « installation toute prête » — je pensais que tu parlais de créer une sorte de distribution clef-en-main pour quiconque voudrait utiliser un Raspberry Pi comme hotspot.
En fait, tu parles d’une installation unique sur une de tes machines, c’est ça ? Et tu ne veux pas que les utilisateurs du hotspot puissent modifier cette installation ?
S’ils ont un accès physique au Raspberry Pi (ce qui devrait être le cas vu que tu parles plus haut d’accèder à la carte SD via un autre système), en gros c’est mort. Tu peux probablement rendre la tâche suffisamment difficile pour décourager un utilisateur moyen, mais tu n’arrêteras pas un utilisateur avancé.
Chiffrer le système de fichiers est une solution, seulement s’il est acceptable que toi seul soit capable de démarrer la machine (pour que tu puisses saisir le mot de passe ou brancher la clef de déchiffrement) — si n’importe lequel de tes utilisateurs doit pouvoir (re)démarrer la machine à sa guise, c’est mort.
[^] # Re: Peut-être impossible
Posté par ptit_poulet . Évalué à 1.
Et oui c'est ce que je me suis dis aussi pour ton dernier paragraphe. Donc le chiffrement complet de l'installation n'est pas envisageable…
La seule personne ayant accès à la machine physiquement sera l'hébergeur du hotspot.
Le hotspot serait chargé de faire l'intermédiaire entre les utilisateurs et mes serveurs.
[^] # Re: Peut-être impossible
Posté par bibitte . Évalué à 0.
Justement le fait que le système soit libre est une garantie que tu ne fasse pas toi même ce que tu veux empecher.
Personnellement, si on me dit: "installe cette boite noire ils ont volontairement couper l'accès aux modifications pour t'assurer que personne ne t'espionne."
La première chose que je me demande c'est est-ce que je ne suis pas déjà espionné par le système en question ???
Sur ce point de vue c'est comme pour le faille soit tu est totalement transparent et c'est ça qui garantit qu'il n'y a pas de faille par le simple fait que l'on peu le vérifier (même si du coup c'est aussi plus simple d'en trouver) soit tu est totalement fermé et tu dit que comme c'est fermé il ne peux pas on ne peu pas trouver de faille mais rien ne garanti que tu n'en a pas laisse une volontairement.
en gros choisi ton camps mais ne reste pas avec le cul entre deux chaise soit tu est totalement transparent soit tu ne l'est pas du tout.
[^] # Re: Peut-être impossible
Posté par ptit_poulet . Évalué à 1.
Tout à fait d'accord avec toi. Mais ce que je ne veux pas qu'il se passe, c'est qu'un utilisateur hébergeant le hotspot s'amuse à modifier l'installation pour espionner le trafic qui passe dessus avant d'arriver sur mes serveurs.
[^] # Re: Peut-être impossible
Posté par Zylabon . Évalué à 1.
C'est impossible…
C'est exactement comme chercher à ôter la possibilité au facteur de lire les cartes postales qu'il transporte, il n'a pas le droit de le faire, il risque gros s'il le fait, mais la seule mesure technique qui pourrait l’empêcher de le faire, c'est de mettre la carte postale dans une enveloppe, mais c'est le client qui choisi d'en mettre une ou pas.
Sur le réseau tor, le même problème ce pose, les nœuds de sortie voient ce qui sort du réseau tor, c'est en clair si le client n'a pas chiffré, ils peuvent écouter, et même modifier (genre inclure des malware à la volée dans les binaires téléchargé, pour de vrai)…
Quelqu'un propose une connexion à son réseau, sur son matos, même si tu lui donne une parfaite boite noire, il garde toujours la possibilité de voir ce qui entre et sort. Si ce qui sort est chiffré, il reste ce qui entre, et sur un wifi ouvert ça veut dire tout. Sur un wifi sécurisé ça doit être mieux, mais il maitrise le matériel… Ça veut dire ce qui entre et sort de la carte réseau. Ça rend l'attaque plus difficile que de simplement installer et lancer tcpdump, mais ça reste possible, même avec une boite noire parfaite.
Sans compter le fait que cette personne serait folle d’exécuter un code qu'elle ne maitrise pas sur son réseau.
La solution la plus naturelle serait de créer un tunnel entre le client et ton serveur…
Please do not feed the trolls
# Impossible
Posté par Zylabon . Évalué à 6.
L'utilisateur contrôle le matos. Le mieux que tu puisse faire c'est écrire un programme super compliqué qui fait ce que tu veux. Mais bon, je suis pas sûr que tu sois au bon endroit pour ça :)
Please do not feed the trolls
# Un truc tout bête.
Posté par sdf56dfd . Évalué à -1.
Un truc tout bête.
# Live CD
Posté par quent57 . Évalué à 1.
Pourquoi pas booter sur un live CD, voir sur la carte SD protégée en écriture ? Avec un reboot automatique chaque nuits par exemple, comme ça si une modification est faite elle est perdue le lendemain. Il faut juste voir comment est récupérée la configuration, ou si elle est en dur dans l'ISO.
# rien d'impossible
Posté par niavlys . Évalué à 2.
bein oui, il y a une méthode: ton initramfs peut embarquer un serveur ssh, et interroger un serveur distant pour obtenir la clé de déchiffrement. Par contre sur un Rpi, les performances risquent d'être bien plombées pour les accès "disques".
cf ici pour la mise en œuvre…
[^] # Re: rien d'impossible
Posté par ptit_poulet . Évalué à 2.
C'est super ce système. Je vais étudier tout ça, et faire des tests si je suis convaincu.
Le système n'a pas besoin d'avoir un accès lecture/écriture super rapide. Je pense que je ferai des tests en conditions réelles
Un grand merci en tout cas :D
[^] # Re: rien d'impossible
Posté par Zylabon . Évalué à 2.
Sûr comme un coffre fort dont on peut avoir la clé sur simple demande.
Please do not feed the trolls
[^] # Re: rien d'impossible
Posté par ptit_poulet . Évalué à 2.
C'est pas vraiment ce que j'ai compris dans le tutoriel.
Le Raspberry reste en attente avec un serveur ssh qui tourne. Ensuite tu te connectes depuis un autre PC sur le Raspberry et là tu est invité à taper le mot de passe. Si le mot de passe est correcte, le boot du Raspberry continue.
[^] # Re: rien d'impossible
Posté par Zylabon . Évalué à 2.
Dans le tutoriel, l'attaquant n'a pas d'accès physique à la machine, ça fait toute la différence.
Qu'est-ce qui te garanti que que tu te connecte sur le raspberry pi ?
SSH est sûr à la seule condition que la clé privée du serveur est privée. Ici, l'attaquant potentiel a un accès physique au serveur, et donc à la clé. Il peut récupérer la clé (en clair) se faire passer pour le raspberry pi, et récupérer le mot de passe pour déchiffrer le système de fichier.
C'est vraiment impossible. Même en admettant que tu puisse avoir un système de boot sûr, qui garde la clé secrète secrète et le système chiffré. Il reste possible de fouiller la RAM à la recherche de la clé de chiffrement du système de fichier. Parce que quand on a un accès physique à une machine, on fait ce qu'on veut…
Please do not feed the trolls
[^] # Re: rien d'impossible
Posté par KiKouN . Évalué à 2.
Oui, c'est pas sur le disque qu'il faut mettre un cadenas, mais sur le boitier.
[^] # Re: rien d'impossible
Posté par ptit_poulet . Évalué à 1.
Pour utiliser cette technique et être sûr qu'il n'y a pas compromission il faut donc enfermer le serveur dans une pièce sécurisée sinon cela ne fera que ralentir la personne qui a vraiment de mauvaise intention.
C'est dommage quand même, j'ai bon tourner le truc dans tous les sens, mais je ne vois pas comment contourner ce soucis de ssh…
[^] # Re: rien d'impossible
Posté par NeoX . Évalué à 2.
à l'ancienne, avec un bon vieux dongle sur port serie, avec de l'electronique de protection dedans,
la machine demarre, cherche le dongle, et s'active,
si le dongle n'est plus là, la machine ne demarre pas.
remplace le dongle par une connexion internet, et va chercher une clef de licence sur un serveur à toi,
et tu as le meme principe, sauf que c'est la machine qui va chercher son identifiant et non pas toi qui te connecte dessus pour finir le demarrage.
dans tous les cas, une fois la machine decryptée et demarrée, la personne qui a accés à la machine pourra lire son contenu.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.