Dévelopeur du #plugin-tesla, j’utilise une librairie pour afficher la carte du tracking. Les tuiles utilisées pour la map ne sont pas affichées à cause de la nouvelle politique de sécurité mise en place depuis la version de Jeedom 4.2.
Pour palier à ce problème, je dois demander à mes utilisateurs de modifier le fichier /etc/apache2/conf-available/security.conf et de remplacer
Bonjour
Je laisserai jeedom SaaS trancher mais pour moi c’est pas une bonne idée. Autant supprimer toute sécurité dans ce cas si c’est pour autoriser plein de site. Pas oublier que mettre du js/IMG ou autre d’un autre site sur ton jeedom reviens a donner les clef de chez toi au site en question.
Par contre tu peux demander aux utilisateurs de désactiver volontairement la sécurité comme je l’ai indiqué dans l’article du blog qui parle de la sécurité c’est plus simple que de passer en ssh
Je suis d’accord avec @Loic, dans l’optique de sécuriser jeedom, cela n’a pas de sens d’ajouter chaque origine qu’un nouveau plugin souhaiterait dans la liste de confiance de tous les jeedoms de tout le monde.
Après je ne me prononce pas sur le fait qu’on puisse avoir confiance en google.com ou pas ou que l’on puisse avoir confiance en jawg.io ou pas et pourquoi plus l’un que l’autre etc.
Mais si on commence avec un plugin il va falloir une politique/règle pour décider quand rajouter et quand ne pas rajouter et ca va demander potentiellement plusieurs changement dans le core pour chaque plugin « accepté », ce dernier point va avoir un impact négatif sur la maintenance: par exemple, comment savoir dans 2 ans si c’est encore relevant ou pas, si le plugin s’en sert encore ou pas?
L’idéal serait un système dans lequel le plugin doit déclarer les origines voulues, qu’à l’install du plugin le core signale à l’utilisateur ce besoin et demande l’accord pour exécuter la commande adéquate plus reboot d’apache (et qu’à la désactivation du plugin l’opération inverse soit faite)
Selon moi, l’utilisateur doit pouvoir accepter ou pas que son jeedom télécharge des fichiers sur tel site, il doit avoir le droit de refuser et par conséquent de perdre en fonctionnalité, voir perdre la possibilité d’utiliser le plugin (cela devrait être indiqué dans la doc/description du plugin).
Ca me semble etre la bonne stratégie. Il ne faut pas devenir fou de la sécurité au point que cela en devient inutilisable.
Tout le travail de Jeedom sur la sécurité est très bien. Certain points qui bloquaient ont pu être traité en fonctionnant différemment dans les plugins, mais d’autres comme celui-ci est plus compliqué à traiter.
Un refus catégorique reviendrait à dire à l’utilisateur, ton plugin il marche pas comme tu voudrais car d’autres ont pris des décisions de sécurité pour toi. Dans certains cas c’est bien, dans d’autres non.
La proposition de @Mips de sensibiliser l’utilisateur à autoriser ou non lors de l’installation d’un plugin, l’accès à un site au niveau du CSP (Content-Security-Policy) est très bien. Par contre ca mérite d’être bien réfléchi pour ne pas permettre une ouverture trop large au développeur « par facilité ».
Il faudrait donc par exemple :
Imposer au développeur de spécifier le(s) CSP à autoriser en http ou https uniquement dans le info.json. Peut être meme pas autoriser les wildcards par précaution
Imposer au développeur de spécifier pour chaque CSP ou au global un texte expliquant la raison de cet ajout qui serait affiché à l’utilisateur lui permettant de choisir en tout état de cause d’autoriser ou non cet ajout et d’en connaitre les impacts.
N’autoriser les CSP d’un plugin, qu’au fichiers du plugin avec un FileMatch par exemple. Cela permettra de limiter le risque au plugin concerné et de plus facilement supprimer cette partie lors de la désinstallation du plugin
Peut être même une partie dans l’administration Jeedom qui liste les CSP additionnel par plugin
:
)