Polkit / pkexec

agp91 · 25-09-2024 10:12:12

Vous trouverez dans le post suivant quelques explications sur le fonctionnement de polkit/pkexec, démontré via gparted
Ceci à débuté par une discutions dans un autre fil, qui pour ne pas l'encombrer a été déplacée ici.

Tawal a écrit :

ggrev31 a écrit :
Il faut juste à chaque fois, que je précise mon mot de passe utilisateur.

C'est normal, seuls les utilisateurs ayants des permissions peuvent déverrouiller l'authentification.

Edit:
Je viens de tester avec mon 2ième utilisateur n'ayant aucun privilèges.
J'ai lancé la commande
/usr/sbin/gparted
dans un terminal.
Magique ! Une demande graphique de mot de passe de … l'utilisateur ayant les droits !
Bon cet utilisateur privilégié était connecté lors du test.
Mais quand même pourquoi ne pas demander le mot de passe root dans ce cas ?

mister_g a écrit :

tu as deux possibilités.

soit ton utilisateur fait partie de la liste des sudoers (c'est a dire qu'il apparait dans la liste des utilisateurs paramétrés dans sudo avec la possibilité d'escalader des privilèges).
soit ce n'est pas le cas.

Dans le premier cas, le mot de passe de l'utilisateur suffit pour lancer gparted.
Dans l'autre cas non. Dès lors le mot de passe root est demandé.

a toi de faire la configuration que tu souhaites en ajoutant ou enlevant des utilisateurs dans la configuration de sudo

dans ton exemple, ton 2eme utilisateur est bien paramétré dans sudo, mais le 1er utilisateur n'y est pas.

Tawal a écrit :

Non pas si clair que ça !

Utilisateur 1 : droits sudo (fait partie du groupe sudo)
Utilisateur 2 : Aucun droits privilégiés.

Utilisateur 1 lance Gparted ==> demande graphique de son mot de passe - normal.
Utilisateur 2 lance Gparted ==> demande graphique de mot de passe de l'Utilisateur 1 - pas normal, j'aurais préféré la demande du mot de passe root.

agp91 a écrit :

Salux,
Tawal a écrit :
Utilisateur 1 : droits sudo (fait partie du groupe sudo)
Utilisateur 2 : Aucun droits privilégiés.

Utilisateur 1 lance Gparted ==> demande graphique de son mot de passe - normal.
Utilisateur 2 lance Gparted ==> demande graphique de mot de passe de l'Utilisateur 1 - pas normal, j'aurais préféré la demande du mot de passe root.
C'est normal... L'utilisateur 1 est considérer comme administrateur en appartenant au groupe sudo. En utilisant l'utilisateur2 (qui n'a aucun privilège), c'est le mdp du premier utilisateur administrateur trouvé qui est demandé.
J'ai écris cela car c'était le cas aussi pour moi.
Mais j'ai actuellement un système tout neuf (que je viens de réinstallé).
Pour tester cela je viens d'installer gparted... Et avec l'utilisateur 1 ou 2, c'est le mdp de root qui m'ai demandé.
Je suis perplexe https://debian-facile.org/img/smilies/x … chhead.gif

ubub a écrit :

agp91 a écrit :
Pour tester cela je viens d'installer gparted... Et avec l'utilisateur 1 ou 2, c'est le mdp de root qui m'ai demandé.

l'utilisateur 1 ou 2 fait partie des sudoers ?
Tant que je n'étai pas "sudoer", fallait que je tape le mdp root, puis ça a changé quand je me suis enregistré dans sudo ...

agp91 a écrit :

L'utilisateur 1 fait partie du groupe sudo
L'utilisateur 2 non
Lorsque je me connecte avec l'utilisateur 1,
Que je lance gparted depuis les menus, pkexec me demande le mot de passe root (comme avec l'utilisateur 2)
De même si depuis le terminal je lance
pkexec /usr/sbin/gparted

Par contre avec la commande
sudo gparted
, sudo me demande le mdp de cet utilisateur.

[edit]
Hihi, je viens de me reconnecté avec l'utilisateur 1
Maintenant quand je lance gparted depuis le menu c'est son mdp qui est demandé.
De retour sous l'utilisateur 2, c'est maintenant le mdp de l'utilisateur 1 qui est demandé par pkexec.
https://debian-facile.org/img/smilies/xtras/acid.gif
Du coup c'est comme avant et ce que j'avais écris plus haut était juste :
agp91 a écrit :
C'est normal... L'utilisateur 1 est considérer comme administrateur en appartenant au groupe sudo. En utilisant l'utilisateur2 (qui n'a aucun privilège), c'est le mdp du premier utilisateur administrateur trouvé qui est demandé.

Tawal a écrit :

Non,; ce n'est pas normal.

Pour moi faire partie du groupe sudo et être root ne sont pas la même chose.
On peut restreindre des droit même pour le groupe sudo.

Donc si je n'ai pas de droits alors c'est le MDP rot qui doit être demandé.

ubub a écrit :

agp91 a écrit :
En utilisant l'utilisateur2 (qui n'a aucun privilège), c'est le mdp du premier utilisateur administrateur trouvé qui est demandé.

bizarre, en effet,
agp91 a écrit :
De retour sous l'utilisateur 2, c'est maintenant le mdp de l'utilisateur 1 qui est demandé par pkexec.

Le mdp de l'user1 qui est demandé? ou un mdp, et tu tapes celui de user1 ?
pour ce que j'en ai compris, en l'absence de droits, pkexec demande un mdp crée pour l'ocase ..

if no authentication agent is available, then pkexec will register its own textual authentication agent

mais j'ai du mal à tout piger ...

agp91 a écrit :

Tawal a écrit :
Pour moi faire partie du groupe sudo et être root ne sont pas la même chose.
Je suis en accord avec ce que tu écris là. Je me suis sûrement mal exprimer pour moi être administrateur, ne signifie pas être root (quand je suis root, je suis root). Être administrateur, c'est avoir des privilèges d'administration que n'ont pas les autres utilisateurs, par exemple via sudo.
Tawal a écrit :
On peut restreindre des droit même pour le groupe sudo.
Tout à fait mais pas avec
%sudo ALL=(ALL:ALL) ALL
Qui donne pratiquement les même droit que root à ceux qui appartiennet au groupe sudo (pratiquement car il y a quelque bricoles que l'on ne peux pas faire sans être véritablement root, via sudo)
Tawal a écrit :
Donc si je n'ai pas de droits alors c'est le MDP root qui doit être demandé.
Dans certains système, le mot de passe root n'est pas connu (par personne). Dans des systèmes fortement sécurisés le mdp root est fort (très long et complexe) pour résister à la force brut. N'étant pas connu, il n'est pas noté quelque par. Inconnu, il ne peux pas être saisi et échappe ainsi aux keylogers.

agp91 a écrit :

ubub a écrit :
agp91 a écrit :
De retour sous l'utilisateur 2, c'est maintenant le mdp de l'utilisateur 1 qui est demandé par pkexec.

Le mdp de l'user1 qui est demandé? ou un mdp, et tu tapes celui de user1 ?
Celui de l'utilisateur 1, pkexec indique Mot de passe pur utilisateur 1
pkexec a écrit :
Il est nécessaire de s'authentifier pour lancer l'éditeur de partitions Gparted en tant qu'un utilisateur root
Une application tente d'effectuer une action qui nécessite des privilèges. Pour effectuer cette action, l'utilisateur principale doit s'authentifier.
Mot de passe pour l'utilisateur 1 :
Remarque : Il en va de même lorsque je lance synaptic depuis la session de l'utilisateur 2
ubub a écrit :
mais j'ai du mal à tout piger ...
Idem
Je pense que pkexec à étudie le groupe sudo, mais je ne suis pas sur. Car la première fois que j'ai lancé gparted depuis l’utilisateur 1 (qui appartenait déjà au groupe sudo), c'est le mdp de root qui m'avait été demandé. Je sais que maintenant se sera le mdp de cet utilisateur (l'utilisateur 1) qui me sera demandé (je viens de contrôler cela en changeant le mdp de l'utilisateur1).

Dernière modification par agp91 (26-09-2024 16:38:18)

agp91 · 25-09-2024 10:34:31

Je ne sais pas comment j'ai pu obtenir la demande du mdp root avec un utilisateur appartenant au groupe sudo (l'utilisateur 1).
Car je n'ai pu reproduire ce résultat. Le mot mdp root est demandé que si aucun utilisateur appartient au groupe sudo
Je me dis que j'ai du mal retenir ce que j'ai fait.
Et j'ai du utilisé le mdp de l'utilisateur 1 (appartenant au groupe sudo) lorsque j'ai lancé la première fois gparted depuis le menu avec l'utilisateur 1 ou 2.

Si dessous je vais essayer d'expliquer comment est obtenu l'autorité nécessaire pour lancer gparted.

Debian utilise la bibliothèque polkit pour qu'un processus sans privilège puisse exécuter un processus privilégié.
Polkit utilise la commande pkexec (ou une API D-Bus) pour controler l'autorisation à escalader les privilèges (devenir root ou l'utilisateur précisé par l'option -u de pkexec).
Polkit permet d'exécuter un processus root sans en connaitre le mot de passe. En ce sens il ressemble à sudo.
Mais polkit n'est pas sudo. Sudo demande le mdp de l'utilisateur qui lance sudo. Polkit/pkexec demande le mdp de l'utilisateur qui est configuré.
Pour exécuter un client (programme) désigné comme action du mécanisme. Polkit un utilise des règles pour désigner l'utilisateur sans privilège qui permettra l'escalade.
Les actions sont définis dans des fichiers au format xml, placés dans le répertoire /usr/share/polkit-1/actions
Les règles sont écrites en java dans des fichiers placés dans les répertoires /etc/polkit-1/rules.d et /usr/share/polkit-1/rules.d

page de manuel polkit a écrit :

...
DÉCLARER DES ACTIONS

Un mécanisme doit déclarer un ensemble d'actions pour pouvoir utiliser polkit. Les actions correspondent aux opérations que les clients peuvent demander au mécanisme d'effectuer et sont définies dans des fichiers XML que le mécanisme installe dans le répertoire /usr/share/polkit-1/actions.

Les actions polkit sont classées par espace de noms et ne peuvent contenir que les caractères « [AZ][az][0-9].- », par exemple ASCII, chiffres, point et trait d'union. Chaque fichier XML peut contenir plusieurs actions, mais toutes les actions doivent être dans le même espace de noms et le fichier doit être nommé d'après l'espace de noms et avoir l'extension .policy.
...
RÈGLES D'AUTORISATION

polkitd lit .rules les fichiers des répertoires /etc/polkit-1/rules.d et /usr/share/polkit-1/rules.d en triant les fichiers dans l'ordre lexical en fonction du nom de base de chaque fichier (en cas d'égalité, les fichiers de /etc sont traités avant les fichiers de /usr). Par exemple, pour les quatre fichiers suivants, l'ordre est
- /etc/polkit-1/rules.d/10-auth.rules
- /usr/share/polkit-1/rules.d/10-auth.rules
- /etc/polkit-1/rules.d/15-auth.rules
- /usr/share/polkit-1/rules.d/20-auth.rules

Les deux répertoires sont surveillés, donc si un fichier de règles est modifié, ajouté ou supprimé, les règles existantes sont purgées et tous les fichiers sont lus et traités à nouveau. Les fichiers de règles sont écrits dans le langage de programmation JavaScript et s'interfacent avec polkitd via l'objet global polkit (de type Polkit ).
...

Lorsque gparted est installé, une action polkit pour gparted est ajoutée dans /usr/share/polkit-1/actions/org.gnome.gparted.policy
Dans ce fichier se trouve le bloc defaults qui permet de définir le type d'autorisation sollicitée.

page de manuel polkit a écrit :

...
defaults
Cet élément est utilisé pour spécifier des autorisations implicites pour les clients. Les éléments qui peuvent être utilisés dans les valeurs par défaut incluent :

allow_any
Autorisations implicites qui s’appliquent à n’importe quel client. Facultatif.
allow_inactive
Autorisations implicites qui s'appliquent aux clients dans les sessions inactives sur les consoles locales. Facultatif.
allow_active
Autorisations implicites qui s'appliquent aux clients dans les sessions actives sur les consoles locales. Facultatif.

Chacun des éléments Allow_any, Allow_inactive et Allow_active peut contenir les valeurs suivantes :

no
Non autorisé.
yes
Autorisé.
auth_self
L'authentification par le propriétaire de la session d'où provient le client est requise. Notez que cela n'est pas suffisamment restrictif pour la plupart des utilisations sur les systèmes multi-utilisateurs ; auth_admin* est généralement recommandé.
auth_admin
L'authentification par un utilisateur administrateur est requise.
auth_self_keep
Comme auth_self mais l'autorisation est conservée pendant une courte période (par exemple cinq minutes). L'avertissement concernant auth_self ci-dessus s'applique également.
auth_admin_keep
Comme auth_admin mais l'autorisation est conservée pendant une brève période (par exemple cinq minutes).
...

La configuration est écrite en xml entre les balises <defaults> et </defaults>, dans /usr/share/polkit-1/actions/org.gnome.gparted.policy

sed -n '/defaults/,/defaults/p'  /usr/share/polkit-1/actions/org.gnome.gparted.policy

        <defaults>

            <allow_any>auth_admin</allow_any>

            <allow_inactive>auth_admin</allow_inactive>

            <allow_active>auth_admin</allow_active>

        </defaults>

Ainsi lorsque l'on souhaite exécuter gparted, pkexec est appelé pour demander le mot de passe d'un utilisateur administratif.
Reste à savoir comment est déterminé un utilisateur administratif.

... Lors de l'installation de polkit, une règle par défaut est fournie (/usr/share/polkit-1/rules.d/50-default.rules).
Cette règle désigne les utilisateurs appartenant au groupe sudo comme administrateurs.
Si aucun utilisateur appartient au groupe sudo, c'est le mdp de root qui est demandé.
Note : Le groupe sudo est utilisé uniquement pour désigner les administrateurs. Les droits sudo qu'il donne (configurés dans /etc/sudoers), n'ont aucun impact à l’escalade des privilèges.
Note2 : Le répertoire /usr/share/polkit-1/rules.d n'est accessible que pour root.

cat /usr/share/polkit-1/rules.d/50-default.rules

/* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */

// DO NOT EDIT THIS FILE, it will be overwritten on update

//

// Default rules for polkit

//

// See the polkit(8) man page for more information

// about configuring polkit.

polkit.addAdminRule(function(action, subject) {

    return ["unix-group:sudo"];

});

Le manuel polkit a écrit :

...
Le type Polkit
Les méthodes suivantes sont disponibles sur l'objet polkit :
void addRule(polkit.Result function(action, subject) {...});
void addAdminRule(string[] function(action, subject) {...});
void log(string message);
string spawn(string[] argv);
La méthode addRule() est utilisée pour ajouter une fonction qui peut être appelée à chaque fois qu'une vérification d'autorisation pour l'action et le sujet est effectuée. Les fonctions sont appelées dans l'ordre dans lequel elles ont été ajoutées jusqu'à ce que l'une d'elles renvoie une valeur. Par conséquent, pour ajouter une règle d'autorisation qui est traitée avant les autres règles, placez-la dans un fichier dans /etc/polkit-1/rules.d avec un nom qui trie avant les autres fichiers de règles, par exemple 00-early-checks.rules. Chaque fonction doit renvoyer une valeur de polkit.Result
polkit.Result = {
NO : "no",
YES : "yes",
AUTH_SELF : "auth_self",
AUTH_SELF_KEEP : "auth_self_keep",
AUTH_ADMIN : "auth_admin",
AUTH_ADMIN_KEEP : "auth_admin_keep",
NOT_HANDLED : null
};
correspondant aux valeurs qui peuvent être utilisées comme valeurs par défaut. Si la fonction renvoie polkit.Result.NOT_HANDLED, null, undefined ou ne renvoie aucune valeur, la fonction utilisateur suivante est essayée.
...
La méthode addAdminRule() est utilisée pour ajouter une fonction qui peut être appelée chaque fois que l'authentification de l'administrateur est requise. La fonction est utilisée pour spécifier les identités qui peuvent être utilisées pour l'authentification de l'administrateur pour le contrôle d'autorisation identifié par action et subject . Les fonctions ajoutées sont appelées dans l'ordre dans lequel elles ont été ajoutées jusqu'à ce que l'une des fonctions renvoie une valeur. Chaque fonction doit renvoyer un tableau de chaînes où chaque chaîne est de la forme "unix-group:<group>", "unix-netgroup:<netgroup>" ou "unix-user:<user>". Si la fonction renvoie null , undefined ou ne renvoie aucune valeur, la fonction suivante est essayée.
...

Note : Si plusieurs utilisateurs appartienne au groupe sudo, pkexec propose un menu déroulant pour choisir l'utilisateur qui doit être utilisé pour s'authentifier.

En l'état, le groupe sudo est bien choisi, car ainsi configuré celui qui connaît le mot de passe d'un administrateur à les mêmes possibilités que ceux qui appartiennent au groupe sudo et qui utilisent sudo.
Ainsi, ceux qui appartiennent aux groupe sudo peuvent tout faire, même devenir root sans en connaître le mdp (qu'ils utilisent sudo ou polkit/pkexec).
... Ce qui est carrément dangereux en terme de sécurité.

Pour séparé polkit/pkexec du groupe sudo, nous pouvons ajouter une règle dans /etc/polkit-1/rules.d

echo 'polkit.addAdminRule(function(action, subject) {

    return ["unix-group:<autre_groupe>"];

});

' >/etc//polkit-1/rules.d/50-default.rules

Ainsi ce sera le mot de passe d'un des utilisateurs appartennant au groupe <autre_groupe> que sera soliciter.
Nous pouvons aussi spécifier directement un utilisateur

echo 'polkit.addAdminRule(function(action, subject) {

  return ["unix-user:<utilisateur>"];

});

' >/etc//polkit-1/rules.d/50-default.rules

Ainsi ce sera le mdp de l'utilisateur <utilisateur> qui sera demandé.

Par défaut polkit/pkexec est permissif : Celui qui connaît le mdp qui va bien peut tout faire (même devenir root).
Pour changer cela et forcer polkit a demander le mdp de root pour tout ce qui ne dispose pas d'une action dans /usr/share/polkit-1/actions, il suffit d'ajouter la règle

echo 'polkit.addAdminRule(function(action, subject) {

  if (action.id == "org.freedesktop.policykit.exec") {

    return polkit.Result.NO;

  }

});

' > /etc/polkit-1/rules.d/40-strict.rules

Ou plus strict encore : Interdire l'usage de polkit/pkexec pour tout ce qui n'est pas déclaré par une action.

echo 'polkit.addRule(function(action, subject) {

  if (action.id == "org.freedesktop.policykit.exec") {

    return polkit.Result.NO;

  }

});

' > /etc/polkit-1/rules.d/40-strict.rules

Dernière modification par agp91 (25-09-2024 10:55:48)

Tawal · 25-09-2024 20:18:21

Très intéressant et instructif

En effet, comme je n'ai qu'un seul utilisateur dans le groupe sudo,
je ne peux pas voir le menu déroulant proposant les utilisateurs "admin" lors de l'utilisation de pkexec.

agp91 · 26-09-2024 16:33:25

Tawal a écrit :

Donc si je n'ai pas de droits alors c'est le MDP root qui doit être demandé.

Si c'est le comportement désiré :

Si l'utilisateur appartient au groupe sudo -> Demander son mdp
Si l'utilisateur n'appartient pas au groupe sudo -> Demander le mot de passe root

Alors la règle suivante doit être ajoutée :

echo '// Default rules for polkit

polkit.addAdminRule(function(action, subject) {

  if (subject.isInGroup("sudo")) {

    return ["unix-group:sudo"] ;

  } else {

    return ["unix-user:root"] ;

  }

}) ;

' >/etc/polkit-1/rules.d/50-default.rules

Dernière modification par agp91 (27-09-2024 05:48:12)

Tawal · 27-09-2024 01:54:06

Merci encore.
Une petite erreur dans le nom du répertoire : plokit ==> polkit

Dernière modification par Tawal (27-09-2024 01:54:57)

agp91 · 27-09-2024 05:49:04

Tawal a écrit :

Une petite erreur dans le nom du répertoire : plokit ==> polkit

Corrigé

Debian-facile

#1 25-09-2024 10:12:12

Polkit / pkexec

#2 25-09-2024 10:34:31

Re : Polkit / pkexec

#3 25-09-2024 20:18:21

Re : Polkit / pkexec

#4 26-09-2024 16:33:25

Re : Polkit / pkexec

#5 27-09-2024 01:54:06

Re : Polkit / pkexec

#6 27-09-2024 05:49:04

Re : Polkit / pkexec

Pied de page des forums