Licença para gerenciar

Transcrição

1 SEGURANÇA Sudo e PolicyKit SEGURANÇA Sudo e PolicyKit Licença para gerenciar Se oferecermos a usuários supervisionados mais espaço para ajudarem a si mesmos, eles precisarão de privilégios adicionais. A ferramenta sudo e o serviço de autorização PolicyKit podem controlar quem faz o que no Linux. por Tim Schürmann Para os administradores, seria um alívio se os usuários regulares fossem capazes de lidar com tarefas menores de gerenciamento, tais como atualização de software. O único problema é que o apt-get requer privilégios administrativos e o leitor possivelmente não iria desejar concedê-los a um usuário leigo. Felizmente, os administradores podem contar com o sudo ou com o serviço de autorização PolicyKit para permitir ações específicas de forma orientada. Sudo As ferramentas sudo executam comandos com uma conta de usuário diferente. Para o apt-get upgrade, este seria um usuário todo-poderoso. Quais usuários possuem permissão para usar o sudo e com quais programas está definido no arquivo de configuração /etc/sudoers. Por exemplo, para permitir que o usuário klaus atualize seu próprio computador chamado marvin, devemos adicionar a seguinte linha ao arquivo /etc/sudoers : klaus marvin=(all) NOPASSWD: /usr/bin/apt-get upgrade A linha começa com o nome do u- suário e é seguida pelo host onde klaus tem permissão para executar o comando. Neste caso, ele deve trabalhar em seu próprio computador, marvin. Se klaus visualizar a mensagem de erro klaus is not allowed to run sudo on... ao executar o apt-get upgrade, isto provavelmente tem algo a ver com a resolução de nomes. O administrador deve verificar se os hostnames especificados batem com a saída do comando hostname e fazer uma verificação cruzada com o conteúdo do arquivo /etc/hosts. Especificar ALL ao invés do hostname, significa que klaus pode executar o apt-get upgrade em qualquer máquina. Como uma alternativa para o hostname, podemos também especificar o endereço IP. Para um intervalo de endereço, basta definir a subrede: klaus / = (ALL)NOPASSWD:/usr/bin/ apt-get upgrade Neste caso, o usuário klaus só pode executar o comando se trabalhar em uma máquina com um endereço IP no intervalo de a O sudo executa um comando em uma conta de usuário diferente. Os detalhes dos parênteses especificam quais contas klaus pode escolher. Especificar tim significaria que klaus só poderia iniciar o programa como usuário tim. ALL permite que klaus escolha qualquer conta de usuário, incluindo o usuário root necessário para o apt-get : sudo -u root apt-get upgrade Figura 1 No Linux Mint, a chamada para visudo só protege o arquivo sudoers contra um acesso mais detalhado e, então, chama o nano. A opção -u para o usuário desejado é opcional no caso do root. Antes do sudo executar o comando apt-get upgrade, klaus normalmente precisa 60

2 Sudo e PolicyKit SEGURANÇA digitar sua senha. Isto não é necessário se colocarmos NOPASSWD: na frente do nome do programa no arquivo de configuração. O comando a ser executado vem no final da linha. Se quisermos deixar klaus executar vários programas ou comandos, basta acrescentarmos uma lista separada por vírgulas: klaus marvin=(all)nopasswd:/usr/ bin/apt-get update,/usr/bin/ apt-get upgrade Neste caso, klaus pode atualizar o banco de dados de pacotes e instalar atualizações, mas não pode instalar novos programas. O ALL universal pode ser também usado para outros parâmetros. A linha a seguir torna klaus equivalente ao usuário root : klaus ALL=(ALL) ALL Como uma alternativa para usuários individuais, o arquivo sudoers também pode conceder acesso a todos os membros de um grupo, como admin: %admin ALL=(ALL) ALL o sudo guarda a senha introduzida. A linha a seguir também é útil: Defaults timestamp_timeout=15 Ela declara que o sudo deve esquecer a senha para todos os usuários após 15 segundos. Se a definirmos para 0, os usuários precisarão digitar suas senhas cada vez que executarem o sudo. Para os outros padrões, veja a página man ( man 5 sudoers ). Dentro de /etc/sudoers, um ponto de exclamação nega uma definição. Isto permite que o administrador previna klaus de executar um programa específico. Para fazer isso, basta adicionar um ponto de exclamação na frente do nome do programa. No exemplo a seguir, klaus não tem permissão para reinicializar o computador: klaus marvin=(all)!/sbin/reboot Todas as chamadas sudo fracassadas geralmente acabam no arquivo syslog, enquanto o Ubuntu usa o arquivo /var/log/auth.log. Desta forma, podemos descobrir qual u- suário sofreu interferência. Dança perigosa O sudo é perigoso em vários aspectos. Por exemplo, apenas um pequeno erro de digitação ou uma exclamação fora de lugar podem bloquear completamente o sistema. Note que isso pode acontecer com regras que podemos esperar que não possuam tal efeito. Portanto, os administradores só devem editar o arquivo /etc/sudoers com a ferramenta visudo criada expressamente para este fim. Entre outras coisas, este editor verifica a sintaxe do arquivo de configuração. Contrariamente ao que o vi no nome implica, o editor subjacente em algumas distribuições hoje é o nano (figuras 1 e 2 ). No Ubuntu, a ferramenta deixar passar erros de digitação óbvios em nosso laboratório, por isso não devemos confiar demais nela. Em muitas distribuições Linux, é prática padrão alterar as regras escritas em um arquivo de configuração O sinal de porcentagem declara ao sudo que este é um grupo e não um usuário individual, que é como o Ubuntu concede acesso aos recursos do sistema a todos os administradores. A listagem 1 mostra o arquivo de configuração sudoers para o Ubuntu; deixamos de fora os comentários para facilitar a leitura: root, os usuários do grupo admin e sudo podem fazer tudo, e os demais usuários não podem fazer nada. O segundo ALL entre parênteses indica o nome do grupo com permissão de acesso; assim, klaus pode executar o comando como qualquer usuário de qualquer grupo. Cada linha que começa com Defaults altera uma configuração padrão no sudo. Na listagem 1, env_reset redefine as variáveis de ambiente, e secure_path define a variável PATH (ou seja, os diretórios onde o Linux pode encontrar os programas a serem executados). Ambas as medidas são projetadas para tornar ataques mais difíceis. Normalmente, Figura 2 O OpenSUSE usa o famoso vi, que suporta syntax highlighting ainda que seja um pouco exagerada. Linux Magazine #98 Janeiro de

3 SEGURANÇA Sudo e PolicyKit separado e armazená-las no diretório /etc/sudoers.d. A linha : #includedir /etc/sudoers.d em /etc/sudoers garante que o sudo leia automaticamente e avalie todos os arquivos de texto no diretório /etc/ sudoers.d. O # do início da linha não introduz um comentário; é parte do comando. Com a terceirização, um administrador pode simplesmente excluir os arquivos de configuração adicionais para retornar o antigo estado, no caso de um erro. No entanto, a cautela também é aconselhada com estas regras adicionais. Se klaus no exemplo a seguir também for membro do grupo admin, ele pode executar qualquer ferramenta do sistema não apenas /sbin/reboot : klaus marvin=(all) NOPASSWD:/sbin/reboot %admin ALL=(ALL) ALL Em um ambiente de produção, as dependências para quais regras estão sujeitas nem sempre são tão evidentes. Como mitigar o risco Para acessar as ferramentas do sistema, o sudo utiliza o bit setuid. O comando, portanto, sempre executa com privilégios de root. Apenas o próprio sudo impede um usuário comum de executar comandos de forma arbitrária no sistema. Para descobrir quais direitos são concedidos ao sudo, podemos simplesmente digitar sudo -l. Executar o comando sem uma senha, especificando NOPASSWD, é conveniente para os usuários. No entanto, a prática também é arriscada, pois um usuário poderia executar comandos sem pensar que comprometeriam o sistema, e um malware poderia iniciar ferramentas de sistema em segundo plano, sem que o administrador percebesse. Finalmente, devemos sempre especificar o caminho completo para os programas; caso contrário, o sudo deixaria de executar o apt-get original, mas executaria um programa malicioso com o mesmo nome que tenha sido injetado no caminho de pesquisa. Serviço de autorização PolicyKit O PolicyKit habilmente trilha seu caminho em torno de problemas de permissão e riscos de segurança [1] com uma abordagem completamente diferente: se o usuário klaus deseja instalar um pacote, o gerenciador de pacotes primeiro pergunta ao PolicyKit se esta é uma ação permitida. O PolicyKit pode então imediatamente oferecer o sinal verde para que klaus siga em frente ou então solicita Diretório: Objetivo: 10-vendor.d / Regulamentação de fornecedor 20-org.d Regras por parte da organização que faz a distribuição 30-org.d Regras por parte do site que faz a distribuição 50-local.d Regras próprias ou locais 90-mandatory.d Regras por parte da organização que faz a distribuição Tabela 1 Diretórios para regras PolicyKit. Figura 3 Um agente de autenticação no Ubuntu. Ao expandir a janela de detalhes, a tela mostra a ação para a qual o programa solicita autorização. uma senha. Em contraste com o sudo, o PolicyKit regula recursos (de sistema) individuais. Assim, o administrador pode permitir que klaus atualize pacotes e permita a instalação de novos pacotes. O PolicyKit passou por uma mudança de conceito durante seu desenvolvimento. A versão atual é normalmente referida como PolicyKit-1, ou, abreviadamente, polkit. De forma um tanto confusa, não chegou a se tornar versão 1; a versão mais recente quando do fechamento desta edição era a Apesar do zero na frente do ponto, o sistema PolicyKit é estável em distribuições como Ubuntu, Fedora e opensuse e tem sido assim há anos. A essência do PolicyKit é o serviço polkitd. Como ele só precisa responder a solicitações de ferramentas Quadro 1: Programa de ação Policykit Ferramentas do sistema primeiro precisam registrar as ações suportadas com PolicyKit, para que cada programa armazene um arquivo XML no subdiretório /usr/ share/polkit-1/actions para esta fi nalidade. Por exemplo, os serviços oferecidos pelo Network Manager estão localizados no arquivo org.freedesktop.networkmanager. policy. Uma ação ligeiramente reduzida é mostrada na listagem 3. O id= na linha 1 é seguido pela mensagem D-Bus enviada pelo programa; o <description> na linha 2 fornece uma breve descrição da ação, e <mensagem> é a mensagem que o usuário visualiza na tela de senha. Para cada ação, o desenvolvedor do programa pode defi nir permissões padrão dentro do elemento <defaults> (linhas 4 a 7). No exemplo acima, apenas os administradores são autorizados a modifi car a confi guração da rede. Os detalhes e valores possíveis aqui correspondem aos dos arquivos.pkla. Nunca devemos modifi car os arquivos.policy diretamente: por um lado, isso poderia causar uma vulnerabilidade; de outro, a distribuição poderia sobrescrever suas alterações durante a atualização do sistema. É melhor, portanto, usar seu próprio arquivo.pkla. 62

4 Sudo e PolicyKit SEGURANÇA do sistema, é executado em uma conta restrita. Portanto, ninguém pode usá-lo para roubar o sistema. O polkitd fornece seus recursos através do sistema de comunicação D-Bus. Como alternativa, os programas podem usar também a biblioteca libpol-kit-gobject-1, que encapsula as chamadas D-Bus correspondentes. Um componente LocalAuthority verifica se a ação solicitada pelo PolicyKit é permitida. Como o nome indica, sua decisão leva em conta as contas de usuários e grupos que existem localmente no computador. Se uma entrada de senha é necessária, o PolicyKit chama um agente de autenticação. Este agente consiste basicamente de uma máscara Quadro 2: Como executar O PolicyKit inclui a ferramenta de linha de comando pkexec, que inicializa um programa em outra conta de usuário e, portanto, substitui o sudo pelo menos, esta é a ideia básica. O comando: pkexec --user klaus apt-get update por exemplo, executaria o comando apt-get update como usuário klaus. Infelizmente, apenas administradores podem executar o pkexec, por razões de segurança. Além disso, o pkexec inicializa o comando apt-get update no contexto de autorização do usuário klaus. No entanto, por padrão, este usuário não possui permissão para executar o apt-get update, e não podemos conceder-lhe estes direitos pois o apt-get simplesmente ignora o PolicyKit e só segue as permissões-padrão do Unix. As ações conhecidas no PolicyKit, org.debian.apt.update-cache, referem-se ao aptdaemon [2]. Em outras palavras, se quisermos permitir que klaus execute o apt-get, precisamos utilizar o sudo com as regras correspondentes ou adicionar klaus ao grupo de administrador, e só então klaus poderia iniciar o apt-get como usuário root. Obviamente, muito pouco se ganha com isso; mas, pelo menos, o pkexec encaixota o programa em um ambiente mínimo e endurecido, impedindo ataques contra a variável de ambiente LD_LIBRARY_PATH. de entrada ( figura 3 ). Cada ambiente de trabalho pode fornecer seu próprio agente de autenticação. Regulador Para conceder ao usuário o acesso a um recurso do sistema, o administrador precisa criar uma regra correspondente. Todas as regras PolicyKit estão reunidas no diretório /etc/polkit-1/local-authority. Aqui também encontraremos cinco subdiretórios nos quais as regras são distribuídas, dependendo de suas origens. A tabela 1 mostra quem precisa dispor de quais regras e em quais diretórios. Os administradores podem se concentrar no diretório 50 local.d. O LocalAuthority lê todos os arquivos armazenados lá com um sufixo.pkla em ordem alfabética crescente. Classificação ordenada Para permanecermos no caminho quando escrevemos as regras, devemos sempre começar o nome do arquivo com um número em ordem crescente. Os arquivos de regras são arquivos de texto simples, e podemos agrupar várias regras em um arquivo. Note que os arquivos.pkla precisam de nomes únicos. O PolicyKit se refere às regras de acesso como entradas de autorização. A listagem 2 mostra uma regra que permite que o usuário klaus altere as Listagem 1: Arquivo Ubuntu /etc/ sudoers 01 # Redefine environmental variables: 02 Defaults env_reset 03 Defaults secure_path="/usr/ local/sbin:/usr/local/bin:/ usr/sbin:/usr/bin:/sbin:/bin" # Permit access: 06 root ALL=(ALL:ALL) ALL 07 %admin ALL=(ALL) ALL 08 %sudo ALL=(ALL:ALL) ALL # Add more rules here: 11 #includedir /etc/sudoers.d configurações globais de rede no Network Manager. Um comentário nos colchetes introduz a regra. Identity= mostra quais usuários ou grupos de usuários são afetados pela regra. Na linha 2, encontra-se alguém com uma conta de usuário local ( unix-user: ) e o nome de usuário klaus. Vários usuários ou grupos são separados no arquivo por ponto-e-vírgula. A linha : Identity=unix-user:klaus; unix-group:networkers permitiria que o grupo inteiro de usuários, e não apenas klaus, modificasse as configurações de rede. A linha Action= na listagem 2 é acompanhada pelo nome da ação permitida. O comando pkaction revela quais ações são conhecidas pelo PolicyKit. Cuidado; a saída da lista por este comando pode ser longa, dependendo da distribuição ( figura 4 ). Normalmente, o nome da ação diz o que ela faz. Se quiser saber exatamente o que acontece, execute pkaction com o nome da ação ( figura 5 ): pkaction --verbose--action-id org.freedesktop.networkmanager. settings.modify.system Faz sentido redirecionar a lista completa e detalhada em um arquivo, por exemplo: pkaction --verbose > actions.txt As ações disponíveis dependem da distribuição e os programas instalados ( quadro 1 ). Várias ações podem ser combinadas em uma única regra com o curinga *. A linha : Identity=org.freedesktop. NetworkManager.* Listagem 2: Regras para o LocalAuthority 01 Klaus is allowed to modify network 02 Identity=unix-user:klaus 03 Action=org.freedesktop. NetworkManager.settings. modify.system 04 ResultInactive=no 05 ResultActive=auth_self Linux Magazine #98 Janeiro de

5 SEGURANÇA Sudo e PolicyKit deixaria klaus executar todos os recursos oferecidos pelo Network Manager. Quem sou eu? O PolicyKit distingue entre pedidos que vêm de uma sessão ativa e aqueles que se originam de uma sessão inativa. O que fazer com as solicitações da sessão ativa é definido por ResultActive=. Na listagem 2, klaus precisa, então, digitar sua própria senha ( auth_self ). No caso de uma sessão inativa, as regras seguem a aplicação do ResultInactive=. A linha 4 contém um no, que proíbe a alteração das configurações de rede no Network Manager. Além de auth_self e no, a tabela 2 resume alguns outros valores possíveis. Como uma alternativa para ResultInactive e ResultActive, podemos especificar ResultAny, que é o mesmo para as sessões ativas e inativas. Apenas uma destas três precisam figurar no arquivo.pkla ; as regras especificadas pela ação correspondente em seguida se aplicarão para qualquer coisa que esteja faltando ( quadro 2 ). Se fôssemos salvar a listagem 2 como 51-org.freedesktop.NetworkManager.pkla no diretório /etc/polkit-1/ localauthority/50local.d, o PolicyKit automaticamente aplicaria as novas regras sem ter que reiniciar o serviço. Para mais exemplos de regras, confira o subdiretório var/lib/polkit-1/localauthority/, que só é acessível para o usuário root. Este diretório armazena todas as regras que vieram com a distribuição. Para mais detalhes sobre a estrutura dos arquivos.pkla, veja a página man da ferramenta ( man pklocalauthority ). Onipotente Alguns recursos do sistema são tão perigosos ou críticos que apenas um administrador de verdade está autorizado a executá-los; assim, o LocalAuthority distingue-se entre usuários regulares e administradores, que possuem o mesmo privilégio de root. Os membros do grupo de elite de administradores são definidos pelos arquivos de configuração em /etc/ polkit-1/localauthority.conf.d. Mais uma vez, o LocalAuthority analisa todos os arquivos em ordem alfabética; configurações em arquivos posteriores sobscrescrevem os arquivos anteriores. O administrador do sistema não deve alterar os arquivos existentes, mas adicionar um arquivo próprio, com um número maior, o que também significa que a distribuição não substituiria o arquivo durante uma atualização de sistema. Por padrão, um arquivo de configuração compreende apenas duas linhas; por exemplo, no Ubuntu: [Configuration] AdminIdentities= unix-group:sudo;unix-group:admin O AdminIdentities= é seguido por todos os usuários e grupos que possuem os mesmos privilégios de root do ponto de vista do PolicyKit. Para adicionar klaus à este grupo de elite no Ubuntu, o usuário administrativo deve criar um novo arquivo chamado 99-Klaus.conf e adicionar: [Configuration] AdminIdentities=unix-group: sudo;unix-group:admin; unix-user:klaus Figura 4 O pkaction revela os nomes de todas as ações suportadas pelo PolicyKit e dependem da distribuição utilizada. Os dois grupos, sudo e admin, vêm de arquivos de configuração existen- 64

6 Sudo e PolicyKit SEGURANÇA tes, por isso é necessário adicioná-los; caso contrário, apenas klaus terá privilégios de root. Mais informações [1] PolicyKit: freedesktop.org/wiki/ Software/polkit [2] Aptdaemon: launchpad.net/aptdaemon Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.brne.com Este artigo no nosso site: Pouco suporte O PolicyKit oferece uma camada adicional de segurança no topo do sistema de autorização Unix existente, mas não a substitui. Além disso, os programas do sistema envolvidos devem suportar o PolicyKit ou solicitar o serviço. Atualmente, apenas algumas ferramentas de interface gráfica de usuário selecionadas fazem isso, como é o caso do Network Manager. Todos os aplicativos de console, incluindo o apt-get, ignoram o PolicyKit. Os problemas que essa confusão pode causar são apresentados no quadro 2. No entanto, mesmo se um aplicativo suportar o PolicyKit, não precisará respeitar suas instruções; assim, um invasor poderá facilmente contornar o PolicyKit com código malicioso. Conclusão Tanto o sudo como o PolicyKit têm suas vantagens e desvantagens. Se quisermos permitir uma ação que o PolicyKit possua em seu repertório, devemos criar um arquivo.pkla correspondente, o que significa que estamos permitindo apenas os recursos necessários. Os administradores não devem permitir que usuários regulares utilizem o sudo, a menos que considere cuidadosamente as consequências, ou em caso de uma emergência: o risco é muito grande de que uma regra incorreta permita aos usuários fazer mais do que o administrador deseja, ou até mesmo o bloqueie do próprio sistema. Valor: no yes auth_self auth_admin auth_self_keep auth_admin_keep Significado: O Linux ainda carece de um sistema de permissões granulares. Para os casos em que os administradores desejam permitir o acesso a programas de linha de comando, é uma boa ideia olhar para técnicas alternativas, tais como listas de controle de acesso ( Access Control Lists - ACLs) [2]. O usuário não deve executar a ação sob quaisquer circunstâncias. O usuário pode executar a ação sem autenticação. O usuário só pode executar a ação depois de digitar sua senha. O usuário deve se autenticar como administrador (e, portanto, saber a senha administrativa). Como auth_self, mas o PolicyKit mantém a senha digitada por alguns minutos. O usuário pode, portanto, executar a ação várias vezes em sucessão, mas só precisa digitar sua senha uma vez. Como o auth_admin, mas neste caso o PolicyKit mantém a senha digitada por alguns minutos. O usuário pode, portanto, executar a ação várias vezes sucessivamente, mas só precisa se autenticar como administrador uma única vez. Tabela 2 Tipos de autorização do PolicyKit. Figura 5 Aqui, o pkaction revela que a ação org.freedesktop. Network Manager.settings.modify.system permite que todos os usuários modifi quem as defi nições de rede com o Network Manager. Na última saída do comando estão as permissões padrão. Listagem 3: Arquivo Action (reduzido) 01 <action id="org.freedesktop.networkmanager.settings. modify.system"> 02 <description xml:lang="en">modify network connections for all users</description> 03 <message xml:lang="en">system policies prevent you from modifying networksettings for all users</message> 04 <defaults> 05 <allow_inactive>no</allow_inactive> 06 <allow_active>auth_admin_keep</allow_active> 07 </defaults> 08 </action> Linux Magazine #98 Janeiro de