La console est un privilège : pourquoi elle demande sa propre autorisation

Une console ressemble à un écran. Vous l’ouvrez, une fenêtre apparaît, du texte défile dedans. Cela donne l’impression de « je ne fais que regarder ».

Pourtant une console est un shell. Et le shell du serveur est le droit le plus élevé qui existe sur cette machine.

Deux pouvoirs distincts

Modifier des réglages. Vous pouvez faire ce que l’interface autorise. Les limites sont nettes, car c’est l’interface qui les trace.

Ouvrir un shell. Vous pouvez tout faire. Y compris ce que l’interface refuserait, et ce dont elle n’a jamais entendu parler.

Ces deux pouvoirs ne se contiennent pas l’un l’autre. Avoir l’un n’exige pas l’autre et, plus important encore : accorder l’un ne devrait pas signifier accorder l’autre.

La distinction est réelle et se voit dans les rôles intégrés

Proxmox lie la console à sa propre autorisation, pas à l’autorisation générale de « peut modifier ». Vous pouvez voir que c’est réel dans les rôles intégrés : le rôle d’administrateur système porte les droits d’audit, de console et de journal, et ne contient aucun droit de modification.

Il est donc légitime de donner à quelqu’un le droit d’ouvrir une console sans le droit de modifier des réglages. Et l’inverse aussi.

La situation courante qui rend cela important

Proxmox permet de créer des rôles personnalisés, et un rôle comme celui-ci est très répandu : un opérateur qui peut modifier les réglages réseau mais ne doit pas atteindre le shell du serveur.

C’est une demande raisonnable. Modifier la configuration réseau et exécuter n’importe quelle commande sur le serveur ne sont pas la même chose.

Mais si un produit raisonne « s’il peut modifier, il peut aussi ouvrir la console », il remet à cet opérateur un shell root sans s’en rendre compte. Il obtient par le panneau ce qu’il n’obtiendrait pas dans Proxmox.

Le principe général qui en découle

Un modèle d’autorisations doit copier la définition propre de la plateforme, pas la paraphraser.

Une porte qui dit « à peu près la même chose » fonctionne correctement sur les installations ordinaires et personne ne remarque rien. La faille s’ouvre le jour où un rôle inhabituel est créé. Et ce jour-là, personne ne se souvient d’une approximation écrite des années plus tôt.

La même barre s’applique à l’accès aux fichiers

Un détail de plus, car il est souvent oublié : l’accès au système de fichiers du serveur équivaut à un shell même en lecture seule.

La raison est simple : les fichiers de mots de passe, les clés et les secrets du cluster se trouvent dans ce système de fichiers. Quelqu’un doté d’un droit en lecture seule qui peut lire les fichiers peut déjà tout apprendre.

L’accès aux fichiers ne peut donc pas être accordé avec un droit de « regarder » ; il demande la même barre qu’un shell.

Ce que fait Atlas

Dans Atlas, la console, le shell distant et l’accès aux fichiers sont liés à la seule autorisation de console. Le droit de modification à lui seul n’ouvre pas ces surfaces.

Cela n’a pas toujours été le cas, et l’article doit finir honnêtement : autrefois ces surfaces acceptaient aussi le droit de modification. Le commentaire dans le code disait la bonne chose, il disait « l’équivalent est l’autorisation de console », mais le code faisait autre chose.

Cela a été trouvé en mesurant contre la définition propre de Proxmox, et cela a été corrigé. Le résultat de la mesure était net : Proxmox lie le shell à la seule autorisation de console et n’accepte pas le droit de modification.

Il faut aussi dire le poids réel tel qu’il est : ce n’était pas exploitable avec les rôles intégrés, car le seul rôle intégré contenant le droit de modification possède aussi l’autorisation de console. Le risque était dans les rôles personnalisés, c’est-à-dire dans l’exemple de l’opérateur réseau décrit plus haut.

La leçon qui en découle vaut aussi pour le produit lui-même : qu’un commentaire ait raison ne veut pas dire que le code a raison. Les deux doivent être mesurés séparément.