Règles de sécurité à respecter

Toutes les solutions logicielles OpenSource de gestion IaaS, voire de certains éditeurs ont besoin de trouver une astuce pour accéder aux ressources OS relatives à la gestion du hardware (ex: device, cpu, ram, disk, etc.), mais aussi à la configuration du système, ont tendance à se faciliter la tache quelque soit le langage de programmation associé (ex: scripts Python, exécutable Java, voire autres) pour obtenir les privilèges nécessaires, c'est-à-dire ceux de l'administrateur "root".

 Un exemple de syntaxe de programmation en Python (dans le code de Nova):

utils.execute('mkdir', '-p', netdir, run_as_root=True)

Pour qu'aucun mot de passe ne soit demandé pour exécuter ce traitement (automatisé), on se facilite la vie en ajoutant le record ci-dessous, dans le fichier "/etc/passwd".

"ALL ALL=NOPASSWD: ALL"

C'est une facilité qui ouvre les portes d'accès à tous les systèmes de l'environnement. A vrai dire, même si le système "sudo" a des limites (filtrage uniquement sur le script ou l'exécutable et pas de contrôle sur les arguments, etc.), il faut être plus restrictif que cela, sinon l'environnement n'est pas sécurisé. A vrai dire, les OS supportant les services OpenStack (Nova, voire Glance, Swift, KeyStone, Quantum, ou encore  Horizon) doivent impérativement être sécurisé. C'est-à-dire qu'au minimum des logiciels de gestion de l'intégrité doivent être mis en place et en cas d'incident sur un fichier quelconque privilégié, une alerte doit être remontée à la supervision de l'environnement.

Voici, sans rentrer dans les détails, quelques exemples de ce que l'on trouve dans le code actuel de Nova.

DEFINE_string('root_helper', 'sudo', 'Command prefix to use for running commands as root')

cmd = shlex.split(FLAGS.root_helper) + list(cmd) 

Cette faiblesse existe actuellement dans le code Nova de la release Diablo et la communauté en est consciente. C'est pour cela qu'un projet d'amélioration est en cours (objectif  ASAP, en tout cas pour la sortie de la release Essex) et se nomme "nova_rootwrap"qui a pour but de lever cette anomalie sur la permissivité déclarée dans le fichier "sudoers" et aussi de s'assurer que seules les commandes avec arguments utilisés pour les accès aux ressources OS soient acceptées, sans avoir à donner le mot de passe de l'utilisateur privilégié "root".

Vivement demain!