81 votes

Quand utiliser pkexec vs. gksu/gksudo ?

Il existe deux façons générales d'exécuter des applications graphiquement en tant que root (ou, plus généralement, en tant qu'autre utilisateur). Des programmes comme gksu , gksudo y kdesudo sont des interfaces graphiques pour sudo . En revanche, pkexec est un frontal graphique pour PolicyKit .

Lorsque manuellement exécuter des programmes en tant que root (ou en tant qu'autre utilisateur non-root), quels sont les avantages/inconvénients (s'il y en a) de l'utilisation de la fonction pkexec par rapport à la méthode plus traditionnelle de l'utilisation d'une sudo front-end ?

26voto

RobinJ Points 8448

PolicyKit est plus configurable, cependant pkexec ne fait pas appel à cette configurabilité. Aussi, pkexec montrer à l'utilisateur le chemin complet du programme qui sera lancé, afin que l'utilisateur soit un peu plus sûr de ce qui va se passer. Les "politiques" de PolicyKit peuvent être utilisées pour définir des paramètres plus avancés. Par exemple, si le mot de passe doit être mémorisé.

Quelque chose que j'ai obtenu de la pkexec manuel :

L'environnement dans lequel PROGRAM l'exécutera sera réglé à un minimum de connu et sûr, afin d'éviter l'injection de code par le biais de LD_LIBRARY_PATH ou d'autres mécanismes similaires. En outre, la variable d'environnement PKEXEC_UID est définie comme l'identifiant de l'utilisateur du processus invoquant pkexec. Par conséquent, pkexec ne vous permettra pas d'exécuter, par exemple, des applications X11 sous la forme d'un autre utilisateur, puisque la variable d'environnement $DISPLAY n'est pas définie.

Plus d'informations sur politiques o définitions des actions de la pkexec manuel :

   To specify what kind of authorization is needed to execute the program
   /usr/bin/pk-example-frobnicate as another user, simply write an action
   definition file like this

       <?xml version="1.0" encoding="UTF-8"?>
       <!DOCTYPE policyconfig PUBLIC
        "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
        "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
       <policyconfig>

         <vendor>Examples for the PolicyKit Project</vendor>
         <vendor_url>http://hal.freedesktop.org/docs/PolicyKit/</vendor_url>

         <action id="org.freedesktop.policykit.example.pkexec.run-frobnicate">
           <description>Run the PolicyKit example program Frobnicate</description>
           <description xml:lang="da">Kør PolicyKit eksemplet Frobnicate</description>
           <message>Authentication is required to run the PolicyKit example program Frobnicate</message>
           <message xml:lang="da">Autorisering er påkrævet for at afvikle PolicyKit eksemplet Frobnicate</message>
           <icon_name>audio-x-generic</icon_name>
           <defaults>
             <allow_any>no</allow_any>
             <allow_inactive>no</allow_inactive>
             <allow_active>auth_self_keep</allow_active>
           </defaults>
           <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/pk-example-frobnicate</annotate>
         </action>

       </policyconfig>

   and drop it in the /usr/share/polkit-1/actions directory under a
   suitable name (e.g. matching the namespace of the action). Note that in
   addition to specifying the program, the authentication message,
   description, icon and defaults can be specified. For example, for the
   action defined above, the following authentication dialog will be
   shown:

       [IMAGE][2]

           +----------------------------------------------------------+
           |                     Authenticate                     [X] |
           +----------------------------------------------------------+
           |                                                          |
           |  [Icon]  Authentication is required to run the PolicyKit |
           |          example program Frobnicate                      |
           |                                                          |
           |          An application is attempting to perform an      |
           |          action that requires privileges. Authentication |
           |          is required to perform this action.             |
           |                                                          |
           |          Password: [__________________________________]  |
           |                                                          |
           | [V] Details:                                             |
           |  Command: /usr/bin/pk-example-frobnicate                 |
           |  Run As:  Super User (root)                              |
           |  Action:  org.fd.pk.example.pkexec.run-frobnicate        |
           |  Vendor:  Examples for the PolicyKit Project             |
           |                                                          |
           |                                  [Cancel] [Authenticate] |
           +----------------------------------------------------------+

   If the user is using the da_DK locale, the dialog looks like this:

       [IMAGE][3]

           +----------------------------------------------------------+
           |                     Autorisering                     [X] |
           +----------------------------------------------------------+
           |                                                          |
           |  [Icon]  Autorisering er påkrævet for at afvikle         |
           |          PolicyKit eksemplet Frobnicate                  |
           |                                                          |
           |          Et program forsøger at udføre en handling der   |
           |          kræver privilegier. Autorisering er påkrævet.   |
           |                                                          |
           |          Kodeord: [___________________________________]  |
           |                                                          |
           | [V] Detaljer:                                            |
           |  Bruger:   Super User (root)                             |
           |  Program:  /usr/bin/pk-example-frobnicate                |
           |  Handling: org.fd.pk.example.pkexec.run-frobnicate       |
           |  Vendor:   Examples for the PolicyKit Project            |
           |                                                          |
           |                                [Annullér] [Autorisering] |
           +----------------------------------------------------------+

   Note that pkexec does no validation of the ARGUMENTS passed to PROGRAM.
   In the normal case (where administrator authentication is required
   every time pkexec is used), this is not a problem since if the user is
   an administrator he might as well just run pkexec bash to get root.

   However, if an action is used for which the user can retain
   authorization (or if the user is implicitly authorized), such as with
   pk-example-frobnicate above, this could be a security hole. Therefore,
   as a rule of thumb, programs for which the default required
   authorization is changed, should never implicitly trust user input
   (e.g. like any other well-written suid program).

15voto

Paul Hänsch Points 3057

Avec sudo, vous pouvez définir des règles par utilisateur et par programme pour conserver ou réinitialiser l'environnement de l'appelant dans le contexte de sudo. La politique env_reset est définie par défaut.

Vous ne pouvez pas exécuter d'applications graphiques via pkexec sans le configurer explicitement pour le faire. Comme il s'agit simplement d'un résultat de la réinitialisation de l'environnement, cela est évidemment vrai aussi pour sudo. Notez cependant que ni pkexec ni sudo ne peuvent empêcher une application malveillante s'exécutant en tant que root de récupérer toutes les informations nécessaires à partir des gestionnaires d'affichage ou du fichier X11-cookie de l'utilisateur. Cette dernière opération, ou des opérations similaires, peut même être effectuée par des applications non root, selon les circonstances.

Sudo ne requiert pas de listes explicites d'utilisateurs. Il est possible de lister n'importe quel groupe d'utilisateurs ou même de définir une permission pour tous les utilisateurs en général. La directive target_pw permet à ces utilisateurs de s'authentifier avec les informations d'identification de l'utilisateur dans le contexte duquel ils veulent exécuter une application, c'est-à-dire root. En outre, le tout aussi traditionnel programme su (su / gtksu / kdesu) peut être utilisé pour faire la même chose sans configuration particulière.

sudo, également, permet à l'utilisateur de rester authentifié pendant une durée déterminée. L'option est nommée timeout, configurable globalement, par utilisateur, ou par application. L'authentification peut être conservée par tty ou globalement par utilisateur.

Alors que pkexec ne fait pas de validation des ARGUMENTS passés à PROGRAM, sudo dispose effectivement de cette fonctionnalité. Cependant, il faut admettre que vous pouvez facilement vous tromper avec cela, et cela n'est normalement pas fait.

Vous pouvez modifier un peu la façon dont vous voulez que les programmes soient lancés via pkexec : icône, texte à afficher, vous pouvez même avoir des trucs de localisation et tout ça. Selon les circonstances, cela peut être très pratique. Il est cependant triste que quelqu'un ait ressenti le besoin de réinventer la roue pour cette fonctionnalité. Ce serait probablement quelque chose à mettre dans les wrappers graphiques de gtksudo/kdesu.

Policykit n'est donc qu'un cadre de configuration centralisé. Malheureusement pas un joli cadre. Les fichiers XML de Policykit sont bien plus compliqués que tout ce qu'une application pourrait fournir nativement, à part des fichiers binaires. Et personne ne serait assez fou pour utiliser des fichiers binaires ... oh gconf ... peu importe.

8voto

DublinJimbo Points 314

Quelques éléments comment pkexec est différent de sudo et ses interfaces :

  1. Vous ne pouvez pas exécuter des applications graphiques via pkexec sans le configurer explicitement pour le faire.
  2. Vous pouvez modifier un peu la façon dont vous voulez que les programmes soient exécutés via pkexec Il peut s'agir de l'icône, du texte à afficher, de la mémorisation ou non du mot de passe, de l'autorisation de l'exécution graphique, etc.
  3. N'importe qui peut exécuter "Run as" en tant que superutilisateur (à condition de pouvoir s'authentifier en tant que tel), avec sudo vous devez être inscrit dans le sudoers en tant que admin .
  4. gksudo verrouille le clavier, la souris et le focus lors de la demande d'un mot de passe, pkexec ne le fait pas. Dans les deux cas les frappes au clavier sont cependant reniflables. .
  5. Avec pkexec vous travaillez dans un environnement un peu plus aseptisé.

Essayez par exemple :

cd /etc/init.d
sudo cat README
# and now the same with pkexec
pkexec cat README
# nice, huh?

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X