Módulos personalizados do PAM e considerações de segurança

Question

Estou escrevendo meu próprio módulo PAM que fará parte de um aplicativo que estou desenvolvendo, mas não sei exatamente onde colocá-lo. Meu módulo basicamente faz autenticação em nível de rede (com outro mojo claro) similar ao LDAP.

Existem muitos arquivos de configuração no meu diretório /etc/pam.d/ , e eu sei o que a maioria dos serviços faz (exceto um casal, como atd, polkit, ppp). Eu suponho que a autenticação com o PAM stack seja algo assim:

1. Executa pilha com base no nome do serviço (se existir um arquivo de configuração)
2. Se não estiver autenticado, use o common- *, onde * é o tipo de módulo (auth, account, etc)
3. Retorna o sucesso ou falha ao chamar o aplicativo (e quaisquer outros dados, é claro)

Estou correto nesta suposição? Todas as plataformas têm common-auth, common-account, common-password e common-session?

Se assim for, eu estava pensando em apenas colocá-lo no topo do common- * como um módulo sufficient para que, em caso de falha, a pilha normal do PAM não fosse afetada. Isso é particularmente vantajoso porque posso programaticamente fazer isso na instalação do software.

Estou perdendo alguma vulnerabilidade de segurança em potencial?

Não encontrei documentação muito boa sobre onde integrar módulos PAM personalizados ou problemas de segurança em torno de onde colocar módulos.

    

Answer 1

Quando você chama o Linux-PAM para algum procedimento de autenticação, é sempre uma e apenas uma pilha que é executada.

A definição da pilha é procurada nesses locais; o primeiro tentativa bem-sucedida determina qual arquivo é lido:

1. o arquivo em /etc/pam.d com o nome do aplicativo "nome do serviço" (por exemplo, sshd ou gdm ) ou

2. o arquivo /etc/pam.d/other se nenhum arquivo específico do serviço existir ou

3. o arquivo /etc/pam.conf se o diretório /etc/pam.d não existir.

Veja a documentação da função pam_start para detalhes.

Os arquivos common- * são uma convenção seguida por muitos distribuições, mas não são obrigatórias pelo próprio software PAM. Eles geralmente são incluídos por outros arquivos PAM por meio de @include afirmações; por exemplo, o arquivo /etc/pam.d/other no Debian tem o seguinte conteúdo:

# We fall back to the system default in /etc/pam.d/common-*
@include common-auth
@include common-account
@include common-password
@include common-session

As mesmas declarações @include podem ser usadas pelo arquivo específico do serviço como bem, e - de fato - eles estão na configuração default no Debian. Note que isto é uma questão de configuração: um sysadmin é livre para altere o arquivo em /etc/pam.d para não incluir arquivos comuns * em tudo!

Portanto: se o seu módulo PAM é específico para sua aplicação, crie um arquivo de serviço específico do aplicativo e chame o módulo a partir dele. Não não adiciona automaticamente um módulo ao arquivo PAM de outros serviços nem o arquivo others de fallback, pois isso pode quebrar outros aplicativos instalado no sistema. O gerenciamento da pilha de software do PAM é um tarefa para o administrador do sistema, não para o aplicativo desenvolvedores.