Docsity
Docsity

Prepare-se para as provas
Prepare-se para as provas

Estude fácil! Tem muito documento disponível na Docsity


Ganhe pontos para baixar
Ganhe pontos para baixar

Ganhe pontos ajudando outros esrudantes ou compre um plano Premium


Guias e Dicas
Guias e Dicas

Privilegios Administrativos, Notas de estudo de Informática

Linux Magazine #70 Setembro de 2010

Tipologia: Notas de estudo

2011

Compartilhado em 10/03/2011

william-felipe-dutra-abreu-da-silva
william-felipe-dutra-abreu-da-silva 🇧🇷

21 documentos

1 / 6

Toggle sidebar

Esta página não é visível na pré-visualização

Não perca as partes importantes!

bg1
66 http://www.linuxmagazine.com.br
SEGURANÇ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
P
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
hora e data para configurar o fuso
Figura 1 No Gnome, o PolicyKit dá acesso às configurações de data e horário.
pf3
pf4
pf5

Pré-visualização parcial do texto

Baixe Privilegios Administrativos e outras Notas de estudo em PDF para Informática, somente na Docsity!

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

SEGURANÇ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

P

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.

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

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 e 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 e </des- cription>. A instrução é 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 02 05 06 07 Linux New Media AG 08 <vendor_url>http://www.linuxnewmedia.de</vendor_url> 09 10 11 run apt-get 12 run apt-get 13 Y ou need to authenticate to modify the system configuration 14 You must identify yourself to run the program apt-get 15 16 <allow_any>no</allow_any> 17 <allow_inactive>no</allow_inactive> 18 <allow_active>auth_self_keep</allow_active> 19 20 /usr/bin/apt-get 21 22 23

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