Quand utiliser pkexec contre gksu / gksudo?

73

Il existe deux manières générales d'exécuter des applications graphiquement en tant qu'utilisateur root (ou, plus généralement, en tant qu'un autre utilisateur). Des programmes tels que gksu , gksudo , et / a> sont des interfaces graphiques pour kdesudo . En revanche, sudo est une interface graphique pour PolicyKit .

Lorsque manuellement exécutez des programmes en tant que root (ou en tant qu'utilisateur non-root), quels sont les avantages / inconvénients (le cas échéant) de l'utilisation de pkexec par rapport à la méthode plus traditionnelle de en utilisant un pkexec frontend?

    
posée Eliah Kagan 11.11.2011 - 21:44
la source

3 réponses

25

PolicyKit est plus configurable, bien que pkexec n’utilise pas cette configurabilité. De plus, pkexec montre à l'utilisateur le chemin complet du programme qui sera lancé, pour que l'utilisateur soit un peu plus sûr de ce qu'il va se passer. Les «stratégies» de PolicyKit peuvent être utilisées pour définir davantage de paramètres d’avancée. Par exemple, si le mot de passe doit être mémorisé.

Quelque chose que j'ai reçu du manuel pkexec :

The environment that PROGRAM will run it, will be set to a minimal known and safe environment in order to avoid injecting code through LD_LIBRARY_PATH or similar mechanisms. In addition the PKEXEC_UID environment variable is set to the user id of the process invoking pkexec. As a result, pkexec will not allow you to run e.g. X11 applications as another user since the $DISPLAY environment variable is not set.

Plus d'informations sur les stratégies ou les définitions d'action du manuel pkexec :

   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).
    
réponse donnée RobinJ 12.11.2011 - 16:35
la source
14

Avec sudo, vous pouvez définir des stratégies par utilisateur et par programme pour conserver ou réinitialiser l’environnement des appelants dans le contexte de sudo. La stratégie env_reset est définie par défaut.

Vous ne pouvez pas exécuter d'applications graphiques via pkexec sans le configurer explicitement. Comme il ne s'agit que du résultat de la réinitialisation de l'environnement, ceci est également vrai pour sudo. Notez cependant que ni pkexec ni sudo ne peuvent empêcher une application malveillante de s'exécuter en tant que root pour récupérer toutes les informations nécessaires à partir des gestionnaires d'affichage ou du fichier de cookies X11 de l'utilisateur. Ces dernières, qu'elles soient identiques ou similaires, peuvent même être effectuées par des applications non root, selon les circonstances.

Sudo ne nécessite pas de listes explicites d’utilisateurs. Vous pouvez répertorier n'importe quel groupe d'utilisateurs ou même définir une autorisation pour tous les utilisateurs. La directive target_pw permet à ces utilisateurs de s’authentifier avec les informations d’identité de l’utilisateur dans le contexte duquel ils souhaitent exécuter une application, c’est-à-dire root. En dehors de cela, le programme tout aussi traditionnel su (su / gtksu / kdesu) peut être utilisé pour faire la même chose sans configuration spéciale.

sudo permet également à l'utilisateur de rester authentifié pendant un temps spécifié. L'option est nommée timeout, configurable globalement, par utilisateur ou par application. L’authentification peut être conservée par utilisateur ou globalement par utilisateur.

Bien que pkexec ne puisse pas valider les ARGUMENTS transmis à PROGRAM, sudo dispose bien de cette fonctionnalité. Admis cependant, vous pouvez facilement déconner, et ce n’est normalement pas fait.

Vous pouvez modifier un peu la manière dont vous voulez que les programmes soient exécutés via pkexec: icône, texte à afficher, vous pouvez même avoir des tâches de localisation, etc. En fonction des circonstances, cela peut être astucieux. Malheureusement, cette personne a ressenti le besoin de réinventer la roue de cette fonctionnalité. Ce serait probablement quelque chose à mettre dans les wrappers graphiques gtksudo / kdesu.

Policykit n’est alors qu’un cadre de configuration centralisé. Malheureusement pas une jolie. Les fichiers XML de PKs sont bien plus compliqués que tout ce qu'une application pourrait fournir de manière native à court de fichiers binaires. Et personne ne voudrait utiliser si binaire ... oh gconf ... ça ne fait rien.

    
réponse donnée Paul Hänsch 26.10.2012 - 14:47
la source
8

Quelques différences entre pkexec et sudo et ses interfaces:

  1. Vous ne pouvez pas exécuter d'applications graphiques via pkexec sans le configurer explicitement.
  2. Vous pouvez modifier un peu la manière dont vous voulez que les programmes soient exécutés via pkexec : icon, le texte à afficher, si vous souhaitez conserver le mot de passe ou non, s'il doit être autorisé à être exécuté graphiquement et plus encore.
  3. N'importe qui peut exécuter "Exécuter en tant que" superutilisateur (à condition de pouvoir s'authentifier en tant que tel). Avec sudo , vous devez être répertorié dans le fichier sudoers en tant que admin .
  4. gksudo verrouille le clavier, la souris et la mise au point lorsque vous demandez un mot de passe, pkexec ne le fait pas. Dans les deux cas, les frappes au clavier sont néanmoins reniflants .
  5. Avec pkexec , vous travaillez dans un environnement légèrement plus assaini.

Essayez par exemple:

cd /etc/init.d
sudo cat README
# and now the same with pkexec
pkexec cat README
# nice, huh?
    
réponse donnée arrange 15.11.2011 - 23:59
la source

Lire d'autres questions sur les étiquettes