Chmod 777?

Bonjour @loic,

En regardant le repo, je suis tombé sur ça

Alors, je passe sur le fait que Jeedom, vient potentiellement faire des trucs sur ma machine sans prévenir (ouf j’utilise pas zabbix, mais personnellement j’aurais préféré que la config de zabbix par un truc du core se base sur la présence/activation du plugin monitoring (enfin j’imagine que c’est ça) plutôt que la présence de fichiers locaux…)… mais faire un « chmod 777 », j’espère que c’est une faute de frappe… Un 755 sera largement suffisant ou à l’exterminé du pire un 775. D’autant plus que les 2 commandes sed suivantes sont faites aussi avec un sudo…

A te lire

1 « J'aime »

Sujet qui à l’air de déclencher les foules.

En fait, il y en a partout… et je comprends absolument pas le besoin.
Les processus de jeedom sont lancés avec le user www-data … ce qui correspond déjà à la configuration de tout le répertoire /var/www/html… www-data est déjà proprio et c’est idem pour le groupe…

root@raspberrypi:/jeedom# grep -R ", 0777"
core/ajax/plan.ajax.php:                        mkdir($uploaddir, 0777);
core/class/event.class.php:                     chmod(jeedom::getTmpFolder() . '/event_cache_lock', 0777);
vendor/symfony/cache/Traits/PhpArrayTrait.php:            if (!is_dir($directory) && !@mkdir($directory, 0777, true)) {
vendor/symfony/cache/Traits/FilesystemCommonTrait.php:            @mkdir($directory, 0777, true);
vendor/symfony/cache/Traits/FilesystemCommonTrait.php:            @mkdir($dir, 0777, true);
vendor/sabre/dav/lib/DAVACL/FS/HomeCollection.php:            mkdir($path, 0777, true);
vendor/guzzle/guzzle/phing/tasks/GuzzlePearPharPackageTask.php:            mkdir($pearwork, 0777, true);
vendor/guzzle/guzzle/phing/tasks/GuzzlePearPharPackageTask.php:            mkdir($pearlogs, 0777, true);
vendor/monolog/monolog/tests/Monolog/Handler/RotatingFileHandlerTest.php:        chmod($dir, 0777);
vendor/monolog/monolog/src/Monolog/Handler/StreamHandler.php:            $status = mkdir($dir, 0777, true);
vendor/doctrine/cache/lib/Doctrine/Common/Cache/FileCache.php:            if (false === @mkdir($path, 0777 & (~$this->umask), true) && !is_dir($path)) {
vendor/knplabs/github-api/lib/Github/HttpClient/Cache/FilesystemCache.php:            @mkdir($this->path, 0777, true);
install/update.php:                             if (!file_exists($cibDir) && !mkdir($cibDir, 0777, true)) {
plugins/blea/core/class/blea.class.php:                         $result = ssh2_scp_send($connection, $_local, $_target, 0777);
plugins/veolia_eau/3rparty/PHPExcel/Classes/PHPExcel/Shared/PCLZip/pclzip.lib.php:        if (!@mkdir($p_dir, 0777)) {
plugins/widget/core/ajax/widget.ajax.php:            $result = mkdir($uploaddir, 0777, true);
plugins/widget/core/ajax/widget.ajax.php:            $result = mkdir($uploaddir, 0777, true);
plugins/jeelog/core/class/jeelog.class.php:            if (mkdir($dataPath, 0777, true) === false )
plugins/openzwave/resources/openzwaved/ozwave/utilities/FilesManager.py:                            os.chmod(final_filename, 0777)
plugins/openzwave/resources/openzwaved/ozwave/utilities/FilesManager.py:        os.chmod(filename, 0777)
plugins/openzwave/resources/openzwaved/ozwave/rest_server.py:                                   os.chmod(target_file, 0777)
plugins/camera/core/class/camera.class.php:                     mkdir($record_dir, 0777, true);
plugins/camera/core/class/camera.class.php:                     if (!mkdir($output_dir, 0777, true)) {
plugins/camera/core/class/camera.class.php:                     if (!mkdir($output_dir, 0777, true)) {
plugins/camera/core/class/camera.class.php:                             if (!mkdir($output_dir, 0777, true)) {
plugins/camera/core/class/camera.class.php:                     if (!mkdir($output_dir, 0777, true)) {
plugins/camera/core/class/camera.class.php:                     if (!mkdir($output_dir, 0777, true)) {
plugins/jeexplorer/3rdparty/elfinder/php/elFinderVolumeDriver.class.php:            chmod($dir, 0777);
plugins/jeexplorer/3rdparty/elfinder/php/elFinderVolumeLocalFileSystem.class.php:            chmod($dir, 0777);

J’ai pris le partir de virer tout ça

sudo find /var/www/html -type f -name "*.php" -print0 | sudo xargs -0 sed -i "s/, 0777)/, 0740)/g"
sudo find /var/www/html -type f -name "*.php" -print0 | sudo xargs -0 sed -i "s/chmod 777/chmod 740/g"
sudo find /var/www/html -type f -name "*.php" -print0 | sudo xargs -0 sed -i "s/chmod -R 777/chmod -R 740/g"
sudo find /var/www/html -type f -name "*.py" -print0 | sudo xargs -0 sed -i "s/, 0777)/, 0740)/g"
sudo find /var/www/html -type f -name "*.sh" -print0 | sudo xargs -0 sed -i "s/chmod -R 777/chmod -R 740/g"
sudo find /var/www/html -type d -exec chmod 740 {} \;
sudo find /var/www/html -type f -exec chmod 740 {} \;

Et ça n’a pas l’air de perturber le fonctionnement

Hello,
Je suis également intéressé de savoir le pourquoi des chmod 777.

J’ai complété la liste des fichiers à patcher… Les droits 777 ont tendances à revenir sinon…

Dans core/install/consistency.php

exec('sudo chmod 777 -R /etc/systemd/system/mariadb.service.d');

@Loic franchement c’est :skull_and_crossbones:

Oui surement malheureusement j’ai vraiment pas le temps de regarder ca pour le moment, je me le note mais si j’ai fait ca c’est surement pour une configuration exotique sur un hardware spécifique.

Merci pour ton retour et pour le prise en compte.
Par contre, c’est pas forcement une bonne idée de généraliser cette config si c’est pour un cas bien particulier. Si c’est un véritable besoin (personnellement j’ai aucun cas d’exemple comme celui-ci et j’ai du mal à le concevoir) autant mettre un if devant et faire ça juste dans le bon cas

Sauf que a mettre des if je me retrouve avec des miliers de lignes de code que je n’arrive plus a maintenir avec le temps que j’ai. On est dans une situation ou maintenant je dois faire des choix pour faire au mieux avec le temps qu’on a et les plateforme qu’on a c’est pas toujours le plus propre mais ca permet au projet de vivre quand meme et de pas s’étouffer sous une lourdeur qu’on ne pourrait maintenir avec les ressources actuel

C’est un choix.
Personnellement entre 1 ligne de code et autant de failles de sécurité potentielles que d’utilisateurs Jeedom, le choix est vite fait…

Failles de sécurité ? C’est pas un peu exageré ? Jeedom est censé etre seul sur sa machine donc si tu as accès a la machine tu as accès a jeedom donc a la db ca change absolument rien le 777 sur ces dossier si la machine est pas partagé.

Mais comme dit je prend bien en compte la demande et si je trouve du temps (je pense en mars ca ira mieux) je verrais comment faire.

Que « Moi » j’ai déjà accès à Jeedom et au contenu de la base c’est pas le souci. Ici, n’importe quel compte de la machine peux aller foutre un fichier dans le répertoire, qui par la suite sera traité avec les droits root au prochain reboot… Non seulement il y a moyen d’avoir accès aux données que j’ai pas forcément envie de partager (indirectement j’offre ici l’accès sans savoir), mais ça reste une élévation de privilège pour d’autres trucs dont on pas besoin et qui met en risque toute la machine.
Que la machine soit partagée par ou pour autre chose ne fait qu’augmenter encore le risque

Mais bon, je note avec plaisir ton intention d’améliorer les choses, c’est tout le but de ma démarche aussi

Si c’est pour gérer des cas particuliers, justement un bloc if à le mérite en plus d’etre plus indicateur. En gros si on écrit sans commenter, le chmod sans un bloc if comme là, tu ne te souviens plus de pourquoi. Si il avait été mis dans un bloc if, ca permettrait en lisant la condition de voir pour qui il est nécessaire.

Quand on voit qu’il y a plusieurs commandes avec 777, ca ressemble fortement à un paliatif facile à simplement mettre le user dans le bon groupe.
Donc ca aussi si c’est des distribs qui font pas comme le reste, le mieux est d’avoir un bloc if par distrib exotique et y mettre les prérequis pour cette distrib, de facon à pas en étaler ailleurs. Voir de simplement le documenter pour que ceux qui sont utilisateurs se débrouillent.

Mais oui, toucher à des fichiers de systemd pour y faire du chmod 777, que jeedom soit seul ou pas, c’est pas normal, ca ne fait qu’augmenter les risques en cas d’exposition à une faille sur un des X composants.
Le principe des plugins est déjà assez dangereux en soit.

ça à l’air d’être un sport un peu partout y compris dans les librairies tierces… La liste plus haut c’est rien en comparaison d’un simplisime grep -R « chmod »

Je prépare le terrain …

Je connais pas le plugin donc je peux pas valider ou pas le pr mais vu qu’il ouvre un socket il a besoin d’un port, si ce port est inferieure à 1024 (l’utilisateur peut le choisir) alors pas sur que sans les droits root ca marche

Bonjour Loic,

Sachant que la valeur par défaut est 55000 pour le socket… J’imagine que 99,999% des utilisateurs garde la valeur par défaut…On peut probablement éviter aussi de mettre tous les droits root automatiquement si c’est pas nécessaire (un test sur la valeur du port, c’est bien aussi), moi personnellement j’irai même jusqu’à pas autoriser la saisie d’un port inférieur à 1024 dans l’interface…

Il y a la même astuce dans le plugin rfxcom. mais là c’est pas suffisant il manque une gestion plus fine des groupes à cause des librairies python…

Je te donnais un exemple parmis tant d’autres la si jeedom m’a appris un truc c’est que c’est pas pck ça marche chez toi que ça marchera ailleurs ya même plus de chance que ça marche pas ailleurs.

Avec le rfxcom si tu es pas en sudo tu es pas sur d’avoir accès au périphérique USB même si sur de nombreuses plateforme ça sera bon car www-data est dans le bon groupe ya des systèmes ou c’est pas le même groupe pour les périphériques USB et ça marchera pas.

Après vu que tu veux augmenter la sécurité de ton jeedom enlève les droits sudo a jeedom il sait le gérer même si c’est moins user friendly c’est possible.

Possible que ça ne fonctionne pas chez les autres, autrement dit ça veux juste dire que la suppression du sudo n’est qu’une partie de la solution et qu’il faut compéter avec une gestion plus fine des droits et des groupes…
Et c’est de toute manière pas une bonne pratique d’utiliser sudo comme solution.

Quant à supprimer les droits sudo dans tout jeedom (même si je comprends du user qui lance jeedom qui est plus juste techniquement), c’est le but (quand c’est pas utile) et si c’est fait directement dans le code, tous les utilisateurs jeedom en profiterons et pas seulement moi avec ma sécurisation perso (comme je le fait actuellement…) C’est bien plus efficace et professionnel vis à vis des clients y compris des pro qui peuvent aider à faire vivre jeedom…
Alors oui c’est pénible, c’est long et c’est chiant…et je suis reloud… Mais c’est le deal gagnant/gagnant

Je vois pas l’intérêt personnel et j’irai pas dans ce sens la sécurité oui être extrémistes ça sert pas a grand chose. La jeedom te laisse le choix tu peux lui virer les droits sudo si tu veux c’est prévu.

La faire ce que tu fais c’est juste beau sur le papier ça change pas qu’il a quand même les droits sudo et donc réduit pas le risque d’attaque au final…

Même pire si un attaquant arrive a prend le contrôle de jeedom même si celui-ci n’a pas les droits sudo ben le mec a quand même accès a toute ta domotique donc bon l’intérêt est pas énorme surtout que comme dit on conseil vivement de mettre jeedom seul sur la machine. Donc l’attaquant aura au pire accès qu’à la machine jeedom et dans ce cas le pire c’est l’accès a la domotique.

Pour moi la le jeu en vaut pas la chandelle c’est vraiment juste pour dire regarder j’utilise pas sudo (mais j’ai quand même les droits et donc si on me pirate ça change rien)

Soyons sérieux ! Je suis certain que l’écrasante majorité des utilisateurs n’utilise pas une solution domotique complètement dédiée, isolée et sécurisée. Et les quelques uns qui le font, ont de toute manière encore à faire à cause de jeedom.
C’est pas parce que tu as une clôture autour de ta maison que tu laisses exprès les clés sur la serrure de la porte d’entrée pour pouvoir laisser tes enfants ou ta femme rentrer facilement un soir où ils auraient exceptionnellement oubliés leur trousseaux le matin en partant…

J’ai pas le prétention de prôner l’extrémisme dans la sécurité… Il y a des tas d’endroit ou le sudo est intéressant (installation des dépendances par exemple). Et si tu vois pas un minimum d’intérêt à corriger là ou c’est pas utile, alors que tu prônes l’aspect « pro » à jeedom (j’ai toujours en tête ta remarque dans le sujet sur la rotation des images pour le plugin camera), je peux rien faire… Et tout cas, moi ça me fait réfléchir et je ne suis (j’espère) pas être le seul.

1 « J'aime »