Módulos de Autenticação Plugáveis

A terminologia em torno do PAM é bastante confusa. Nem o artigo original de Neither Samar e Lai nem a especificação original do XSSO fizeram algum esforço para definir formalmente os termos de vários atores e entidades envolvidas no PAM, e os termos que eles usam (mas não definem) são algumas vezes duvidosos ou ambíguos. A primeira tentativa de estabelecer uma terminologia consistente e não ambígua foi feita no artigo escrito por Andrew G. Morgan (autor do Linux-PAM) em 1999. A escolha da terminologia de Morgan foi um grande avanço, mas na opinião deste autor, não é perfeita. O que segue é uma tentativa, fortemente inspirada por Morgan, de definir termos precisos e não ambíguos para todos os atores e entidades envolvidas no PAM.

Esta seção tem como objetivo ilustrar os significados de alguns dos termos definidos acima por meio de alguns exemplos simples.

Este exemplo simples mostra alice usando su(1) para se tornar root.

O exemplo abaixo mostra eve tentar iniciar uma conexão ssh(1) com login.example.com, solicitar para efetuar login como bob e ter exito. Bob deveria ter escolhido uma senha melhor!

A seguir, a política padrão do FreeBSD para sshd:

A API do PAM oferece seis primitivas de autenticação diferentes agrupadas em quatro recursos, descritos abaixo.

Módulos são um conceito muito central no PAM; afinal, eles são os "M" no "PAM". Um módulo PAM é um código de programa autocontido que implementa as primitivas em uma ou mais instalações para um mecanismo específico; possíveis mecanismos para o recurso de autenticação, por exemplo, incluem os bancos de dados de senhas UNIX®, NIS, LDAP e Radius.

O FreeBSD implementa cada mecanismo em um único módulo, chamado pam_mechanism.so (por exemplo, pam_unix.so para o mecanismo UNIX®. Outras implementações às vezes possuem módulos separados para instalações separadas e incluem o nome do recurso, bem como o nome do mecanismo no nome do módulo. Para citar um exemplo, Solaris™ tem um módulo pam_dial_auth.so.1 que é comumente usado para autenticar usuários de conexões discadas.

A implementação original do PAM no FreeBSD, baseada no Linux-PAM, não utilizou números de versão para os módulos PAM. Isso normalmente causaria problemas com aplicativos legados, que poderiam estar vinculados a versões mais antigas das bibliotecas do sistema, pois não havia como carregar uma versão correspondente dos módulos necessários.

O OpenPAM, por outro lado, procura por módulos que possuam o mesmo número de versão que a biblioteca PAM (atualmente 2), e só retorna a um módulo não versionado se nenhum módulo versionado puder ser carregado. Assim, os módulos legados podem ser fornecidos para aplicativos legados, permitindo que novos aplicativos (ou recém-construídos) aproveitem os módulos mais recentes.

Embora os módulos PAM do Solaris™ normalmente tenham um número de versão, eles não são realmente versionados, porque o número é uma parte do nome do módulo e deve ser incluído na configuração.

Quando um servidor inicia uma transação PAM, a biblioteca PAM tenta carregar uma política para o serviço especificado na chamada pam_start(3). A política especifica como as solicitações de autenticação devem ser processadas e definidas em um arquivo de configuração. Este é o outro conceito central no PAM: a possibilidade de o administrador ajustar a política de segurança do sistema (no sentido mais amplo da palavra) simplesmente editando um arquivo de texto.

Uma política consiste em quatro cadeias, uma para cada uma dos quatro recursos do PAM. Cada chain é uma sequência de instruções de configuração, cada uma especificando um módulo para invocar, alguns parâmetros (opcionais) para passar para o módulo e um sinalizador de controle que descreve como interpretar o código de retorno do módulo.

Entender os sinalizadores de controle é essencial para entender os arquivos de configuração do PAM. Existem quatro diferentes flags de controle:

Quando um servidor invoca uma das seis primitivas PAM, o PAM recupera a chain para o recurso ao qual a primitiva pertence, e invoca cada um dos módulos listados na chain, na ordem em que estão listados, até chegar ao fim ou determina que nenhum processamento adicional é necessário (porque um módulo binding ou sufficient teve exito, ou porque um módulo requisite falhou.) O pedido é concedido se e somente se pelo menos um módulo foi chamado e todos os módulos não opcionais tiveram exito.

Note que é possível, embora não muito comum, ter o mesmo módulo listado várias vezes na mesma chain. Por exemplo, um módulo que procura nomes de usuário e senhas em um servidor de diretório pode ser chamado várias vezes com parâmetros diferentes, especificando diferentes servidores de diretórios para contato. O PAM trata diferentes ocorrências do mesmo módulo na mesma chain de módulos diferentes e não relacionados.

O ciclo de vida de uma transação típica do PAM é descrito abaixo. Observe que, se qualquer uma dessas etapas falhar, o servidor deverá informar uma mensagem de erro adequada ao cliente e anular a transação.

O arquivo de política tradicional do PAM é /etc/pam.conf. Este arquivo contém todas as políticas do PAM para o seu sistema. Cada linha do arquivo descreve uma etapa em uma chain, conforme mostrado abaixo:

Os campos estão, na ordem: nome do serviço, nome do recurso, flag de controle, nome do módulo e argumentos do módulo. Quaisquer campos adicionais são interpretados como argumentos adicionais do módulo.

Uma chain separada é construída para cada par de serviço/recurso, portanto, embora a ordem na qual as linhas para o mesmo serviço e recurso apareçam seja significativa, a ordem na qual os serviços e recursos individuais são listados não é. Os exemplos no artigo original do PAM agruparam as linhas de configuração por recurso, e o suporte do Solaris™ ao pam.conf ainda faz isso, mas a configuração de ações do FreeBSD configura as linhas por serviço. De qualquer maneira está bem; De qualquer forma, faz o mesmo sentido.

O OpenPAM e o Linux-PAM suportam um mecanismo de configuração alternativo, que é o mecanismo preferido no FreeBSD. Neste esquema, cada política está contida em um arquivo separado com o nome do serviço ao qual se aplica. Esses arquivos são armazenados em /etc/pam.d/.

Esses arquivos de políticas por serviço possuem apenas quatro campos, em vez de cinco no pam.conf: o campo nome do serviço é omitido. Assim, em vez da linha de exemplo no pam.conf da seção anterior, a seguinte linha deve estar em /etc/pam.d/login:

Como consequência dessa sintaxe simplificada, é possível usar a mesma política para vários serviços vinculando cada nome de serviço a um mesmo arquivo de política. Por exemplo, para usar a mesma política para os serviços su e sudo, pode-se fazer o seguinte:

Isso funciona porque o nome do serviço é determinado a partir do nome do arquivo em vez de ser especificado no arquivo de políticas, portanto, o mesmo arquivo pode ser usado para vários serviços com nomes diferentes.

Como a política de cada serviço é armazenada em um arquivo separado, o mecanismo pam.d também facilita a instalação de políticas adicionais para pacotes de software de terceiros.

Como vimos acima, as políticas do PAM podem ser encontradas em vários lugares. O que acontece se as políticas para o mesmo serviço existirem em vários lugares?

É essencial entender que o sistema de configuração do PAM está centrado em chains.

Como explicado em Arquivos de política do PAM, cada linha em /etc/pam.conf consiste em quatro ou mais campos: o nome do serviço, o nome do recurso, a flag de controle, o nome do módulo e nenhum ou mais argumentos do módulo.

O nome do serviço é geralmente (embora nem sempre) o nome do aplicativo ao qual a instrução se aplica. Se não tiver certeza, consulte a documentação do aplicativo individual para determinar qual nome de serviço ele usa.

Note que se você usar /etc/pam.d/ em vez de /etc/pam.conf, o nome do serviço é especificado pelo nome do arquivo de política e omitido a partir das linhas de configuração atuais, que então começam com o nome da instalação.

O recurso é uma das quatro palavras-chave do recurso descritas em Recursos e Primitivas.

Da mesma forma, a flag de controle é uma das quatro palavras-chave descritas em Cadeias e Políticas, descrevendo como interpretar o código de retorno do módulo. O Linux-PAM suporta uma sintaxe alternativa que permite especificar a ação para associar com cada código de retorno possível, mas isso deve ser evitado, pois não é padrão e está intimamente ligado à forma como o Linux-PAM envia chamadas de serviço (que difere muito da maneira que Solaris™ e OpenPAM fazem isso). Não surpreendentemente, o OpenPAM não suporta esta sintaxe.

Para configurar o PAM corretamente, é essencial entender como as políticas são interpretadas.

Quando um aplicativo chama pam_start(3), a biblioteca PAM carrega a diretiva do serviço especificado e constrói quatro chains de módulos (uma para cada recurso). Se uma ou mais dessas chains estiverem vazias, as chains correspondentes da política para o outro serviço são substituídas.

Quando o aplicativo chama mais tarde uma das seis primitivas PAM, a biblioteca PAM recupera a chain para o recurso correspondente e chama a função de serviço apropriado em cada módulo listado na chain, na ordem em que foram listadas na configuração. Após cada chamada para uma função de serviço, o tipo de módulo e o código de erro retornado pela função de serviço são usados ​​para determinar o que acontece a seguir. Com algumas exceções, discutidas abaixo, a tabela a seguir se aplica:

Se fail for true no final de uma chain, ou quando um "break" for atingido, o dispatcher retornará o código de erro retornado pelo primeiro módulo que falhou. Caso contrário, retorna PAM_SUCCESS.

A primeira exceção é que o código de erro PAM_NEW_AUTHTOK_REQD é tratado como um sucesso, exceto que se nenhum módulo falhar e pelo menos um módulo retornar PAM_NEW_AUTHTOK_REQD, o dispatcher retornará PAM_NEW_AUTHTOK_REQD.

A segunda exceção é que pam_setcred(3) trata os módulos binding e sufficient como se eles fossem required.

A terceira e última exceção é que pam_chauthtok(3) executa a chain inteira duas vezes (uma vez para verificações preliminares e uma vez para definir a senha), e na fase preliminar, ele trata os módulos binding e sufficient como se fossem required.

O módulo pam_deny(8) é um dos módulos mais simples disponíveis; responde a qualquer pedido com PAM_AUTH_ERR. É útil para desabilitar rapidamente um serviço (adicioná-lo ao topo de cada chain) ou para encerrar chains de módulos sufficient.

O módulo pam_echo(8) simplesmente passa seus argumentos para a função de conversação como uma mensagem PAM_TEXT_INFO. É principalmente útil para depuração, mas também pode servir para exibir mensagens como "O acesso não autorizado será processado" antes de iniciar o procedimento de autenticação.

O módulo pam_exec(8) leva seu primeiro argumento a ser o nome de um programa a ser executado, e os argumentos restantes são passados ​​para esse programa como argumentos de linha de comando. Uma aplicação possível é usá-lo para executar um programa no momento do login, que monta o diretório pessoal do usuário.

The pam_ftpusers(8) module

O módulo pam_group(8) aceita ou rejeita os requerentes com base em sua participação em um determinado grupo de arquivos (normalmente wheel para su(1)). Ele é destinado principalmente para manter o comportamento tradicional do su(1) do BSD, mas tem muitos outros usos, como excluir determinados grupos de usuários de um serviço particular.

O módulo pam_guest(8) permite logins convidados usando nomes de login fixos. Vários requerimentos podem ser colocados na senha, mas o comportamento padrão é permitir qualquer senha, desde que o nome de login seja o de uma conta de convidado. O módulo pam_guest(8) pode ser facilmente utilizado para implementar logins FTP anônimos.

O módulo pam_krb5(8)

O módulo pam_ksu(8)

O módulo pam_lastlog(8)

O módulo pam_login_access(8) fornece uma implementação da primitiva de gerenciamento de contas que impõe as restrições de login especificadas na tabela login.access(5).

O módulo pam_nologin(8) recusa logins não-root quando existe um /var/run/nologin. Este arquivo é normalmente criado por shutdown(8) quando restam menos de cinco minutos até o horário de encerramento programado.

O módulo pam_opie(8) implementa o método de autenticação opie(4). O sistema opie(4) é um mecanismo de desafio-resposta em que a resposta a cada desafio é uma função direta do desafio e uma frase-senha, então a resposta pode ser facilmente computada "just in time" por qualquer pessoa que possua a senha, eliminando a necessidade de listas de senhas. Além disso, como opie(4) nunca reutiliza um desafio que tenha sido respondido corretamente, ele não é vulnerável a ataques de repetição.

O módulo pam_opieaccess(8) é um módulo complementar para pam_opie(8). Sua finalidade é impor as restrições codificadas em opieaccess(5), que regulam as condições sob as quais um usuário que normalmente se autenticaria usando opie(4) tem permissão para usar métodos alternativos. Isso geralmente é usado para proibir o uso de autenticação de senha de hosts não confiáveis.

Para ser eficaz, o módulo pam_opieaccess(8) deve ser listado como requisite imediatamente após uma entrada sufficient para pam_opie(8), e antes de qualquer outro módulo, na chain auth.

O módulo pam_passwdqc(8)

O módulo pam_permit(8) é um dos módulos mais simples disponíveis; responde a qualquer pedido com PAM_SUCCESS. É útil como um espaço reservado para serviços onde uma ou mais chains estariam vazias.

O módulo pam_radius(8)

O módulo pam_rhosts(8)

O módulo pam_rootok(8) reporta sucesso se e somente se o ID do usuário real do processo que o chama (que é assumido como sendo executado pelo requerente) é 0. Isso é útil para serviços que não estão em rede, como su(1) ou passwd(1), para o qual o root deve ter acesso automático.

O módulo pam_securetty(8)

O módulo pam_self(8) reporta sucesso se, e somente se, os nomes do requerente coincidem com os da conta de destino. É mais útil para serviços que não estão em rede, como su(1), onde a identidade do requerente pode ser facilmente verificada.

O módulo pam_ssh(8) fornece serviços de autenticação e de sessão. O serviço de autenticação permite que os usuários que tenham chaves secretas SSH protegidas por senha em seu diretório ~/.ssh se autentiquem digitando sua frase secreta. O serviço de sessão inicia o ssh-agent(1) e o pré-carrega com as chaves que foram descriptografadas na fase de autenticação. Esse recurso é particularmente útil para logins locais, seja em X (usando xdm(1) ou outro gerenciador de login X que reconhece o PAM) ou no console.

O módulo pam_tacplus(8)

Tornando os serviços de login independentes das tecnologias de autenticação. Vipin Samar e Charlie Lai. Sun Microsystems.

Especificação Preliminar do X/Open Single Sign-on. O grupo aberto. 1-85912-144-6. Junho de 1997.

Módulos de autenticação plugáveis​​​​. Andrew G. Morgan. 06-10-1999.

Administração do PAM. Sun Microsystems.

Homepage do OpenPAM. Dag-Erling Smørgrav. ThinkSec AS.

Página inicial do Linux-PAM. Andrew G. Morgan.

Página inicial do Solaris PAM. Sun Microsystems.