Droits Sudo et 777

Bonjour
C’est juste une aide il n’est absolument obligatoire de le remplir c’est juste pour simplifier nla configuration dans certains plugins

Sauf que pour configurer le wifi c’est par jeedom donc faudra m’expliquer comment on fait pour que Jeedom configure le wifi sans avoir le droit de le configurer…

Oui Loïc, je le disais c’est facultatif :wink: juste j’ai eu cette fulgurance en voyant le champ vide au moment de déployer jeedom, puisqu’on aborde la sécu je me suis dit que j’allais vous partager…
Merci pour tes lumières :wink:

Bé tu met les coordonnées du voisin :shushing_face:

Moi j’ai un sécateur connecté sur le cable rj45 de jeedom :grin:

Sinon y’a déjà eu des cas avéré de piratage de Jeedom ?

1 « J'aime »

Chiche ? :joy:

Mince c’est déjà fait :grin:

Le sécateur électrique est également connecté : avec l’application FELCO, vous pourrez retrouver toutes les informations sur celui-ci, notamment le nombre de coupes mais aussi l’autonomie de la batterie. Vous aurez également la possibilité de gérer les paramètres de votre sécateur pour une utilisation la plus efficace possible.

Oui ou du centre-bourg, ça marche aussi, on est pas à 500m près :wink:

1 « J'aime »

Jolie esquive ! Des PR de ce genre et sur les droits justement j’en ai fais … Restés plusieurs mois sans retour ni question, et clôturés au bout de 2 ans sans un mot… Des solutions de corrections des droits j’en ai posté également sur le forum… Alors même si je ne suis plus utilisateur jeedom aujourd’hui, je m’autorise à me plaindre

Si effectivement c’était une hypothèse toujours valable. Et avec une prise de controle, c’est sur que c’est 100% faux.

Encore une fois, c’est toujours pas 100% vrai.

Certaines solutions ont déjà été évoquées : 755 ça sert à rien, 777 c’est pire ! C’est pas forcement complet mais c’est bien mieux que de rien faire

1 « J'aime »

Salut !!

C’est pas parce que c’est pas connu que c’est n’existe pas ou que c’est pas possible. Log4j ça fait un petit moment que la faille est là …
Je me rappelle d’une fois, je ne sais plus qui à laissé sont « Invite SSH » par défaut (avec le user et le password) exposé sur internet… Dans ce cas, là c’est pas jeedom le responsable mais ça y contribue quand même un peu

Je m’autorise à dire que ceux qui n’utilisent plus Jeedom et qui viennent troller un forum qui ne les concerne plus devraient voir ailleurs…
Merci d’avance à un modérateur de supprimer mon message ainsi que celui des trolls

Ah mais je suis bien d’accord, c’était une vrai question, je suis curieux.

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é.