



Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Os melhores documentos à venda: Trabalhos de alunos formados
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Comunidade
Peça ajuda à comunidade e tire suas dúvidas relacionadas ao estudo
Descubra as melhores universidades em seu país de acordo com os usuários da Docsity
Guias grátis
Baixe gratuitamente nossos guias de estudo, métodos para diminuir a ansiedade, dicas de TCC preparadas pelos professores da Docsity
Linux Magazine #70 Setembro de 2010
Tipologia: Notas de estudo
1 / 6
Esta página não é visível na pré-visualização
Não perca as partes importantes!
66 http://www.linuxmagazine.com.br
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
or 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 Figura 1 No Gnome, o PolicyKit dá acesso às configurações de data e horário. hora e data para configurar o fuso
67 PolicyKit | SEGURANÇA 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: 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.
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
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
69 PolicyKit | SEGURANÇA Linux Magazine #70 | Setembro de 2010 sem problemas; auth_self pede que ele forneça sua senha de usuário e auth_self_keep faz o PolicyKit lembrar dessa senha por alguns segundos. Se carlo precisar ajustar o horário de novo durante esse período, não será preciso digitar sua senha de novo. Por fim, auth_admin pede que o u- suário forneça a senha administrati- va. Isso se aplica a qualquer usuário listado depois de AdminIdentities= no arquivo /etc/polkit-1/localauthori- ty.conf.d/60-myconfig.conf – nesse exemplo, adam e bonny. A tabela 2 mostra os outros valores suportados para ResultActive. Seguindo o mes- mo padrão, ResultInactive cuida das buscas originárias de sessões inativas; ResultAny não faz distinção entre ses- sões ativas e inativas. Com base nos padrões mostrados anteriormente, é possível adicionar mais sessões ao seu arquivo .pkla , ajustando assim suas atribuições de privilégios. Em um ambiente de pro- dução, regras para uma única ação serão normalmente agrupadas em um arquivo, que é, então, nomeado para uma ação. As alterações do usuário carlo estariam salvas então em org. gnome.clockapplet.mechanism.pkla. Tudo ou nada O PolicyKit aplica regras imediata- mente, sem necessidade de reinicia- lização. No Ubuntu, no entanto, as alterações não modificam a capacida- de do usuário de acertar o relógio: a Canonical parece ter redirecionado as configurações do sistema fazendo com que um clique no ícone do ca- deado busque por org.freedesktop. systemtoolsbackends.set. Para que o usuário bonny possa acertar o reló- gio, é preciso modificar a linha 3 da listagem 1 dessa maneira: Action=org.freedesktop. systemtoolsbackends.set Como o nome da ação sugere, isso daria a bonny o acesso a todas as outras configurações do sistema. Ela não só poderia alterar o horário, mas também poderia mexer com o gerenciamento de usuários. No Ubun- tu, seria então mais fácil adicionar bonny ao grupo de administradores. Plataforma de lançamento Com o PolicyKit, é possível deixar usuários comuns iniciarem progra- mas do sistema. Para permitir que isso aconteça, o pkexec substitui o conhe- cido sudo. Por exemplo, o comando $ pkexec --user bonny /usr/bin/ apt-get inicia o gerenciador de pacotes no contexto da conta do usuário bonny ( quadro 1 ). O aplicativo é executado em um ambiente mínimo e seguro. Isso torna impossível a injeção de có- digo malicioso, mas também impos- sibilita a inicialização de programas X11 com a conta de outro usuário. Por padrão, apenas administrado- res – quer dizer, os usuários listados no arquivo de configuração /etc/ polkit-1/localauthority.conf.d/60- myconfig.conf – têm permissão de usar pkexec para iniciar um progra- ma. Para permitir que o usuário sem privilégios carlo inicie programas, basta criar uma nova regra. A ação para isso é org.freedesktop.policykit. exec ( listagem 2 ). O código da listagem 2 permitiria que carlo iniciasse qualquer progra- ma através do pkexec. Se é necessário permitir que carlo execute apt-get apenas após fornecer sua senha, outro arquivo de configuração pre- cisa ser feito. Figura 2 O cliente primeiramente habilita um serviço do sistema. O serviço então utiliza o D-Bus para solicitar permissão ao PolicyKit e este pede uma senha de usuário. Figura 3 O prompt da senha de autenticação do Gnome revela a ação do usuário.
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
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.
01 02 05
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