Droits Sudo et 777

La mentalité de l’autruche, c’est joli !
:roll_eyes:

Idem intéressé, dans le changelog on voit que Jeedom a fait travailler une société spécialisée dans la sécurité, pour corriger une faille en 4.1.27 de mémoire…

Je trouve cela plutôt rassurant pour les utilisateurs, de faire appel à des pros du domaine pour encore plus sécuriser le core.

1 « J'aime »

Si tous les supporters de foot qui n’ont jamais été champion du monde pouvaient suivre ton principe …

Je vais scinder le sujet je crois :face_with_monocle:

3 « J'aime »

L’exemple en question est réel, pour le reste je ne sais pas

Tu sais quoi j’arrête là comme à chaque fois avec toi c’est stérile comme débat, il n’y a pas de réflexion tu veux juste une application bête et méchante de ce que des gens appels les bonne pratique… Des fois il est bon de se demande si dans le contexte ses bonnes pratiques sont vraiment bonne ou si il vaut mieux passer du temps sur d’autre sujet plus important.

Il faut toujours s’en inspirer mais faut se dire tien dans mon contexte est ce une bonne chose ? Est ce que je ferais pas mieux de passer mon temps sur d’autre plutôt que la dessus qui n’apporte pas grand chose en terme de sécurité par rapport au temps passer ? Par rapport à d’autres sujet ?

On est donc du même avis sur la stérilité du débat. Je te laisse révolutionner à toi tout seul les bonnes pratiques que des milliers d’informaticiens se forcent définir et à appliquer bêtement (du coup on les appelle bonnes si elles ne le sont pas ? :grin: )
Et parce que si effectivement changer un 5 en 0 c’est une perte de temps injustifiée, je crois que ma place n’est définitivement plus sur ce forum.

Tu interprètes et déforme comme à chaque fois… J’ai jamais dit qu’il ne fallait pas regarder les bonnes pratiques juste qu’il fallait le faire en bonne intelligence tout simplement. Ce dire tient dans mon cas est ce pertinent ? Exemple les droits des fichiers oui faut les restreindre le plus possible c’est la bonne pratique mais dans le cadre de Jeedom ça donne quoi ?

Si quelqu’un pirates jeedom il a les droits de Jeedom donc réduire les droits n’apportera pas grand chose car il y aura toujours accèsw ne vaudrait il pas mieux que les jours perdu la dessus a tester pour voir si tout va bien et à adapter pour pas que ça bug je les passes plutôt a sécuriser jeedom lui même pour réduire les risques de pirate ?

Là c’est juste un exemple mais faut le faire sur tout, alors oui c’est moins facile que d’appliquer bêtement une règles car ça demande de réfléchir…

Du coup, tous les exemples ci-dessus ne servent à rien. si j’était le seul à le dire encore, mais c’est même pas le cas.

Mais on est d’accord … Obtenir les droits jeedom, ça sert à rien. Par contre, c’est une étape vers beaucoup plus grave, obtenir ceux de root …

C’est justement l’intérêt de modifier les droits en question, réduire et prévoir les risques.

Oui sur tout. En commençant par les points faciles et évidents, surtout ceux qui ne coutent pas chers.
Et ton raisonnement est tout à fait valable : Mettre du 755 plutôt que 750 c’est ne pas réfléchir. Il y a que jeedom sur la machine, donc c’est utilisé par qui ‹ le xx5 › ? Tu veux tester quoi ? Et si ça buggue, c’est que l’erreur est justement dans ces droits qui ne devraient jamais être définis comme ça. C’est n’est pas à jeedom de l’autoriser (ou de faire perdurer la situation) mais à celui qui s’en sert de s’en passer.
Encore pire avec le 777, c’est la solution de facilité quand on ne veut pas chercher.

Le problème est surtout qu’il y a 7 partout. Ceci rend n’importe quel fichier exécutable. Vu que jeedon avec le compte www-data qui peut faire du sudo -u root sans password. On peut imager qu’un fichier à l’air anodin (un png par exemple) mais qui contient un malware soit uploadé. Ce fichier *.png sera alors rendu exécutable lors du prochain backup et pourra faire n’importe quoi sur le system (et se rependre sur le réseau ?) avec les droits root.

Dommage pour ceux qui utilisent Jeedom pour sécuriser leur maison…

En résumé, le flag x (exécutable) ne devrait être mis que sur les fichier qui doivent vraiment être exécutable.

Tu lis pas… A quoi ça sert de mettre du 770 si le piratage vient de Jeedom lui mémé qui a les droits sur les fichiers ? A quoi ça sert d’interdire l’accès au fichier a tout le monde si le monde se limite à Root qui a tous les droits et a Jeedom ?

Et si c’était juste mettre 770 ou même 750 ne crois tu pas qu’on l’aurait déjà fait ? Tu as testé sur combien de Jeedom ? Le tiens aller ceux de copains on va dire une centaines ? C’est rien comparé au nombre de Jeedom et au particularité de chaque. Si on a mis en 775 c’est pas que pck mettre en 770 apporte rien de plus niveau sécurité mais pck ça diminue énormément les soucis.

Honnêtement a te lire ça laisse penser qu’on est vraiment des incompétent et qu’on fait rien donc si tu veux je te laisse ma place immédiatement et je m’arrête ça me gène absolument pas au contraire je n’attends que ça laisser ma place a quelqu’un de compétent.

Encore une fois le raisonnement est pas bon :

  • on peut pas enlever les droits Root a Jeedom car sinon impossible d’installer les dépendances automatiquement
  • donc a quoi ça sert de pas mettre un 7 si le logiciel qui est piraté est Root ?
  • de plus a quoi ça sert de limiter les droits sur des systèmes ou ya seulement 2 utilisateurs Root et jeedom ?

Comme dit c’est les bonnes pratiques mais c’est encore une fois les appliquer bêtement et perdre un temps de malade sur quelques chose qui ne securisera rien du tout c’est de la poudre au yeux. Je préfère donc passer du temps sur des vrai soucis potentiel de sécurité.

Le risque n’est naturellement pas l’utilisateur qui attaque sa propre machine. Si tu te renseaigne un peu, tu verra qu’il arrive que des sites soient attaqués par des depuis internet en utilisant des failles qui ne sont pas connues ou n’ont pas été corrigées.

Je sais qu’il est illusoire de vouloir avoir un système sûr à 100% mais un minimum de sécurité ne fait pas de mal.

On peut aussi attendre d’avoir un problème puis ce dire qu’on aurai dû réfléchir avant…

Vraiment on se comprend pas : ya que Jeedom sur la machine qui tourne et Root, jeedom a par défaut les droits Root pour simplifier l’installation en quoi passer du temps à sécuriser les droits des fichiers est utile ? Si jeedom se fait pirater le mec a tous les droits ça sert à rien de sécuriser ça… Faut sécuriser l’application directement mais la dans tous les cas l’attaquant aura tous les droits si il passe l’application faut sécuriser l’application.

Il n’y a pas que root et jeedom. L’application Jeedom tourne avec les droit du compte www-data. Il suffit d’attaquer le jeedom pour obtenir les droits www-data et prendre les droits root via une commande sodu sans avoir à saisir un password. Reste alors, par exemple, à consulter la config de wpa-supplicant pour connaître le password wifi et se connecter sur le réseau interne.

Je suis tout à fait d’accord et c’est ce que dis depuis le début !!!

A quoi ça sert de limiter les droits des fichiers jeedom vu que dans tous les cas il faut qu’il y ait accès et il a les droits root. Donc il faut se concentrer sur la sécurité même du code.

PS pour info le nom d’utilisateur de Jeedom c’est www-data sur les systèmes il n’y a donc bien que 2 gros utilisateurs.

Les mauvais droits ne sont pas un risque après une attaque du system mais pour attaquer le system

Ok comment attaque tu le système alors ? Je serais vraiment currieux la que tu m’expliques

Pour rappel sur l’os il n’y a que jeedom

Oui, tu as raison, vu que jeedom est une application web et que l’on a jamais vu une application web avoir une vulnérabilité exploitable et exploitée.

J’ai pas dit ça mais tu le dis toi même il faut une faille dans jeedom (donc déjà il vaut mieux je pense passer du temps à chercher ces failles la). Ensuite et c’est le plus important une fois que tu as la faille tu as déjà toutes les clefs pourquoi le mec se ferait chier a mettre un fichier puis faire en sorte que Jeedom le lance alors qu’il peut déjà toujours faire… C’est complètement idiot

Bonsoir
J’ai parcouru le fil de la discussion et j’ai l’impression de vivre les éternels échanges entre les jeunes puristes qui sortent de l’école (rien de péjoratif et je cible personne) et les anciens qui on installé et gérés les systèmes depuis des années

Je vis moi même ces discussions régulièrement avec des nouveaux arrivants qui veulent refaire toutes les infra car selon eux ça a été mal fait

Mais la plupart du temps quand on lance ces personnes sur les projets et bien il ne se passe rien car ce sont de vrais projets d’améliorer la sécurité
Et que ces mêmes personnes ne savent pas par ou commencer et quand il le font et bien cassent tout la plupart du temps et vous appelle pour réparer

Dans la sécurité informatique le béaba est le fameux. DICT
Disponibilité
Intégrité
confidentialité
Traçabilité

Très souvent les gens qui se pensent sachant sur la sécurité pensent en premier lieux au cyber attaques
Mais mettent totalement de côte la disponibilité des applications suites à des changements (planifiés ou non )

Je suis d’accord si on arrive à respecter toutes les bonnes pratiques et faire que le système fonctionne aux petits oignons c’est magnifique
Mais malheureusement c’est pas ça la vraie vie…

La vraie vie ce sont des systèmes en production qui faut continuer à faire tourner et et faire évoluer la plupart du temps avec des équipes restreintes

Je suis d’accord avec Loïc sur certains points
C’est bien beau de respecter toutes les bonnes pratiques pour rendre au final un système moins utilisable et générer le l’insatisfaction

Depuis quelques années, je suis plutôt partisan de gérer la sécurité par le risque

Faire une vraie analyse de risque sur la solution et en
Découler un plan d’action accessible avec des Quick wins qui sont peu impactants et font gagner tout de suite de la valeur ajoutée et de la sécurité, a plus de sens que de vouloir à tout prix respecter bêtement toutes les bonnes pratiques

J’ai en effet plus confiance dans une solution qui va montrer patte blanche avec une vraie analyse de risque et une vraie transparence sur ses audits de sécurité réguliers

Cela vaut mieux a mon sens qu’un éditeur qui va te balancer ces certifications a la tronche et son respect des bonnes pratiques mais au final ne vont pas plus loin et manque de transparence

Cela me fait écho avec des discussions avec des experts de la sécurité qui vont mettre en place le dernier joujou de sécurité a la mode pour détecter les cyberattaques , mais n’ont même pas encore attaquer la sécurisation de leur parc de pc clients qui sont tous admin de leur poste

Les mêmes personnes qui se plaignent sont plupart du temps ceux qui respectent moins les processus de sécurité

SONDAGE : Aucun utilisateur de Jeedom n’est admin de son poste actuellement ?

12 « J'aime »