Groupe 4-b: polkitd réfuse sa coopération
polkitd – une introduction
Pour éviter du sens dessus dessous sur un ordinateur, tout système
d'exploitation raisonnable sépare des niveaux de privilèges entre des processus
d'utilisateur et du système.
Tandis que les premiers opèrent par ordre de l'utilisateur, les derniers sont
actifs par ordre du système et au plus sont en prise indirecte avec des actions
de l'utilisateur, mais il peut cependant se produire que des processus non
privilegés doivent communiquer avec des processus privilegés.
Dépendant sur l'action il pourrait être comparativement bénin que justifie
permettre l'accès, mais de temps en temps il peut se produire qu'une action
critique soit demandée. Particulièrement dans ce cas il est important qu'on ne
puisse pas simplement exécuter cette action, parce que tout utilisateur
pourrait, par exemple, installer ou déinstaller des logiciels, potentiellement
avec des conséquences fâcheuses.
Dans ce cas polkitd intervient et détermine selon des
particulières règles quel accès à permettre ou interdire ou lesquelles il faut
autoriser par des tiers. Mais parfois il y a des situations dans lesquelles
polkitd cale l'accès dont on normalement aurait pu
permettre.
Dans ce cas il faut intervenir dans les règles.
On peut trouver ces règles à deux endroits:
- /usr/share/polkit-1
- /etc/polkit-1/rules.d
Ceux-ci sont et des scripts à exécuter par polkitd et
des fichiers XML qui signalent au démon les actuelles règles, et dépendant sur
la distribution il est nécessaire d'avior accès à un particulier répertoire pour
ajuster les paramètres de sécurité.
Avec openSuSE vous aurez de succès dans le répertoire
/etc/polkit-1/rules.d tandis que vous devez ajuster
les fichiers XML dans /usr/share/polkit-1 sous
Débian.
Le seul problème sous openSuSE est que les règles semblent extrêmement
cryptique et l'ordre des permissions paraît contre-intuitif (la dernière valeur
dans les tableaux est associée avec des utilisateurs actifs – la première
valeur par contre spécifie les permissions pour des autres utilisateurs).
Vous pouvez définir comment polkitd doit réagir pour
toutes les trois catégories d'utilisateur (actif, inactif et les autres):
Règle | Signification |
---|---|
no | Rejète l'action. |
yes | Permets l'action. |
auth_self | Demande le mot de passe de l'utilisateur avant que l'action soit permis. |
auth_self_session | Demande le mot de passe de l'utilisateur avant que l'action soit permis. Retiens le mot de passe pour la séance courante. |
auth_self_keep | Demande le mot de passe de l'utilisateur avant que l'action soit permis. Retiens le mot de passe durant plusieurs séances. |
auth_admin | Demande le mot de passe de l'administrateur avant que l'action soit permis. |
auth_admin_session | Demande le mot de passe de l'administrateur avant que l'action soit permis. Retiens le mot de passe pour la séance courante. |
auth_admin_keep | Demande le mot de passe de l'administrateur avant que l'action soit permis. Retiens le mot de passe durant plusieurs séances. |
Lorsqu'un logiciel soudainement réfuse sa coopération, il est recommandé de regarder dans les permissions qu'est réglée quoi et les rajuster en cas de besoin. Enfin il seulement faut faire polkitd lire les nouveaux paramètres.
- Ouvrez un terminal et connectez-vous comme root.
- Changez au répertoire /etc/polkit-1/rules.d.
- Copiez le fichier 90-default-privs.rules au 10-local.rules.
- Chargez le fichier 10-local.rules dans votre éditeur.
- Cherchez pour les entrées qui réfèrent au processus qui est apparemment déjanté là-dedans et effacez le reste si nécessaire.
- Ajustez les règles mises en place en accord de votre besoin.
- Sauvegardez le fichier.
Si vous devez ajuster des additionelles règles ultérieurement, veuillez copier ce qu'il faut ajuster du fichier 90-default-privs.rules au 10-local.rules et ajustez-les appropriément. Vous allez retenir vos règles même si polkitd sera mis à jour et le fichier 90-default-privs.rules sera écrasé dans le cadre de ceci.
Gare!
Considérez bien comment vous ajustez quelles permissions d'accès! Même s'il y a
plusieurs entrées pour le même processus, il est mal ciblé d'ajuster tout au
hasard, parce que toute entrée se réfère à une particulière permission d'accès
du même processus!
Il n'a pas de sens de permettre l'accès au dialogue de configuration pour des
connexions réseau même si vous voulez seulement donner la permission d'activer
ou déconnecter des connexions réseau. En plus vous pouvez évoquer du malheur
par permettre l'accès aux faux points comme tout utilisateur pourrait
tripatouiller dans le système à tout va!
Moins, c'est plus dans ce cas, et si vous avez les doutes, ne permettez pas
l'accès invérifié à la ressource désirée, mais couplez-le à entrer le mot de
passe du superuser avec succès aut simile!
Si vous avez fait les ajustages nécessaires, simplement redémarrez polkitd: systemctl restart polkitd.service
en hautNetworkManager ne peut pas être contrôlé
Lorsque vous vous loguez localement sur un ordinateur, NetworkManager opère
cotumièrement: Lorsque vous voulez connecter à un autre réseau – normalement un
réseau sans fil – simplement choisissez-le et NetworkManager accomplit le
reste.
Lorsque vous vous connectez par XDMCP, tout fonctionnerait similairement – on
pourrait penser.
Mais loin de là! Si vous voulez connecter à un autre
réseau, NetworkManager acquitte ceci avec un commentaire lapidaire que l'action
ne soit pas permis.
Maintenant on pourrait penser que NetworkManager est capricieux lorsqu'on se
connecte à travers un réseau, mais ce n'est pas le cas. C'est les paramètres de
sécurité de polkitd qui font une entourloupette à
vous que devient un problème lorsqu'on voudrait se connecter à un VPN.
Il est juste de protéger les connexions au fil contre la séparation par erreur
pour que l'ordinateur distant reste joignable, mais on ne peut gagner l'accès
aux VPNs, et si on ne veut pas toujours tenir la connexion VPN ouvert, il n'est
aucune option de démarrer le démon VPN directement. Il donc faut relâcher les
contraintes de sécurité à une façon qu'on ne puisse pas séparer une connexion
réseau, mais on a l'accès à une connexion VPN si on donne le bon mot de passe
(normalement de l'administrateur du système). Vous y avez assez de temps à
réagir lorsque vous découvrez que vous avez accédé à la fausse connexion et il
suffit que vous avortez l'action, et si vous avez choisi la bonne connexion,
simplement confirmez l'action par donner le mot de passe du mot de passe de
root.
Mais la question majeure est quel ajustage de NetworkManager il faut modifier
pour que tout aille sans faille. Cette commande y va à votre aide:
cat /etc/polkit-1/rules.d/90-default-privs.rules | grep -A
1 NetworkManager.
La commande cat va présenter le contenu d'un
fichier. Le fichier contenant les valeurs par défaut y est de l'intérêt pour
nous, donc on a son contenu présenté.
Mais comme nous ne voulons pas avoir l'entier ramas de données, il faut qu'il y
a seulement les entrées appropriées presentées à nous. L'outil
grep l'accomplit pour nous en évaluant la sortie de
cat selon d'une
expression régulière
et indique les points appropriés.
Il est seulement une ajustage qui présente de l'intérêt pour nous, quelle est
nanti du marqueur
org.freedesktop.NetworkManager.network-control.
Cherchez pour ce marqueur et regardez la ligne immédiatement en dessous. Vous
verrez les valeurs suivantes: [ 'no', 'no', 'yes' ].
Ceci seulement permet les utilisateurs locals avec une séance active contrôler
les réseaux locales. Cette permission est refusée aux touts autres
utilisateurs.
Ceci n'est pas acceptables pour notre fin, donc modifiez-les comme suivant:
[ 'auth_admin', 'auth_admin', 'yes' ].
Après que vous avez redémarré polkitd vous pouvez
utiliser ces connexions à l'avenir même si vous êtes connectés par XDMCP. Dans
ce cas le mot de passe de l'administrateur du système (soit
root) est demandé de vous pour confirmer l'action.
Si confirmé avec succès, elle est exécute.
Attention!
Ne séparez pas la connexion réseau physique en aucune circonstance si vous êtes connectés d'un ordinateur distant! Vous allez terminer l'accès à travers le réseau, donc quelqu'un a besoin de loguer localement pour établir la connexion réseau encore une fois – et lorsqu'il n'est pas possible, il faut redémarrer l'ordinateur affecté au lieu de cela. Il est donc plus judicieux de demander donner un mot de passe, parce que vous avez la chance d'avorter l'action si vous découvririez que vous avez pris la fausse connexion.
PackageKit demande sans cesse le mot de passe de root
Normalement vous pouvez mettre le système à jour lorsque vous êtes logués sur
votre ordinateur sans que le gestionnaire des packages demande quelconque mot
de passe.
Tant que vous êtes connectés comme un utilisateur local, il n'y a aucun
problème. Mais il est entièrement différent si vous connectez à travers un
réseau, par exemple par XDMCP. Dans ce cas PackageKit
va demander le mot de passe de l'administrateur du système avec insistance, ne
serait-ce qu'il veut mettre des packages vieillis à jour, ne serait-ce qu'il
veut seulement actualiser sa liste des packages, ou il faut accepter un contrat
de licence. Sur la durée ça va se révéler d'être encombrant.
Pour remédier à ce problème il faut modifier quelques règles. Ils sont des entrées avec des marqueurs suivants qui présentent de l'intérêt pour nous:
- org.freedesktop.packagekit.system-update
- org.freedesktop.packagekit.trigger-offline-update
- org.freedesktop.packagekit.system-sources-refresh
- org.freedesktop.packagekit.package-eula-accept
Si vous regardez ces valeurs, vous allez trouver qu'elles sont mises au
[ 'auth_admin_keep', 'auth_admin_keep', 'yes' ],
sauf org.freedesktop.packagekit.system-sources-refresh
qui est mise au [ 'auth_admin_keep', 'no', 'yes' ].
Il est inacceptable pour notre fin, parce qu'il faut confirmer toute action
beau simple. Le potentiel énervant est disproportionné au bénéfice de cette
méthode: Quels dégâts est-ce qu'on pourrait causer par mettre le système à jour
quand il est ciblé à avertir des failles de sécurité?
Pour éviter les demandes énervantes pour le mot de passe de l'administrateur du
système une fois pour toutes concernant des actualisations, veuillez mettre
toutes les quatre valeurs au [ 'yes', 'yes', 'yes' ].
Après redémarrer polkitd le mot de passe de
l'administrateur du système n'est plus demandé de vous, mais le gestionnaire
des packages cherchera automatiquement pour des actualisations, et si vous les
lancez, l'actualisation a lieu sans des additionnelles demandes. Il seulement
pourrait se passer que vous devez confirmer un contrat de licence. Mais il est
seulement nécessaire de cliquer sur «Accepter» pour installer le package.
Demander le mot de passe de l'administrateur du système ne sera plus
nécessaire dans ce cas.