Baixe Privilegios Administrativos e outras Notas de estudo em PDF para Informática, somente na Docsity! 66 http://www.linuxmagazine.com.br S E G U R A N Ç A 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 res-ponsabilidades: o único usuá-rio com permissão de modificar as configurações do sistema é o oni- presente root. Os usuários normais estão restritos ao seu desktop. No uso diário, essa restrição pode ser um aborrecimento, especialmen- te 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 Po- licyKit [1] oferece uma solução mais refinada ao problema de configurar privilégios de acesso. O PolicyKit su- porta 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 acer- tar o horário do sistema, antes que a janela escondida em Sistema / Ad- ministração / Hora e data permita a mudança, é preciso clicar antes no ícone do cadeado ou do escudo. De- pois de fazer isso, a janela Configu- raçõ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 re- ló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 com- paração com su e sudo, os aplicati- vos 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. 67 | 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 Po- licyKit possui alguns problemas. Por exemplo, o aplicativo e a distribui- ção precisam suportar o PolicyKit – pelo menos no Ubuntu, até agora. O OpenSUSE 11.2 e o Fedora 12 ainda exigem a senha de root para a maio- ria das configurações do sistema. O OpenSUSE usa o PolicyKit para per- mitir que qualquer usuário atualize softwares, mas somente para isso. Além disso, a versão 0.9.1 do siste- ma foi completamente reformulada; as versões mais recentes do PolicyKit não podem mais ser usadas com pro- gramas mais antigos. Por isso, os de- senvolvedores 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-ofi- cialmente chamada de PolicyKit-1 ou polkit-1 para distingui-la das outras. A última versão não suporta o ge- renciador gráfico de privilégios, que funciona apenas em versões mais an- tigas do PolicyKit, até a 0.9.0, mais precisamente. Para as tarefas de ge- renciamento de privilégios, a única alternativa é usar seu editor favorito, mas isso não é tão complicado quan- to 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 confi- guração em /etc/polkit-1/localau- thority.conf.d definem os membros. Assim que instalado, o PolicyKit possui um único arquivo, 50-loca- lauthority.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 adminis- trador. 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 admi- nistradores privilegiados. É fácil mo- dificar 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áfi- ca, portanto, criar seu próprio arqui- vo de configuração irá sobrescrever qualquer outro cujo nome principiar com um número menor. Para dar privilégios administrati- vos aos usuários adam e bonny, basta criar um arquivo 60-myconfig.conf no diretório /etc/polkit-1/localauthori- ty.conf.d com o seguinte conteúdo: [Configuration] AdminIdentities=unix-group:admin; unix-user:adam;unix-user:bonny O nome do arquivo não impor- ta, ele só precisa começar com um número mais alto do que os outros (60 nesse exemplo). Os futuros ad- ministradores 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 di- retó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 70 http://www.linuxmagazine.com.br SEGURANÇA | PolicyKit Ação em grupo O PolicyKit só responde a uma requi- sição se souber a ação em questão. Os aplicativos precisam primeiro dizer ao PolicyKit quais funções de sistemas eles oferecem. Para que isso aconteça, inclua a informação necessária em um ou em múltiplos arquivos XML que ficam no subdi- retório /usr/share/polkit-1/actions, onde também está org.gnome.clocka- pplet.mechanism.policy com as ações do applet do relógio do Gnome que requerem autenticação do PolicyKit. Iniciar o programa /usr/bin/apt- get é apenas mais uma ação. Para aplicar o controle de acesso, é pre- ciso acrescentar outro arquivo XML (listagem 3). A estrutura é mais complexa do que os arquivos de configuração que vimos até agora. Os caracteres no início são essenciais em qual- quer arquivo XML. O publisher ou o desenvolvedor são revelados entre as tags <vendor> e </vendor> e o endereço está em <vendor_url>. A definição da ação a ser executada, que inicia em <action id=> e um nome único, ao qual o PolicyKit também se refere por Action ID, vem em seguida. Qualquer nome é válido, contanto que tenha ape- nas números, letras em caixa baixa, pontos e traços. A convenção é usar a URL de trás para frente e anexar o nome da ação. Uma descrição da ação é dada entre as tags <description> e </des- cription>. A instrução <description xml:lang=”en”> é usada para a tradu- ção em inglês. É possível adicionar descrições para outras línguas da mesma maneira; org.gnome.clocka- Tabela 2: Tipos de privilégios do PolicyKit Valor Significado yes O usuário pode iniciar a ação diretamente sem o uso de senha. no Acesso à ação é completamente bloqueado. auth_self O usuário precisa informar sua própria senha. auth_self_keep O usuário precisa informar sua própria senha. O PolicyKit irá guardá-la por alguns segundos. auth_admin O PolicyKit solicita uma senha administrativa. auth_admin_keep O PolicyKit solicita uma senha administrativa e a guarda por alguns segundos. Listagem 3: Aplicar controles de acesso 01 <?xml version="1.0" encoding="UTF-8"?> 02 <!DOCTYPE policyconfig PUBLIC 03 "-/ /freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" 04 "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"> 05 <policyconfig> 06 07 <vendor>Linux New Media AG</vendor> 08 <vendor_url>http://www.linuxnewmedia.de</vendor_url> 09 10 <action id="de.linuxnewmedia.example.run-apt-get"> 11 <description>run apt-get</description> 12 <description xml:lang="en">run apt-get</description> 13 <message>Y ou need to authenticate to modify the system configuration</message> 14 <message xml:lang="en">You must identify yourself to run the program apt-get</message> 15 <defaults> 16 <allow_any>no</allow_any> 17 <allow_inactive>no</allow_inactive> 18 <allow_active>auth_self_keep</allow_active> 19 </defaults> 20 <annotate key="org.freedesktop.policykit.exec.path"> /usr/bin/apt-get</annotate> 21 </action> 22 23 </policyconfig> Listagem 4: Início sem uma senha 01 Release apt-get program for 02 Identity=unix-user:carlo 03 Action=de.linuxnewmedia.example.run-apt-get 04 ResultActive=yes 05 ResultInactive=no 06 ResultAny=no 71 | SEGURANÇAPolicyKit Linux Magazine #70 | Setembro de 2010 pplet.mechanism.policy é um bom exemplo. A janela para inserir a se- nha mostra o texto message, e <mes- sage xml:lang=”en”> oferece a versão em inglês. A sessão default define os privilégios padrão. O comando : <allow_active>auth_admin</allow_ active> diz ao pkexec que o programa não deve ser executado até que o usuário na sessão ativa (allow_active) tenha informado a senha administrativa (auth_admin). Mais tarde, é possível sobrescrever essas configurações individualmente com um arquivo .pkla localizado em /etc/polkit-1/ localauthority/50-local.d. Todos os valores da tabela 2 são permitidos entre as tags allow_acti- ve. A tag allow_inactive cuida das requisições de sessões inativas de modo semelhante (e corresponde a ResultInactive), enquanto que allow_any (como contrapartida a ResultAny) não se preocupa com a origem. Por fim, o caminho para o pro- grama é especificado em <annota- te key=”org.freedesktop.policykit. exec.path”>, que é o gerenciador de pacotes do aplicativo nesse exemplo. Apesar de ser necessário salvar a descrição da ação com uma extensão .policy, o próprio nome do arquivo não é importante; a convenção é seguir o ID da ação. Extras Agora, é preciso estabelecer uma regra especial (exceção) para o usuário carlo em /etc/polkit-1/ localauthority/50-local.d (lista- gem 4) para permitir que ele inicie o programa apt-get através do pke- xec sem inserir uma senha. Infeliz- mente, o pkexec não confere os pa- râmetros que o usuário passa junto com o programa. Neste exemplo, carlo poderia instalar um pacote arbitrário (malicioso). Conclusão O PolicyKit dá aos administradores uma ferramenta extremamente fle- xível para moldar perfis de acesso. Diferente do su e sudo, o PolicyKit não libera o usuário na totalidade do aplicativo; em vez disso, restrin- ge o usuário a funções individuais do sistema. Além disso, os usuários não precisam recorrer à linha de co- mando; no máximo, eles terão que fornecer uma senha. Em cenários mais complexos, as regras podem ficar um tanto confusas e o uso de um editor de texto para criá-las e mantê-las não é exatamente algo inconveniente. Além do mais, o PolicyKit é mais um sistema de gerenciamento de privilégios além do próprio sistema Linux. Mesmo que se use o PolicyKit para evitar que carlo execute um programa, ele ainda poderá fazer isso com sudo. Isso significa que é preciso ficar de olho nas suas configurações do PolicyKit e nos outros privilégios. Para que o PolicyKit funcione bem, os desenvolvedores precisam manter suporte explicitamente em seus apli- cativos; os sistemas de desktop preci- sam fornecer um diálogo de senha e as distribuições precisam ser mais consistentes no seu uso do PolicyKit. As últimas versões do openSUSE, do Fedora e o Ubuntu mostram que ain- da há muito a ser feito. n Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br Este artigo no nosso site: http://lnm.com.br/article/3850 Mais informações [1] PolicyKit: http://www.freedesktop.org/wiki/Software/PolicyKit Figura 4 Assumindo que os usuários possuem os privilégios necessários, eles podem instalar programas. Nesse caso, o usuário precisa fornecer apenas sua senha para executar apt-get com privilégios de root.