Linux-PAM: Como Funciona – Teoria

Por várias vezes durante minha vida como SysAdmin eu escutei o mesmo comentário: para que serve o Linux-PAM? Qual o sentido dele? Como ele funciona? Isso acabou me motivando a falar sobre esse assunto, pois, além de eu mesmo querer saber como funciona e quando utilizar, eu queria que essa minha experiência fosse compartilhada com outros usuários de sistemas Unix-Like. Nesse post irei explicar o processo de funcionamento do PAM e seus arquivos de configuração, e num post futuro pretendo tratar de como configurar dois módulos que acredito serem extremamente importantes: pam_limits e o google authenticator.

 

O que é o Linux-PAM?

 

Linux-PAM (Pluggable Authentication Modules) é uma das diversas implementações do PAM que existem, sendo outras a OpenPAM e o JavaTM PAM, que foram desenvolvidas como uma maneira dos desenvolvedores implementarem uma autenticação que fosse simples, bem documentada, com um bom suporte da comunidade, e que permitisse que os mantenedores do serviço pudessem alterar o esquema de autenticação sem a necessidade do desenvolvedor reimplementar a solução. No caso a que iremos tratar é justamente a implementação voltada aos sistema operacional GNU/Linux, porém não é muito diferente a parte teórica para as outras implementações.

O fluxo do Linux-PAM é bem simples de entender, e extremamente parecido com o TCPWrappers: o cliente solicita acesso a um determinado serviço que utiliza a biblioteca compartilhada libpam.so para autenticação. Essa comunicação então é primeiramente redirecionada ao Linux-PAM, que validará a autenticação por uma série de módulos informados numa determinada ordem dentro de um arquivo de configuração. Caso falhe em alguma checagem, então o mesmo retorna que o acesso foi negado. Caso seja aprovado em todas as checagens, então é redirecionado para o serviço em questão, e então a comunicação prossegue normalmente entre cliente e servidor.

PAM sozinho não faz nada – ele seria equivalente a um framework aonde você estende suas funções com “módulos”. Vários módulos já vem com o sistema operacional, como por exemplo o pam_limits (limitador de recursos), pam_nologin (impede a autenticação no ambiente), securetty (Bloqueia o login do root em x terminais), pam_time (módulo de gerenciamento de horários), entre outros. Você não é limitado a usar um único módulo para tudo: você pode ordenar eles da forma que quiser, além de aumentar ou diminuir o grau de importância de um módulo ou outro.

Os arquivos de configuração ficam no /etc/pam.d, enquanto suas bibliotecas ficam nos diretórios /lib/security e /lib64/security. Para saber se um software possui suporte ao Linux-PAM, basta rodar o comando ldd para listar todas as bibliotecas compartilhadas de um programa, e executar um grep por “libpam”.

ldd /bin/login | grep libpam
    libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0
    libpam_misc.so.0 => /lib/x86_64-linux-gnu/libpam_misc.so.0

Entendendo o PAM.d

 

 

Toda a configuração do Linux-PAM é armazenada no diretório /etc/pam.d, aonde existe um arquivo para cada aplicação que utiliza a biblioteca libpam.so para validação de autenticação. A leitura do arquivo é feita em ordem, do primeiro item configurado até o ultimo, porém esses itens possuem momentos específicos para serem ativados, não sendo todos iniciados exatamente durante o login do usuário. Alguns podem ser ativados depois de autenticado, como é o caso do pam_limits.so. O preenchimento de um arquivo de Linux-PAM deve seguir a seguinte ordem:

domínio          controle          modulo          parâmetros

O primeiro campo é o domínio, aonde você informa em qual situação esse módulo deve ser ativado, sendo que cada domínio possui um momento em que será acionado, alguns são durante a autenticação, e outros após a autenticação. O termo “domínio” não é como essa parte da configuração é chamada, porém por falta de um nome para ela muitos autores decidem usar qualquer coisa para descrever, sendo que alguns até optaram pelo termo domínio (realm no original), enquanto outros (Red Hat por exemplo) chamam de Interface de Módulos. Um arquivo de configuração do Linux-PAM é dividido em quatro domínios, sendo que cada domínio possui uma coleção de módulos que serão executados em determinados momento e em uma determinada ordem. Esses domínios são “account”, “auth”, “password”, “session”, na qual serão descritos abaixo:

Account: Esse domínio possui como tarefa validar as informações da conta, como por exemplo se ela existe, ou se ela possui acesso ao servidor, ou se a senha está expirada, e assim por diante;

Auth: Abreviação para authentication, sua tarefa é validar se as credenciais fornecidas pelo usuário são validas. As credenciais não precisam ser necessariamente usuário e senha, porém é a maneira mais comum de se solicitar acesso a um sistema. Credenciais também contam digitais, cartões magnéticos, certificados, tokens, entre outros;

Password: Chama operações em caso de você ter tido acesso ao sistema, porém suas credenciais estão vencidas e precisam ser alteradas. Um exemplo disso seria o ato de você se autenticar no sistema Linux com uma senha vencida, e a primeira coisa que você dá de cara ao se autenticar é com o comando passwd;

Session: Também como o Password, esse domínio não serve para validar se um usuário possui acesso ao ambiente ou não, e sim para realizar operações antes de ele poder se autenticar ou após ele poder se autenticar, como logs do audit, montar o diretório home do usuário, chamar o Shell padrão do usuário, entre outras atividades.

O segundo campo é o controle, na qual define o grau de importância de um módulo ou outro dentro do arquivo. O Linux-PAM conta com quatro tipos de controles, sendo esses controles “required”, “requisited”, “sufficient”, “optional”, além de dois relacionados a arquivos de configuração externos, no caso o “substack” e o “include”. Veremos abaixo um pouco sobre cada um desses controles:

Required: Um módulo listado como required significa que ele é obrigatório para que toda a operação retorne como “Autorizado”. A falha de um módulo required significa o bloqueio total do serviço, porém o required tem um diferencial: o retorno de “Operação Não Autorizada” só ocorre após todos os módulos serem checados, mesmo que esse required que falhou esteja no início do arquivo. Isso é feito para que os usuários mal intencionados que desejam acesso ao seu ambiente não saibam em que parte da checagem ele falhou, dificultando assim suas ações;

Requisited: Um módulo listado como requisited é bem parecido com o required: é obrigatório para que toda a operação retorne como “Autorizado”. A falha de um módulo requisited significa o bloqueio total do serviço, porém a diferença comparado ao required é que caso essa checagem falhe, nenhuma outra é feita e o retorno de “Operação Não Autorizada” é feito no mesmo instante;

Sufficient: Um módulo listado como sufficient somente falhará caso todos os módulos listados como sufficient falhem. O fluxo desse seria mais ou menos da seguinte forma: você configurou uma lista de módulos como sufficient, e quando foi executar a autenticação, quase todos os módulos como sufficient falharam, com exceção de pelo menos 1. Por conta da checagem ter passado por esse um, toda a operação é retornada como sucesso. A única exceção para esse caso é quando você possui módulos como Required/Requisited e eles falham: o Linux-PAM ignora completamente o resultado de sufficient, seja ela sucesso ou não;

Optional: Esse controle é o de menor importância e só valerá seu resultado caso o módulo listado como optional seja o único dentro do arquivo ou seja o único que esteja funcionando corretamente;

Include: Inclui um arquivo de configuração separado para ser usado no lugar de um módulo. A falha de um módulo dentro de um arquivo instanciado via include significa a falha de toda a operação não importa quais resultados tenha dado anteriormente;

Substack: Semelhante ao Include, inclui um arquivo de configuração separado para ser usado no lugar de um módulo. A diferença é que a falha de um módulo dentro de um arquivo instanciado via substack significa a falha somente desse arquivo, não de toda a operação.

O terceiro e quarto campo são direcionados a informar o módulo que será utilizado para a checagem, e demais parâmetros que ele possa precisar para funcionar, como no caso o módulo cracklib, que é usado para descobrir se sua senha é fácil de ser descoberta, comparando ela com um dicionário de padrões de senhas fracas. Nem todos os módulos possuem parâmetros, por isso o quarto campo é comum de ficar vazio na grande maioria das vezes.

Conclusões

Esse primeiro artigo é completamente teórico, e serve como introdutório para outros dois que pretendo lançar, aonde iremos fazer algo mais prático, como limitar recursos de máquina, proteger com senha, gerenciar horários de acesso, entre outros. Para entender como funciona a ferramenta, boa parte disso foi buscando artigos sobre o assunto na internet, tarefa que se provou simples, porém algumas informações que me faltavam, como substack e include, foram mais complicadas de se encontrar um material que explicasse de forma compreensível esses dois controles. Deixarei abaixo o link dos artigos que usei de consulta.

Links:

  • http://www.linux-pam.org/
  • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/Pluggable_Authentication_Modules.html
  • http://www.tuxradar.com/content/how-pam-works
  • https://www.linux.com/news/understanding-pam

2 thoughts to “Linux-PAM: Como Funciona – Teoria”

  1. A explicação ficou muito boa [Como de costume] ! Só acho que faltou um exemplo de uso do PAM.
    Acho que se você apresentasse o pam_nologin como exemplo já ficaria um pouco mais claro para quem está procurando entender como funciona o PAM 🙂

  2. Ótimo exemplo de como funciona o PAM.
    As explicações ficaram extremamente claras e diretas. Parabens.

    A explicação da diferença de required e requisited estão incríveis.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *