Segurança no mundo Apple: arquitetura de autenticação (AuthPlugin)

Plugin de autorização

Atrasamos o artigo de ontem, mas até o final da semana colocamos todos em dia. 😉

A implementação BSD do kernel do OS X oferece um modelo de segurança baseado em usuários e proprietários. Cada objeto do sistema de arquivos, como um arquivo ou diretório, possui um proprietário e um conjunto de permissões ou atributos, especificando o que um proprietário, um grupo e todos os outros são capazes de fazer com aquele objeto. Este modelo de permissionamento é comum no mundo Unix e abrange o conceito de autorização.

No OS X, esse modelo é expandido criando um sistema baseado em políticas que são utilizadas em conjunto com as permissões BSD. Para o bom entendimento deste artigo, recomendo a leitura dos anteriores: infraestrutura Unix, framework de segurança, controle de acesso obrigatório, sandboxing e autenticação/autorização.

Embora muito intuitivo e funcional, existem casos nos quais o modelo de segurança BSD não se encaixa em situações enfrentadas por usuários do OS X. Nestes, o modelo de segurança baseado em políticas, usado em conjunto com as permissões BSD, fornecem importantes recursos adicionais para um aplicativo (nativo ou de terceiros) — por exemplo, proteger o usuário comum de uma modificação crítica acidental no sistema, mesmo em casos nos quais o modelo de segurança BSD permita.

Ao modificar as configurações de rede do painel Network ou ao copiar um aplicativo para a pasta /Applications/, o sistema exige que o usuário se autentique como administrador para fazer alterações. Serviços de autorização também podem ser utilizados para executar operações como super-usuário (root), como reiniciar um daemon. Elevações de privilégio podem ocorrer apenas nos casos em que os aplicativos não estejam sendo executados em sandboxing, pois o ambiente é restrito e controlado.

Plugin de autorização

Em resumo, um usuário ou serviço requisita uma autorização e, após a autenticação e verificação, é concedido o direito para executar uma ação privilegiada. Na prática, um aplicativo nativo ou de terceiros faz uma requisição de autorização ao daemon Security Server, que por sua vez verifica os direitos no arquivo /etc/authorization para determinar os mecanismos a serem utilizados na autenticação. Se necessário (em casos nos quais o requisitante não tenha um ticket kerberos), o Security Server requisita uma iteração do usuário através do Security Agent, que em seguida solicita ao usuário que se autentica através do uso de uma senha, certificado digital, ou leitor biométrico, retornando a informação de autenticação de volta para o Security Server, o qual repassa para a aplicação.

No diretório /System/Library/CoreServices/SecurtiyAgentPlugins/ existem plugins do OS X (e de terceiros, caso instalados) chamados AuthPlugins, os quais são utilizados para controlar o acesso a um serviço ou aplicativo. Esses plugins (e suas regras associadas e os privilégios de autorização para usuários) são definidos no arquivo /etc/authorization, que por sua vez são consultados pelo Security Server.

Este modelo é interessante pois facilita a implementação de um método seguro de autenticação e autorização integrado ao sistema operacional. O desenvolvedor não precisa se preocupar qual vai ser o método de autenticação (ticket, senha, certificado, leitor biométrico…). Aqui, você pode encontrar um exemplo de como implementar um plugin AuthPlugin e como definir políticas que serão consultadas no arquivo /etc/authorization.

Posts relacionados

Comentários