Quando usar pkexec vs. gksu / gksudo?

Question

Existem duas maneiras gerais de executar aplicativos graficamente como root (ou, mais geralmente, como outro usuário). Programas como gksu , gksudo e kdesudo são front ends gráficos para sudo . Em contraste, pkexec é uma interface gráfica para PolicyKit .

Quando manualmente executa programas como raiz (ou como outro usuário não raiz), quais são as vantagens / desvantagens de usar pkexec , em comparação com o método mais tradicional de usando um frontend sudo ?

    

Answer 1

O PolicyKit é mais configurável, embora pkexec não faça uso dessa configurabilidade. Além disso, pkexec mostra ao usuário o caminho completo do programa que será iniciado, para que o usuário tenha mais certeza do que irá acontecer. As chamadas 'políticas' do PolicyKit podem ser usadas para definir mais configurações de adiantamentos. Por exemplo, se a senha deve ser lembrada.

Algo que recebi do manual 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.

Mais informações sobre políticas ou definições de ação no pkexec manual:

   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).

    

Answer 2

Com o sudo, você pode definir políticas por usuário e por programa para manter ou redefinir o ambiente de chamadores no contexto do sudo. A política env_reset é definida por padrão.

Você não pode executar aplicativos gráficos via pkexec sem configurá-lo explicitamente para isso. Como isso é meramente um resultado da reinicialização do ambiente, isso também é obviamente verdadeiro para o sudo. Note, entretanto, que nem o pkexec nem o sudo podem impedir que um aplicativo mal-intencionado rodando como root recupere todas as informações necessárias dos gerenciadores de exibição ou do arquivo X11-cookie dos usuários. O último, tanto ou similar, pode até mesmo ser feito por aplicativos não-root, dependendo das circunstâncias.

O Sudo não exige listagens explícitas de usuários. Listar qualquer grupo de usuários ou até mesmo definir uma permissão para todos os usuários em geral pode ser feito. A diretiva target_pw permite que esses usuários se autentiquem com as credenciais do usuário em cujo contexto eles desejam executar um aplicativo, ou seja, root. Além disso, o programa igualmente tradicional su (su / gtksu / kdesu) pode ser usado para fazer o mesmo sem configuração especial.

O

sudo também permite que o usuário permaneça autenticado por um tempo especificado. A opção é denominada tempo limite, configurável globalmente, por usuário ou por aplicativo. A autenticação pode ser retida por tty ou globalmente por usuário.

Embora o pkexec não faça nenhuma validação dos ARGUMENTOS passados para o PROGRAM, o sudo realmente possui esse recurso. Admitido, você pode facilmente atrapalhar com isso, e isso normalmente não é feito.

Você pode ajustar um pouco como você quer que os programas sejam executados via pkexec: ícone, texto para exibir, você pode até ter material de localização e tudo mais. Dependendo das circunstâncias, isso pode ser realmente bacana. Infelizmente, alguém sentiu a necessidade de reinventar a roda para esse recurso. Isso provavelmente seria algo para colocar nos invólucros gráficos do gtksudo / kdesu.

O Policykit é apenas uma estrutura de configuração centralizada. Infelizmente não é bonita. PKs XML-Files são muito mais complicados do que qualquer coisa que um aplicativo possa fornecer em arquivos binários. E ninguém seria tão maluco para usar binário ... oh gconf ... não importa.

    

Answer 3

Algumas coisas como pkexec é diferente de sudo e seus frontends:

1. Você não pode executar aplicativos gráficos via pkexec sem configurá-lo explicitamente para fazer isso.
2. Você pode ajustar um pouco como deseja que os programas sejam executados por meio de pkexec : ícone, texto a ser exibido, se deseja lembrar a senha ou não, se ela deve ser executada graficamente e um pouco mais.
3. Qualquer pessoa pode executar "Executar como" um superusuário (desde que possa autenticar como tal), com sudo você precisa estar listado no arquivo sudoers como admin .
4. gksudo bloqueia o teclado, o mouse e o foco ao solicitar uma senha, pkexec não. Em ambos os casos, as teclas são sniffable embora .
>
5. Com pkexec você trabalha em um ambiente um pouco mais higienizado.

Tente por exemplo:

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