Bonjour à tous,
J’ai suivi les discussions, et ce que j’en ressorts c’est que chacun veut un Jeedom le plus sécurisé possible, mais que vous n’êtes pas d’accord sur la façon de le faire et sur les priorités à mettre en place.
Toutefois il y a quelques phrases qui me font plus réagir.
D’abord, celle-ci :
Malheureusement un système sans faille n’existe pas. A partir du moment ou un système n’est pas 100% isolé (c’est à dire qu’il n’y a aucun port/porte d’entrée physique ou via réseau) il existera toujours 1 jour une faille pour ce système.
Donc, c’est une bonne chose de chercher des failles pour ceci, et avoir un bug bounty ouvert est encore mieux.
Toutefois, une faille tant qu’elle n’est pas découverte ne doit pas être considérée comme inexistante. En effet, elle peut être découverte par un mauvais groupe de personne en premier, et faire un vrai carnage. Exemple, si un groupe mal intentionné passe du temps sur le code de Jeedom et trouve une faille il serait en mesure de créer un plugin / template / lot d’image que tout le monde pourrait mettre sur son système et ainsi ils prendraient le contrôle de plusieurs milliers de machine que deviendraient des botnets. Sachant qu’une grande partie des personnes utilisant Jeedom ne sont pas des experts en informatique et ne verraient très probablement pas de changement.
En conclusion appliquer une deuxième couche de sécurité en retravaillant au maximum les droits sur les fichiers n’est pas stupide du tout, afin d’améliorer la sécurité globale de Jeedom.
Une très bonne question.
Mais comment savoir comment un système a été piraté ? Ce n’est pas du tout à la portée de tout le monde de savoir si un de leurs équipements ne s’est pas transformé en botnet.
Aussi, il existe des attaques qui ont une cible précisent mais pour lesquels les attaquants tirs gros. Donc, il y a pleins de système infectés, mais 1 seul va s’activer (voir le virus Stuxnet, par exemple).
Je vais refaire a un nouveau le raisonnement avec un autre type d’attaque si vous voulez (a la fin je pense vous aller peut être comprendre).
L’attaquant arrive a mettre un fichier image sur jeedom corrompu (770, 700 ou 777 au final ça changera rien en faite)
Pour une raison inconnu l’attaquant arrive a passer une commande shell a travers jeedom (je pars du principe que l’attaquant est idiot est ne voit pas qu’il a deja tous les droits vu qu’il arrive a faire exécuter une commande shell à Jeedom)
Avec la commande il lance sont fichier, vu que c’est a travers jeedom quelques soit les droits (770,700,777) il a toujours un 7 coté user donc il peut le faire sans soucis
Un deuxième exemple pour la route :
au lieu de 7 quelque chose je suis en 5, même soyons fou je suis en 500
idem le mec envoi une commande shell
alors la il peut soit faire un chmod 700 et exécuter son fichier image sans soucis, soit au lieu de faire ./monimage.png il fait un bash monimage.png par exemple
Dans tous les cas les droits ont rien changés.
Je le dis et redis la gestions des droits c’est utiles a partir du moment ou il y a plusieurs utilisateur pour limiter les risques entre eux, sur jeedom c’est pas le cas et vu que jeedom a les droits root il a de base tous les droits. On a donc au final qu’un type d’utilisateur avec tous les droits sur son systeme. Ce n’est pas genant jeedom est seul dessus.
J’ai pour ma part très bien compris ton raisonnement Loic.
Jeedom ayant déjà tous les droits, l’attaquant aura de toute façon d’une manière ou d’une autre accès à tous sur la machine.
La vraie question au final serait est ce qu’il est possible de garder un Jeedom utilisable sans qu’il ait des droits particuliers
Tu as bien expliqué le problème des installation des dépendances si pas les droits.
Et c’est là qu’il faut faire l’analyse de risque et la balance bénéfices risques.
Je ne suis pas développeurs et n’en sait fichtre rien si c’est possible, mais on peu imaginer une demande d’authentification à chaque besoin d’élévation de privilège.
A étudier techniquement et fonctionnellement.
Ce qui embête nos camarades c’est au delà de pourrir le système Jeedom, récupérer des données, rendre la domotique inutilisable, c’est aussi pouvoir transformer cette machine en relais / botnet / espions… etc …
et là il en va d’une sécurisation globale de nos infras messieurs.
Si vous êtes conscients des risques, que Jeedom est transparent sur les risques alors le travail est aussi coté utilisateur.
Sécuriser vos infrastructures internes;
Ne soyez pas admin de vos postes et serveurs
mettez à jour vos systèmes
Isoler les flux.
-Tracer les accès
Tout le monde en rigole, mais j’ai fait ma propre analyse de risques, et toute ma domotique est isolé dans un réseau IOT et n’a accès qu’à une matrice de flux précises.
Aller au delà des bonnes pratiques et commençons à tous se responsabiliser sur la sécurité en étant conscient que la sécurité est l’affaire de tous et pas que de l’éditeur ou du fournisseur de logiciel.
Je vais même plus loin, certains éditeurs (bon c’est rare) demande une vraie sécurité coté client sinon il n’intègre pas la solution.
Je ne sais pas si c’est moi que tu considères comme jeune débutant mais sache que j’ai commencé l’informatique du temps des cartes perforées, que je suis passé à Unix en 1993 etque j’ai débuté avec Linux en 1994. J’ai travaillé, entre autres sur des systèmes bancaires, dans une société liée à la sécurité et je suis maintenant en charge de systèmes étatiques.
Je ne cible personne
Mais c’est vrai que l’âge n’a parfois rien a voir avec le problème
Je rencontre souvent de problématique aussi avec des plus expérimentés
Tout dépend de son expérience et sa sensibilité sur le sujet
Je vais refaire a un nouveau le raisonnement avec un autre type d’attaque si vous voulez (a la fin je pense tu vas peut être comprendre).
Un utilisateur met un fichier image correctement formé pour être malveillant sur son jeedom. Boom, dès que Jeedom charge l’image pour l’afficher (dans un template ou autre), le créateur de l’image reçoit une notification avec les liens et identifiant pour accéder à la machine en root.
Pas besoin pour l’attaquant d’avoir un accès à la machine pour avoir un grand impact. Par contre si le fichier ne peut pas être exécuté l’attaquant a besoin d’un accès à Jeedom pour pouvoir lancer son fichier corrompu. Donc ça réduit drastiquement la surface d’attaque.
NB : ta phrase (que j’ai volontairement reprise) « à la fin je pense que vous aller peut être comprendre » est plus que méprisante. Ça revient à dire quelque chose comme « vous êtes bêtes comme vos pieds, mais à force d’insister une lueur d’intelligence n’est pas exclue »
On va continuer pas de soucis, l’utilisateur met un fichier image malveillant pas de soucis :
pourquoi jeedom lancerait le fichier images comme un script ? Il n’y a aucune raison sans qu’on lui demande explicitement qu’il fasse un ./monimage.png
imaginons il la lance (je sais pas encore ni comment ni pourquoi) en quoi mettre 700 empêche jeedom de la lancer ?
dernier cas on met du 500 il suffit alors de faire bash monimage.png au lieu de ./monimage.png et c’est bon elle est executé aussi
Dans aucun des cas le changement de droits ne protege.
NB : oui a la fin (du raisonnement) vous allez peut etre comprendre, je ne vois pas en quoi c’est maîtrisant…