Pour commencer, merci pour ce travail et ces améliorations de sécurités qui, même si elles apportent de nouvelles contraintes, sont nécessaires.
Je pense qu’une prochaine étape importante sera de corriger la gestion des droits des fichiers. Je trouve en effet aberrant d’avoir une commande dans la procédure de backup qui mette TOUS les droits d’accès à ‹ 775 ›. Ceci signifie que tous les fichiers (y compris les images, code html, code js, fichiers de config, etc…) sont exécutables et qu’ils peuvent être lancé par n’importe quel compte utilisateur.
Je sais qu’il est plus facile de mettre le doigt sur ce problème que de proposer une solution cohérente et non destructive mais il n’en reste pas moins que c’est, à mon avis, une grosse lacune de sécurité.
Bonjour,
Je serais d’accord avec ton analyse sauf que le 1er postulat avec Jeedom c’est qu’on part du principe qu’il est tout seul sur son systeme. Donc si soucis de sécurité il y a c’est soit par l’utilisateur root (les droits y change rien) soit une attaque sur le jeedom (les droits y changeront rien non plus). Nous préférons donc concentré nos moyens sur des partie de la sécurité vraiment utile (comme attaque sur le jeedom directement)
Hello,
La remarque de @ktn est pertinente.
775 c’est trop … Soit c’est root (et donc peu importe), soit proprio (jeedom/wwwdata) et il n’y a que le 7 qui compte…Donc 750 c’est jouable, et 700 aussi… De toute façon il y a pas de groupe … Et pour avoir fait l’exercice de corriger les droits par dessus Jeedom systématiquement pendant des années, c’est parfaitement fonctionnel.
Postulat à moitié valable seulement… Si jeedom ne fonctionnait pas en root (ce qui est tout à fait faisable), et les droits s’appliquaient correctement (sans sudo dans tous les coins, surtout quand c’est pas nécessaire), la surface d’attaque par Jeedom permettraient de faire moins de chose…
Mais bon c’est un sujet houleux qu’on a déjà évoqué plusieurs fois…
Sauf que si jeedom est seul sur la machine (postulat de base je rappelle) une fois jeedom attaqué tu veux accéder à quoi d’autre ? L’important c’est les données que contient jeedom et c’est déjà trop tard.
De plus je rappelle qu’il est tout à fait possible de virer les droits Root a Jeedom et que le code est prévu pour il faudra juste souvent faire du ssh pour lancer les commandes d’installation des dépendances par exemple ou même gérer les droits d’accès au périphérique USB mais c’est tout a fait possible
Mais jeedom n’est pas tout seul dans le reseau… Du coup, ça justifie d’autoriser le risque ailleurs ?
Les données jeedom, c’est surement pas l’objectif le plus intéressant (Quelques mots de passe et des relevés de température ?). Par contre, une machine dont on a le contrôle total et qui offre l’accès à toutes ses ressources (cpu / internet /lan) on a beaucoup plus à y gagner. C’est déjà laid de se faire pirater quand on est un particulier, mais il est certain que les ‹ pros › ont encore plus à craindre
CPU => Minage
Internet => Bot DDOS
LAN => Sniff réseau
Si effectivement il y a bien une fonction pour autoriser le sudo ou pas, encore faudrait-il quelle soit utilisée PARTOUT… Les sudo en shell directement dans du php (et donc qui courcircuitent la fonction),ne sont pas rares !!! Et dans les plugins officiels aussi, et pour certains le daemon tourne en root directement.
Truc joli qui me revient en mémoire : le service mariadb en 777
Soit je comprends rien a l’informatique soit ya un soucis dans ce que tu dis : en quoi ne pas avoir les droits Root empêche l’accès au cpu/ram/disk/réseau ?
Je viens de tester sous linux avec un utilisateur sans droit je peux :
faite un ping donc je dois avoir accès au réseau ? Enfin je crois
je peux faire un calcul en shell, donc j’ai accès au cpu non ?
je peux faire une variable d’environnement donc j’ai accès à la ram non ?
j’ai même pu créer un fichier donc je pense j’ai accès au disk ?
Faudra m’expliquer aussi comment tu fais du sniff réseau en lan filaire. Hormis une attaque par usurpation d’ip je vois pas le mec va pas récupérer grand chose… Ou par corruption de table arp mais même la la plupart des routeurs savent le détecter et l’éviter.
Pour le sudo dans le core n’hésite pas à faire des pr pour passer par la fonction prévu pour.
Le souci c’est plus quand on est root : c’est trop tard. Par contre quand tu ne l’es pas encore, l’idée c’est d’éviter de le devenir simplement.
Tu es utilisateur normal (conquis à travers jeedom), les fichiers ont des droits pourris mais avec des exécutions en root… Et voilà, tu remplaces/exécutes le contenu par le petit script de ton choix et c’est fini. Tu déploies ce que tu veux ou tu veux. Tu bricoles service d’annonce et même après reboot, la machine est à nouveau exploitable.
Les concepteurs de linux ont surement perdu leur temps à gérer les profils puisque ça n’apporte rien de plus d’être root
Donc 100% des jeedom sont filaires et derrière des switchs ?
C’est fini pour moi le temps de faire des PR sur jeedom… désolé
Les amis, ce sujet de sécurité est intéressant et je suis vos échanges, un peu de loin car pas du tout vos compétences pour débattre avec vous
J’ai un un truc plus “trivial” à vous proposer concernant la sécurité, Jeedom propose de sauvegarder latitude et longitude à un moment dans la config.
Heureusement, c’est facultatif et j’ai laissé vide, j’ai toujours eu peur que ce soit accessible si quelqu’un de malveillant pénétrait le Jeedom… (avec acces flux camera, etc) : l’adresse serait alors servie sur un plateau.
Oui, ton exemple est interressant, ajoute à ça la lecture de la clé wifi (puisque root) par exemple c’est pas mal … Et te voilà avec un joli point d’accès gratuit
Ca je ne sais pas, peut-être, c’était juste pour dire qu’on peut trouver autre chose aussi que des températures
(caméras, gestion presence, localisation maison, etc).
Avec l’adresse et la gestion de présence, tu peux presque venir prendre l’apéro pendant que les proprios sont absents (dans le meilleur des cas…)
Je fais ce que je peux avec les moyens et le temps que j’ai, je classe les demandes suivants les priorités que j’estime (ou que me demande jeedom sas) et je fais. Si ça va pas ne pas hésiter à prendre ma place je la laisse avec plaisir. Mais bon c’est sur qu’il est toujours plus simple de se plaindre sur d’agir (comme faire des pr)
Pour revenir au sujet je ne suis toujours pas d’accord avec toi, la gestion des droits à un intérêt quand tu as plusieurs logiciels qui tournent sur la même machine, ce n’est pas le cas avec jeedom. Et même alors imaginons je les retire pas de soucis comment faire pour installer les dépendances ? Je demande à tous les utilisateurs de se connecter en ssh et de lancer le script ? Je serais curieux que tu m’éclaires de ton savoir la dessus, je suis de mon côté vraiment pas assez bon pour résoudre ce soucis.
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 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
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
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
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
(dans le meilleur des cas…)
