Linux : comment déléguer des droits et autorisations root avec PolKit ?

I. Présentation

Dans ce tutoriel, nous allons voir comment déléguer des droits et autorisations root à un utilisateur standard avec PolKit.

Les tâches d'administration système de base, telles que l'ajout de disques, la configuration réseau, les mises à jour, etc. requièrent généralement des privilèges root ou l'appartenance à un groupe d'administrateurs. Un utilisateur standard n'y a pas accès.

Cependant, comment procéder si ce dernier souhaite, par exemple, mettre à jour son PC sans toutefois en être administrateur ?

La solution la plus simple serait de l'introduire dans le groupe sudo. Sauf que cela lui permettrait d'aller au-delà de l'action pour laquelle il a été introduit dans le groupe. Il pourrait même rendre le système indisponible s'il le veut ou s'il en est capable.

• Comment utiliser sudo sous Linux ? Notre guide complet avec des exemples

Il existe cependant un outil permettant à un utilisateur non-administrateur d'effectuer des tâches d'administration Linux, sans toutefois être membre du groupe sudo. Cet outil se nomme PolKit (initialement PolicyKit). Il s'agit ici d'applicatifs permettant de définir et gérer la communication entre les processus privilégiés et non privilégiés, autorisant ainsi des utilisateurs standards à effectuer des tâches d'administration, sans toutefois être administrateurs.

Autrement dit, lorsqu'un utilisateur standard souhaite, par exemple, télécharger et installer les mises à jour sur son PC, il s'adressera directement à PolKit. C'est ce dernier qui ira alors lancer le service d'installation de mises à jour à sa place.

Cela permet ainsi à l'administrateur système d'optimiser son temps, en se concentrant sur des tâches complexes plutôt que sur des opérations routinières. On verra donc ici comment utiliser ces applicatifs pour déléguer certains droits d'administration à des utilisateurs standard

Remarque : Tous les services administratifs sous Linux ne sont pas soumis à PolKit. Donc, il faut bien se renseigner sur le service à déléguer avant toute configuration.

II. Configuration générale de Polkit

La configuration dépend de deux types de fichiers : les fichiers d'actions et les fichiers de règles d'autorisation.

A. Fichiers d'actions

Les fichiers d'actions sont généralement au format XML et portent l'extension .policy. Ils sont situés dans le répertoire /usr/share/polkit-1/actions.

Chaque fichier dépend du paquet installé. Certains fichiers sont conçus pour plusieurs environnements de bureau (org.freedesktop.*), certains pour un seul environnement (com.ubuntu.*) et d'autres pour un seul service ou application (power-profiles-daemon).

L'essentiel de la configuration est contenu dans la balise policyconfig, dont les éléments sont les suivants :

• Les balises vendor et vendor_url renseignent sur l'éditeur.
• La balise action définit l'action possible dans la policy. L'attribut id souvent sous la forme d'une URI renversée, indique la commande réelle renvoyée à D-BUS.
• Les balises description et message indiquent à l'utilisateur à quoi servent la policy et si une authentification est requise ou non.
• La balise defaults indique l'endroit où se trouvent les permissions ou non. Elle contient trois types de balises qui font office ici de paramètres : allow_any, allow_inactive, et allow_active.

Pour chacun de ces paramètres, les options ci-dessous sont disponibles :

• no : l'utilisateur n'est pas autorisé à effectuer l'action.
• yes : l'utilisateur est autorisé à effectuer l'action sans aucune authentification.
• auth_self : l'authentification est nécessaire, mais l'utilisateur ne doit pas nécessairement être administrateur.
• auth_admin : l'authentification en tant qu'administrateur est requise.
• auth_self_keep : identique à auth_self mais l'autorisation dure quelques minutes.
• auth_admin_keep : identique à auth_admin mais l'autorisation dure quelques minutes.

Voici en image l'exemple d'un fichier d'actions :

B. Fichiers de règles

Les fichiers de règles quant à eux sont au format JavaScript et portent l'extension .rules. Ils sont souvent aussi sous la forme d'une URI renversée, sont généralement situés dans le répertoire /usr/share/polkit-1/rules.d.

Ils contiennent au moins chacun des éléments suivants :

• Une méthode AddRule utilisée pour ajouter une fonction pouvant être appelée chaque fois qu'un contrôle d'autorisation pour l'action et l'utilisateur est effectué.
• Une fonction avec les paramètres action pour la commande D-BUS et subject pour l'utilisateur ou le groupe concerné.
• Une structure conditionnelle composée de l'instruction if pour vérifier la relation entre les paramètres action et subject, et de l'instruction return pour autoriser ou refuser l'action à l'aide de la méthode Result et des booléens YES ou NO.
• Un ou plusieurs opérateurs logiques "et" (&&), "ou" (||) et "égale à" (==) pour créer des liens entre les paramètres de la fonction.

Les fichiers de règles peuvent également être commentés.

Voici en image l'exemple d'un fichier de règles :

Remarque : Il est souvent recommandé, pour certaines configurations, de créer ses propres fichiers d'actions ou de règles. Car certains fichiers par défaut peuvent être modifiés ou simplement effacés lors des mises à jour. Ceci impacterait aussi nos configurations avec délégation de droits. Les fichiers mis à jour potentiellement ont souvent un commentaire d'avertissement.

III. Exemple de configuration de PolKit

Ici, nous avons sur un poste Linux (Ubuntu), un administrateur (meister) et un utilisateur standard (test1). On aimerait que l'utilisateur test1 puisse configurer ses propres paramètres réseaux et installer des mises à jour sur le PC sans être administrateur.

On verra donc ici comment lui déléguer ces droits-là avec PolKit.

Les modifications et autres configurations se font ici sous sudo. L'id de l'utilisateur test1 sur notre PC Ubuntu est 1001.

A. Installation de PolKit

PolKit est déjà fourni avec des distributions Linux telles qu'Ubuntu. Si ce n'est pas le cas avec la vôtre, un simple sudo apt install policykit-1 dans le terminal permet de l'installer.

Une fois installé, un agent d'authentification (pkttyagent) sert à déterminer si l'utilisateur d'une session est administrateur ou non.

Le nom de cet agent peut varier en fonction de l'environnement graphique sous lequel on travaille. Sous Ubuntu, ce dernier s'appelle polkit-agent-helper-1 et se trouve dans le répertoire /usr/lib/polkit-1/.

Donc, il est primordial de vérifier si cet agent se lance au démarrage avant de continuer la configuration. La commande ci-dessous permet de le vérifier :

pgrep -af polkit


1030 /usr/lib/polkit-1/polkitd --no-debug

Sinon, il faut penser à l'intégrer à la liste des services et applications qui démarrent en même temps que le système.

Remarque : la configuration de délégation de droits est possible tant au niveau des fichiers d'actions qu'au niveau des fichiers de règles. Pour ce tutoriel, on ira plutôt éditer les fichiers de règles.

B. Déléguer la configuration du réseau

Initialement, le mot de passe d'un compte administrateur est requis à chaque fois que l'utilisateur standard veut modifier les paramètres de sa carte réseau.

On va donc voir ici comment lui permettre de configurer sa carte réseau sans être administrateur.

Ici, on se limitera juste à configurer les paramètres DNS de la carte réseau (DNS primaire et DNS secondaire). On lui indiquera ceux de Cloudflare et de Google comme résolveurs DNS en lieu et place de 192.168.1.1.

Une règle pour la gestion des paramètres réseaux est déjà disponible par défaut sur le PC (org.freedesktop.NetworkManager.rules). On va donc la modifier en y ajoutant la directive '|| subject.isInGroup ("test1")' dans l'instruction if. Puis, on sauvegarde le tout et on ferme le fichier.

vim /usr/share/polkit-1/rules.d/org.freedesktop.NetworkManager.rules

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.NetworkManager.settings.modify.system" &&
        subject.local && subject.active &&
        (subject.isInGroup ("sudo") || subject.isInGroup ("test1") || subject.isInGroup ("netdev"))) {
        return polkit.Result.YES;

Ce qui donne en image :

On se connecte ensuite avec notre utilisateur test1. Dans les paramètres réseaux, on insère respectivement 1.1.1.1 et 8.8.8.8 comme DNS primaire et secondaire. On ne devrait plus être confronté à l'insertion d'un mot de passe administrateur quelconque.

Allons vérifier tout cela dans les logs. On doit bien pouvoir retrouver des informations telles que l'id de notre utilisateur (1001), le nom de profil de notre carte réseau (" connexion filaire 1 "), la méthode de configuration manuelle (' args="ipv4.ignore-auto-dns,ipv4.dns" '), l'indication de réussite de l'opération (' result="success" ') ainsi que les adresses IP des nouveaux résolveurs DNS (1.1.1.1, 8.8.8.8 ).

cat /var/log/syslog

2025-03-24T17:37:30.497565+01:00 PC NetworkManager[757]: <info>  [1742834250.4969] audit: op="connection-update" uuid="1feb562d-81b4-308d-86c2-5d56dc272fda" name="Connexion filaire 1" args="connection.timestamp,ipv4.ignore-auto-dns,ipv4.dns" pid=3518 uid=1001 result="success"
2025-03-24T17:37:30.528887+01:00 PC NetworkManager[757]: <info>  [1742834250.5267] audit: op="device-reapply" interface="ens33" ifindex=2 args="ipv4.ignore-auto-dns,ipv4.dns" pid=3518 uid=1001 result="success"

...

2025-03-24T17:37:31.781876+01:00 PC systemd-resolved[573]: ens33: Bus client set DNS server list to: 1.1.1.1, 8.8.8.8

En image, cela donne :

C. Déléguer l'installation des mises à jour

Par défaut, un utilisateur standard doit saisir le mot de passe administrateur pour installer les mises à jour.

Pour contourner cette restriction, on va éditer le fichier de règles org.freedeskptop.packagekit.rules. Ensuite, on va récupérer l'attribut id org.freedesktop.packagekit.system-update dans le fichier d'actions org.freedesktop.packagekit.policy. On vient l'insérer dans le bloc de l'instruction "if" de notre fichier de règles comme suit : '|| action.id == "org.freedesktop.packagekit.system-update" '.

On ajoute ensuite le groupe test1 comme groupe autorisé comme suit : '|| subject.isInGroup ("test1")'.

On sauvegarde le tout et on ferme le fichier.

vim /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules

polkit.addRule(function(action, subject) {
    if ((action.id == "org.freedesktop.packagekit.upgrade-system" ||
         action.id == "org.freedesktop.packagekit.trigger-offline-update" ||
         action.id == "org.freedesktop.packagekit.system-update" ) &&
        subject.active == true && subject.local == true &&
        subject.isInGroup("sudo") || subject.isInGroup("test1")) {
            return polkit.Result.YES;
    }
});

Ce qui donne en image :

Si on se connecte avec l'utilisateur test1 et qu'on tente l'installation des mises à jour, on ne devrait plus avoir à entrer un mot de passe administrateur.

On peut aussi vérifier tout ceci dans les logs du système. On y retrouve bien l'id (1001) de notre utilisateur standard.

vim /var/log/syslog

2025-03-28T09:48:19.402176+01:00 PC dbus-daemon[3367]: [session uid=1001 pid=3367] Activating service name='org.freedesktop.FileManager1' requested by ':1.34' (uid=1001 pid=4433 comm="/usr/bin/gnome-shell" label="unconfined")

...

2025-03-28T09:49:37.136562+01:00 PC dbus-daemon[860]: [system] Activating via systemd: service name='org.freedesktop.PackageKit' unit='packagekit.service' requested by ':1.202' (uid=0 pid=11422 comm="/usr/bin/gdbus call --system --dest org.freedeskto" label="unconfined")                                                                     2025-03-28T09:49:37.189825+01:00 PC PackageKit: daemon start
2025-03-28T09:49:37.190112+01:00 PC systemd[1]: Starting packagekit.service - PackageKit Daemon...
2025-03-28T09:49:37.254887+01:00 PC dbus-daemon[860]: [system] Successfully activated service 'org.freedesktop.PackageKit'                                                2025-03-28T09:49:37.255987+01:00 PC systemd[1]: Started packagekit.service - PackageKit Daemon.       

Ce qui donne :

On peut encore aller plus loin en allant vérifier la liste des paquets mis à jour avec la commande cat /var/log/apt/history.log. On peut d'ailleurs constater que l'heure et la date de début et de fin de mises à jour correspondent bien à ceux présents dans les logs du système.

cat /var/log/apt/history.log

Start-Date: 2025-03-28  09:48:16
Commandline: aptdaemon role='role-commit-packages' sender=':1.183'
Install: linux-modules-6.11.0-21-generic:amd64 (6.11.0-21.21~24.04.1, automatic), linux-hwe-6.11-tools-6.11.0-21:amd64 (6.11.0-21.21~24.04.1, automatic), linux-modules-extra-6.11.0-21-generic:amd64 (6.11.0-21.21~24.04.1, automatic), linux-tools-6.11.0-21-generic:amd64 (6.11.0-21.21~24.04.1, automatic), linux-image-6.11.0-21-generic:amd64 (6.11.0-21.21~24.04.1+1, automatic), linux-headers-6.11.0-21-generic:amd64 (6.11.0-21.21~24.04.1, automatic), linux-hwe-6.11-headers-6.11.0-21:amd64 (6.11.0-21.21~24.04.1, automatic)
Upgrade: linux-headers-generic-hwe-24.04:amd64 (6.11.0-19.19~24.04.1, 6.11.0-21.21~24.04.1), linux-generic-hwe-24.04:amd64 (6.11.0-19.19~24.04.1, 6.11.0-21.21~24.04.1), linux-tools-common:amd64 (6.8.0-55.57, 6.8.0-56.58), openssh-client:amd64 (1:9.6p1-3ubuntu13.8, 1:9.6p1-3ubuntu13.9), libdebuginfod1t64:amd64 (0.190-1.1build4.1, 0.190-1.1ubuntu0.1), tzdata:amd64 (2024b-0ubuntu0.24.04.1, 2025a-0ubuntu0.24.04), libdebuginfod-common:amd64 (0.190-1.1build4.1, 0.190-1.1ubuntu0.1), ssh:amd64 (1:9.6p1-3ubuntu13.8, 1:9.6p1-3ubuntu13.9), libgs10-common:amd64 (10.02.1~dfsg1-0ubuntu7.4, 10.02.1~dfsg1-0ubuntu7.5), libgs10:amd64 (10.02.1~dfsg1-0ubuntu7.4, 10.02.1~dfsg1-0ubuntu7.5), openssh-server:amd64 (1:9.6p1-3ubuntu13.8, 1:9.6p1-3ubuntu13.9), ghostscript:amd64 (10.02.1~dfsg1-0ubuntu7.4, 10.02.1~dfsg1-0ubuntu7.5), linux-image-generic-hwe-24.04:amd64 (6.11.0-19.19~24.04.1, 6.11.0-21.21~24.04.1), libdw1t64:amd64 (0.190-1.1build4.1, 0.190-1.1ubuntu0.1), openssh-sftp-server:amd64 (1:9.6p1-3ubuntu13.8, 1:9.6p1-3ubuntu13.9), libgs-common:amd64 (10.02.1~dfsg1-0ubuntu7.4, 10.02.1~dfsg1-0ubuntu7.5), libelf1t64:amd64 (0.190-1.1build4.1, 0.190-1.1ubuntu0.1), linux-libc-dev:amd64 (6.8.0-55.57, 6.8.0-56.58)
End-Date: 2025-03-28  09:49:36

IV. Conclusion

On vient de voir ici comment déléguer des droits d'administration de façon granulaire à un utilisateur standard sur un système Linux avec PolKit.

Même si cela peut représenter un avantage considérable pour l'administrateur, PolKit reste cependant exposé aux vulnérabilités comme tout autre composant. On se souvient notamment de la CVE-2021-4034 surnommée PwnKit par les chercheurs en sécurité.

Qu'en pensez-vous ?

Émile Fabrice ATANGANA ADZABA Technicien Informatique et Réseau

Technicien Informatique et Réseau, Gérant et Directeur Technique chez MEISTER INFORMATIK, une ESN basée à Yaoundé au Cameroun, spécialisée dans l'installation, la maintenance et le suivi des parcs informatiques des PME et des particuliers. Je partage aussi mes découvertes de recherche via mes articles, ici et ailleurs.

Voir la bio complète