OpenNab et la sécurité

Suite à un patch 'sécurité' de Neffrith et à des interrogations de Thus0 concernant le paramétrage de proxy sont apparues des questions concernant la sécurité d'une install opennab.
Ce n'est pas la première fois que ce sujet est abordé par des utilisateurs d'opennab.
Citons par exemple les craintes sur la possibilité offerte à n'importe qui d'envoyer n'importe quel message à un lapin connecté à opennab (message de reboot, de sommeil, etc.)

Ma conviction sur ce sujet est que ces questions ne doivent pas être traitées indépendamment de la question de l'identification des utilisateurs et des lapins.
Sans avoir réfléchi à toutes les implications, j'aimerais bien faire aller opennab dans la direction suivante :

- stockage dans opennab d'un ensemble de noms d'utilisateurs
- un utilisateur peut, optionellement, être associé à 1 numéro de série de lapin
- le nom d'utilisateur peut être utilisé en lieu et place du numéro de série dans les appel à l'api
- lorsqu'il y aura une interface graphique d'administration pour opennab, la plupart des répertoires pourront être protégés contre des appels http "de base" (listage des fichiers d'un répertoire, visualisation d'un fichier)
- le nom d'utilisateur, associé à un mot de passe est utilisé pour se connecter à l'interface graphique d'administration
- l'interface graphique d'administration permet à un utilisateur de déclarer le No de série qui lui correspond et d'éditer le paramétrage du .ini spécifique au lapin représenté par le No de série
- chaque plugin définissant une api prévoit un niveau de droit nécessaire pour exécuter chaque appel à l'api. Par exemple de 0 (le plus bas) à 9 (le plus haut). Typiquement un appel provoquant un 'reboot' nécessiterait un niveau 8 ou 9 alors que l'envoi d'un message tts serait plutôt vers 0 ou 1.
- Un appel à l'api peut être optionellement accompagné d'une identification de l'appelant (via le mécanisme d'authentication définit en standard par le protocole http)
- Les droits associés à l'identification d'un appel api sont définis par le lapin (et donc l'utilisateur) récepteur de l'appel. Typiquement, dans l'interface graphique d'administration, chaque utilisateur pourrait dire "tous les appels non identifiés à l'api de mon lapin ont les droits de niveau 2", "l'utilisateur xxx qui appelle l'api de mon lapin a les droits de niveau 8"

Voilà... J'aimerais savoir si vous pensez que ce genre de mécanisme peut être suffisant à opennab pour être utilisé comme serveur "public" hébergeant un certain nombre de lapins ?

L'idée c'est que ce mécanisme :
- protège l'install opennab : tous les fichiers sensibles sont dans des répertoires inaccessibles via http
- protège toute personne utilisatrice : le numéro de série du lapin n'est jamais rendu public
- laisse une marge de manoeuvre suffisante à chaque utilisateur pour gérer qui peut faire quoi à son lapin. Cela permet notamment d'aller au delà du mécanisme de token de Violet puisque chaque utilisateur peut attribuer ou révoquer des droits sur son api individuellement auprès de chaque autre utilisateur (qui peut être un fournisseur de service externe utilisant l'api opennab)
- permet à chaque utilisateur de protéger finement les envois réalisés vers son lapin pour peu que chaque plugin laisse ses niveaux de droits configurables dans le .ini

Je pense qu'il ne faut pas confondre :sécurité, configuration et fonctionnalité, Même si ces trois pôles sont liés.

- La sécurité : c'est je pense ce que tu appelle "protège l'install opennab ...toute personne utilisatrice & ses données associées".. c'est vraiment la sécurité de premier niveau "basic ou non intelligente".
- La configuration : c'est faire en sorte que chaque utilisateur puisse faire en sorte de configurer le serveur OpenNab pour son Lapin 'à sa sauce' avec si possible differents niveau de droits... c'est la sécurité de second niveau "complèxe et dynamique".
- La fonctionnalité : ce sont les interactions que peuvent avoir plusieurs utilisateur entre eux (invités y compris) ou avec le monde extérieur (bot..etc). ce que tu appelle "marge de manoeuvre" mais qui à mon avis reléve plus du développement des pluggins.

Mon patch ne prétent qu'adresser le niveau 1 basic. Car c'est vrai que cela ne me branchait pas trop de mettre à disposition de tout le mode, toutes la vie secréte et trépidente de mon Lapin.
Après je passerai à l'étape suivante.. poco à poco...

Voila voila

A Ciao

Neff

Ps. Ce patch est pour l'instant spécifique à la configuration des serveurs Free.fr

oaz a écrit:

- stockage dans opennab d'un ensemble de noms d'utilisateurs
- un utilisateur peut, optionellement, être associé à 1 numéro de série de lapin
- le nom d'utilisateur peut être utilisé en lieu et place du numéro de série dans les appel à l'api
- l'interface graphique d'administration permet à un utilisateur de déclarer le No de série qui lui correspond et d'éditer le paramétrage du .ini spécifique au lapin représenté par le No de série

une remarque rapide sur ces 3 points : un utilisateur peut avoir plusieurs lapins et inversement un lapin pourrait avoir plusieurs utilisateurs (avec même des niveaux différents) par exemple de la même famille : le papa qui a tous les droits et la fille/le fiston qui a des droits limités...

Thus0 a écrit:

une remarque rapide sur ces 3 points : un utilisateur peut avoir plusieurs lapins et inversement un lapin pourrait avoir plusieurs utilisateurs (avec même des niveaux différents) par exemple de la même famille : le papa qui a tous les droits et la fille/le fiston qui a des droits limités...

Pour l'utilisateur qui a plusieurs lapins, je pense que c'est tout à fait acceptable d'avoir 1 login utilisateur par lapin : c'est le cas sur my.nabzatag.com
Pour le lapin qui a plusieurs utilisateurs, je ne vois pas trop le cas d'utilisation qui pourrait bloquer. Si chaque utilisateur possède un login différent et qu'un seul d'entre eux est réellement associé au lapin (et donc "administre" le fonctionnement), il suffit de donner des droits d'accès à l'api un peu plus privilégiés aux autres logins "amis" qu'à l'enemble des autres logins.

Neffrith a écrit:

Mon patch ne prétent qu'adresser le niveau 1 basic. Car c'est vrai que cela ne me branchait pas trop de mettre à disposition de tout le mode, toutes la vie secréte et trépidente de mon Lapin.
Après je passerai à l'étape suivante.. poco à poco...

Oui, je comprends bien. D'ailleurs moi aussi je compte faire les trucs pas à pas. Les journées sont si courtes...
En fait j'exposais juste ma vision du pas à pas avec le raisonnement suivant :

- je veux protéger les dossiers d'opennab mais avant je veux une interface d'admin car sinon c'est la galère tester, vérifier des trucs, etc.
- je veux une interface d'admin mais avant il me faut des logins pour verrouiller l'entrée de cette interface et je ne veux pas avoir des systèmes d'identification trop disparates => admin et api doivent fonctionner sur le même principe d'identification
- je veux un système d'identification mais la partie sécurisation de cette identification n'est pas le morceau le plus simple donc je vais commencer par une identification qui ne nécessite pas de traitement sécurisé
=> et j'en arrive à la conclusion qu'il vaut mieux que je commence par créer une identification associée au numéros de série de chaque lapin pour faire un appel api sans serial number

Ceci étant dit, la simple association d'un changement sur l'identification du lapin destinataire dans l'api et de ton patch sécurité a un intérêt : celui de pouvoir rendre public un appel api opennab sans jamais dévoiler de serial number.