(Parte 1 de 3)

6 http://www.linuxmagazine.com.br

Privilégios administrativos com o PolicyKit

Poderes ao alcance das mãos

Se o Linux fechar as portas para você, o primeiro impulso pode ser recorrer ao comando su ou sudo. O PolicyKit oferece uma abordagem mais flexível para atribuir privilégios administrativos. por Tim Schürmann

Por padrão, o Linux delega responsabilidades: o único usuário com permissão de modificar as configurações do sistema é o onipresente root. Os usuários normais estão restritos ao seu desktop.

No uso diário, essa restrição pode ser um aborrecimento, especialmente se for preciso apenas montar um pendrive USB ou ajustar o horário do relógio. Quando vários usuários compartilham um PC, o usuário root precisa assumir o teclado para efetuar as mudanças.

Um projeto recente chamado PolicyKit [1] oferece uma solução mais refinada ao problema de configurar privilégios de acesso. O PolicyKit suporta gerenciamento independente de privilégios que lembra um auxílio à lista telefônica: os programas do Linux podem “fazer uma ligação” para saber se um determinado usuário tem permissão de executar uma função específica do sistema.

Chame o administrador

No Ubuntu, quando se tenta acertar o horário do sistema, antes que a janela escondida em Sistema / Administração / Hora e data permita a mudança, é preciso clicar antes no ícone do cadeado ou do escudo. Depois de fazer isso, a janela Configurações de data e hora irá perguntar ao PolicyKit se há autorização para ajustar o relógio.

Para responder essa pergunta, o

PolicyKit checa o conjunto de regras, que dirá que é possível acertar o relógio se você for membro do grupo Administradores e puder informar a senha correta. O PolicyKit pede, então, que o gerenciador de desktop Gnome peça a senha.

O Gnome faz isso imediatamente, abrindo uma janela como mostra a figura 1. Quando o PolicyKit possui todas as informações necessárias, ele libera janela Configurações de data e hora, que por sua vez desbloqueia a funcionalidade do diálogo.

Com essa abordagem, o PolicyKit pode liberar ou proibir privilégios de modo orientado. Por exemplo, é possível permitir que um usuário, a quem chamarei de carlo, acerte o relógio sem ter acesso a nenhuma outra função do sistema. Em comparação com su e sudo, os aplicativos envolvidos aqui não recebem privilégios de root; isto é, carlo não terá permissão de usar a janela de hora e data para configurar o fuso Figura 1 No Gnome, o PolicyKit dá acesso às configurações de data e horário.

| SEGURANÇAPolicyKit

Linux Magazine #70 | Setembro de 2010 horário ou acessar qualquer outra parte do sistema.

Jogos de números Esse admirável mundo novo do PolicyKit possui alguns problemas. Por exemplo, o aplicativo e a distribuição precisam suportar o PolicyKit – pelo menos no Ubuntu, até agora. O OpenSUSE 1.2 e o Fedora 12 ainda exigem a senha de root para a maioria das configurações do sistema. O OpenSUSE usa o PolicyKit para permitir que qualquer usuário atualize softwares, mas somente para isso.

Além disso, a versão 0.9.1 do sistema foi completamente reformulada; as versões mais recentes do PolicyKit não podem mais ser usadas com programas mais antigos. Por isso, os desenvolvedores tiveram que modificar ou reformar todos os aplicativos que suportam o PolicyKit, fazendo com que os distribuidores oferecessem as versões mais recentes e as mais antigas. A última versão é extra-oficialmente chamada de PolicyKit-1 ou polkit-1 para distingui-la das outras.

A última versão não suporta o gerenciador gráfico de privilégios, que funciona apenas em versões mais antigas do PolicyKit, até a 0.9.0, mais precisamente. Para as tarefas de gerenciamento de privilégios, a única alternativa é usar seu editor favorito, mas isso não é tão complicado quanto se possa imaginar.

Dono da casa O PolicyKit-1 faz distinção entre usuários normais e administradores. Os administradores podem ajustar as configurações do sistema por padrão, como o root. Os arquivos de configuração em /etc/polkit-1/localauthority.conf.d definem os membros. Assim que instalado, o PolicyKit possui um único arquivo, 50-localauthority.conf, com o conteúdo:

[Configuration] AdminIdentities=unix-user:0 que instrui o PolicyKit a solicitar a senha (unix-user) do usuário com ID 0 para todos (AdminIdentities) que precisam de privilégios de administrador. Logicamente, o ID 0 designa o usuário root. Em outras palavras, instalar o PolicyKit não muda as coisas em nada. No Ubuntu, um segundo arquivo de configuração, chamado 51-ubuntu-admin.conf, sobrescreve essa regra com o seguinte conteúdo:

[Configuration] AdminIdentities=unix-group:admin

Seguindo esses parâmetros, todos os membros do grupo de usuários admin são automaticamente administradores privilegiados. É fácil modificar o padrão de acordo com suas necessidades, na próxima vez em que atualizar o sistema, o arquivo voltará para seu estado original e todo seu trabalho irá se perder. Felizmente, o PolicyKit avalia seus arquivos de configuração em ordem lexicográfica, portanto, criar seu próprio arquivo de configuração irá sobrescrever qualquer outro cujo nome principiar com um número menor.

Para dar privilégios administrativos aos usuários adam e bonny, basta criar um arquivo 60-myconfig.conf no diretório /etc/polkit-1/localauthority.conf.d com o seguinte conteúdo:

[Configuration] AdminIdentities=unix-group:admin; unix-user:adam;unix-user:bonny

O nome do arquivo não importa, ele só precisa começar com um número mais alto do que os outros (60 nesse exemplo). Os futuros administradores estão separados por ponto e vírgula e vêm depois de AdminIdentities=. Os indivíduos adam e bonny precisam do prefixo unix-user:. Os grupos são indicados por unix-group:.

Quem pode mais? Regras definem que tem permissão para chamar funções do sistema. O PolicyKit os chama de “Authorization Entries” (Entradas de Autorização) e os agrupa em subdiretórios no diretório /etc/polkit-1/localauthority. Algumas regras estão em 50-local.d; a tabela 1 lista os outros.

Tabela 1: Pastas para entradas de autorização

Diretório Conteúdo 10-vendor.d Regras do distribuidor

20-org.d Regras feitas pela organização que distribui o sistema operacional

30-site.d Regras feitas pelo site que distribui o sistema operacional

50-local.d Regras locais

90-mandatory.d Regras feitas pela organização que distribui o sistema operacional

Listagem 1: Acertar o relógio

01 Carlo allowed to set the 02 Identity=unix-user:carlo 03 Action=o rg.gnome.clockapplet.mechanism.settime 04 ResultActive=yes 05 ResultInactive=no 06 ResultAny=no

68 http://www.linuxmagazine.com.br

SEGURANÇA | PolicyKit

Para permitir que o usuário sem privilégios carlo acerte o relógio, será preciso criar um novo arquivo de configuração com a extensão .pkla (PolicyKit Local Authority).

Mais uma vez, o nome do arquivo não faz diferença: o PolicyKit simplesmente avalia todos os arquivos .pkla desse diretório em ordem lexicográfica ascendente. Entretanto, faz sentido escolher um nome intuitivo. Para o carlo que vai acertar o relógio, o arquivo seria como o da listagem 1.

Uma descrição entre chaves abre o arquivo, seguida da palavra-chave Identity= e o usuário ou usuários a quem se aplicam as seguintes alterações de privilégios. Múltiplos usuários e grupos precisam ser separados por vírgulas (como mencionado antes) após as conhecidas palavras-chaves unix-user: ou unix-group.

A linha seguinte contém o nome da função do sistema ou ação em questão, org.clockapplet.mechanism. settime, que se refere ao ajuste do relógio no Gnome. Digitar pkaction --verbose na linha de comando irá informar quais outras ações o PolicyKit suporta. Essa lista pode ser bem longa, dependendo de sua distribuição; o comando a seguir redireciona a saída para um arquivo texto list.txt para facilitar a inspeção:

$ pkaction --verbose > list.txt

O prompt de diálogo da senha no

Gnome, mostrado na figura 3, fornece outra informação útil. A seção Details revela qual Action (ação) o usuário tentou fazer.

No arquivo .pkla, é possível usar wildcards (*) para agrupar múltiplas ações. Por exemplo,

Action=org.gnome.clockapplet. mechanism.* modifica todas as ações que começam por org.gnome.clockapplet.mechanism ao mesmo tempo. Isso quer dizer que o usuário carlo pode acertar a hora e mudar o fuso horário.

Privilégios As últimas três linhas da regra na listagem 1 definem os privilégios. Quando o usuário carlo tentar qualquer ação na sessão atual, o PolicyKit confere ResultActive= configurado com yes e permite que carlo altere o horário

Quadro 1: Armadilhas da senha

O comportamento do pkexec com prompts de senhas é lógico, porém confuso à primeira vista. Com o comando

$ pkexec - -user bonny apt-get install gnuchess você inicia o pkexec. O PolicyKit solicita então sua própria senha. Não há acesso ao diretório /var/lib/dpkg, por isso o apt-get também se recusa a instalar o programa. Para instalar o gnuchess como o usuário bonny, é preciso primeiro fazer o login como este usuário e depois digitar o comando pkexec apt-get install gnuchess

O PolicyKit irá pedir agora a senha do usuário bonny, iniciar o apt-get com privilégios de root e instalar o gnuchess – assumindo que nenhuma regra do PolicyKit impeça isso.

(Parte 1 de 3)

Comentários