Pourquoi et comment exécuter une station de test sans droits root

Lancer une station de test en root (Linux) ou en administrateur (Windows) est le moyen le plus rapide de débloquer l'accès au matériel, mais c'est une facilité qui se paie plus tard, en surface d'attaque et en fragilité au quotidien. Le réflexe le plus rentable tient en une phrase : ne faites pas tourner la station avec un compte administrateur. Ce guide part de là, puis montre jusqu'où pousser le moindre privilège sous Linux et Windows sans sacrifier ni l'accès au matériel ni le démarrage automatique.

Le raccourci et son coût

Quand l'objectif est de déployer vite, faire tourner la station entièrement en root est souvent le chemin le plus court : un périphérique a renvoyé Permission denied, et passer root débloque tout de suite. Avec le temps, ça se fige sous l'une de ces formes :

Parfois c'est l'urgence, parfois c'est un outil fournisseur qui réclame vraiment root sans échappatoire ce jour-là. Le résultat est le même, et l'addition grimpe : elle se répète sur chaque poste, ressort à chaque audit, et vous suit sur chaque machine renvoyée en réparation. La bonne règle n'est pas « ne jamais élever les droits », mais élever pour installer, jamais pour exécuter : root a sa place le temps d'une mise en place (logiciels, pilotes, règles de périphériques), pas comme identité qui enchaîne les tests, run après run.

La solution pérenne : un compte sans droits admin

Sans passer par une configuration avancée, un seul changement fait tomber l'essentiel du risque pour presque rien : l'opérateur ouvre sa session avec un compte standard, sans droits admin, et la station tourne en mode kiosque. C'est le 80/20.

Un compte standard protège autant l'opérateur de la machine que la machine de l'opérateur : il ne doit tout simplement pas pouvoir faire ce qui ne le regarde pas. Le mode kiosque fait l'objet d'un guide à part ; ce qui compte ici, c'est que le compte qui exécute la station ne soit pas administrateur. Tout ce qui suit sert à tenir cette ligne sans perdre l'accès au matériel ni le démarrage automatique.

Ce que coûte le root, côté sécurité

Le moindre privilège, c'est du confinement d'erreur : le pendant logiciel du fusible qu'on met sur un circuit au lieu de parier qu'il n'y aura jamais de court-circuit. Une station de test lit en continu des fichiers qu'elle n'a pas produits (images firmware, données de calibration, trames série, config tirée d'un partage), et le moindre bug s'exécute avec les droits du processus.

Le risque d'élévation est assez réel pour qu'un outillage sérieux refuse carrément de l'ouvrir : la CLI TofuPilot n'installe pas de service de démarrage root si le binaire se trouve dans un répertoire modifiable par l'utilisateur, car quiconque pourrait le remplacer se retrouverait root au prochain boot. Côté traçabilité, l'enjeu est aussi devenu business : un compte admin permanent sur un poste d'atelier vaut de plus en plus un échec d'audit CMMC / NIST 800-171, rédhibitoire dès qu'on fournit l'aérospatial, la défense ou un EMS exigeant. Quant au rayon d'impact, c'est ce que les équipes sécurité appellent le mouvement latéral : un attaquant qui prend pied sur une station trop permissive rebondit sur toute l'usine avant que quiconque s'en aperçoive.

« De toute façon, la station est hors ligne »

L'argument classique pour justifier le root, c'est « la station n'a pas internet, alors quel risque ? ». Il repose sur un malentendu. La station est coupée d'internet, mais elle est presque toujours raccordée à un réseau local sécurisé, visible depuis d'autres machines et souvent capable d'atteindre le MES et le serveur de production où sont centralisées les données.

Si la DSI a accepté la contrainte, franchement pénible, d'une station hors ligne, c'est justement parce que les machines et les données de ce réseau sont sensibles. « Hors ligne » ne veut donc pas dire « sécurité facultative », mais l'inverse : elle y pèse plus lourd qu'ailleurs. Une station en root sur ce réseau, c'est une porte d'entrée commode vers tout le reste : précisément le mouvement latéral que l'isolement était censé empêcher. Les supports amovibles achèvent le tableau : même hors ligne, une station reçoit des firmwares sur clé USB et repart un jour en réparation (le ver Stuxnet a atteint des systèmes industriels isolés justement par clé USB).

Le principe : élever pour installer, jamais pour exécuter

La suite montre comment mettre ça en place, sous Linux puis sous Windows.

Linux : mise en place au moindre privilège

Étape 1 : Faire tourner la station sous un compte sans droits

Le compte qui exécute la station doit être un utilisateur ordinaire, sans droits admin : ni root, ni membre de sudo/wheel. Sur la plupart des bancs, c'est déjà le compte operator du kiosque.

# Un compte ordinaire, sans privilèges, pour la station. Pas dans sudo/wheel/adm.
# L'opérateur ouvre sa session et lance l'UI kiosque, mais ne touche pas au système.
sudo useradd --create-home operator
id operator   # à vérifier : ni sudo, ni wheel, ni adm

Étape 2 : Donner accès au matériel par les groupes, pas par root

Si l'on passe root, c'est presque toujours pour une histoire de permissions de périphérique. La bonne réponse, c'est l'appartenance à un groupe : rattachez le compte operator au groupe qui possède déjà le périphérique.

# Les ports série (/dev/ttyUSB*, /dev/ttyACM*) appartiennent au groupe 'dialout'
sudo usermod -aG dialout operator
# Les instruments USB branchés à chaud relèvent en général du groupe 'plugdev'
sudo usermod -aG plugdev operator

# Repérer le groupe propriétaire du périphérique (4e colonne)
ls -l /dev/ttyUSB0
# crw-rw---- 1 root dialout 188, 0 ... /dev/ttyUSB0
#                   ^^^^^^^ le groupe qui donne l'accès

Pour un périphérique qui n'appartient à aucun groupe standard, écrivez une règle udev (udev est le sous-système Linux qui attribue propriétaire et permissions aux périphériques au fur et à mesure qu'ils apparaissent) :

# Cibler un instrument précis par ses identifiants USB vendor/product et le
# confier au groupe 'dialout' (celui de l'opérateur). Aucun root en exécution.
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="dialout", MODE="0660"

sudo udevadm control --reload-rules && sudo udevadm trigger

Si un binaire réclame un privilège noyau bien précis (par exemple l'I/O brut pour flasher un firmware), accordez-lui cette seule capability au lieu de root. Les capabilities découpent les pouvoirs de root en droits indépendants :

# N'accorder que l'I/O brut à ce binaire, rien d'autre de ce que root permet
sudo setcap cap_sys_rawio+ep /usr/local/bin/flash-tool
getcap /usr/local/bin/flash-tool

Étape 3 : Démarrer au boot sans repasser par root

C'est là que root revient d'habitude par la petite porte. Quand vous activez Lancement au démarrage, la CLI TofuPilot installe toute seule le bon service, inutile d'écrire un fichier unit à la main :

Le piège qui pousse vers root : si vous activez le démarrage automatique via SSH sous le compte operator, donc dans un shell sans session graphique, systemctl --user n'a aucun bus de session auquel se connecter, et échoue :

Failed to connect to bus: No medium found
systemctl --user: Failed to connect to user scope bus

La solution n'est pas de repasser en root. C'est d'autoriser les services de l'operator à tourner sans session ouverte. C'est ce que systemd appelle le lingering (comme une machine qui garde sa routine de fond active même quand personne n'est devant l'IHM) :

# Les services systemd de l'operator démarrent au boot, sans session ouverte
sudo loginctl enable-linger operator
loginctl show-user operator --property=Linger   # -> Linger=yes

Le lingering activé, la station sans droits root démarre à chaque boot, garde son écran kiosque et n'a plus jamais besoin de root pour se lancer. Les identifiants suivent le même compte : lancez tofupilot login --token <jeton> en tant qu'operator, surtout pas en sudo.

Étape 4 : Vérifier le moindre privilège

# Le processus de la station doit tourner sous 'operator', pas root
ps -o user,cmd -C tofupilot
# Lancer le test EN TANT QU'operator (sudo -u bascule d'identité, il n'élève pas les droits)
sudo -u operator cat /dev/ttyUSB0   # doit s'ouvrir grâce au groupe dialout, pas de « Permission denied »

Windows : mise en place au moindre privilège

Même logique : le compte operator est un utilisateur standard, pas un administrateur. Windows simplifie l'essentiel, car un utilisateur standard a déjà tout ce qu'il faut pour une station de test.

# Utilisateur local standard (surtout PAS dans le groupe Administrateurs)
$pw = Read-Host -AsSecureString "Mot de passe du compte operator"
New-LocalUser -Name "operator" -Password $pw -PasswordNeverExpires `
  -Description "Opérateur de station de test"
# Volontairement omis : Add-LocalGroupMember -Group "Administrators"

# Donner au compte operator son propre dossier de travail, en écriture
New-Item -ItemType Directory -Path "C:\tofupilot" -Force
icacls "C:\tofupilot" /grant "operator:(OI)(CI)M"

Sous Windows, la station s'exécute comme un processus rattaché à la session du compte operator : elle démarre à l'ouverture de session, sans service admin ni privilèges SYSTEM. Rangez la clé API dans l'environnement utilisateur de l'operator, ou dans un fichier sous C:\tofupilot réservé à ce seul compte, jamais à l'échelle de la machine.

Quand root reste le choix pragmatique

La bonne pratique se heurte parfois à la productivité, et celui qui connaît vraiment les contraintes, le développeur au banc en plein rush, est le mieux placé pour trancher. Chez TofuPilot, on ne bloque pas ce choix : la CLI tourne en root ou en admin si vous le décidez, parce qu'en pleine cadence, lever une friction de déploiement compte plus que d'imposer une rigueur de principe. Lancée en root, la CLI installe d'ailleurs pour vous le bon service système.

Si vous exécutez en root, faites-le en connaissance de cause et réduisez l'exposition :

L'objectif n'est pas la pureté, mais la lucidité : mesurer ce que coûte le raccourci pour décider en toute connaissance, et revenir au moindre privilège une fois l'urgence passée.

Troubleshooting