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

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 no nível da rede (com outro mojo, é claro) semelhante ao LDAP.

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

1. Executa a pilha com base no nome do serviço (se houver um arquivo de configuração)
2. Se não estiver autenticado, volte ao common- *, onde * é o tipo de módulo (auth, conta, etc)
3. Retornar com êxito ou falhar ao chamar o aplicativo (e quaisquer outros dados, é claro)

Estou correto nesta suposição? Todas as plataformas têm autenticação comum, conta comum, senha comum e sessão comum?

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

Sinto falta de possíveis vulnerabilidades de segurança?

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

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

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

1. o arquivo /etc/pam.dnomeado após o aplicativo "nome do serviço" (por exemplo, sshdou gdm) ou

2. o arquivo /etc/pam.d/otherse não existir um arquivo específico de serviço ou

3. o arquivo /etc/pam.confse o diretório /etc/pam.dnão existir.

Consulte a documentação da função pam_start para obter detalhes.

Os arquivos common- * são uma convenção seguida por muitas distribuições Linux, mas não são obrigatórios pelo próprio software PAM. Eles geralmente são incluídos por outros arquivos PAM por meio de @include instruções; por exemplo, o /etc/pam.d/otherarquivo 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 @includeinstruções também podem ser usadas por arquivos específicos de serviço, e -indeed- eles estão na configuração padrão no Debian. Observe que isso é uma questão de configuração: um administrador de sistema é livre para alterar o arquivo para /etc/pam.dnão incluir nenhum arquivo comum- *!

Portanto: se o seu módulo PAM for específico para o seu aplicativo, crie um arquivo de serviço específico do aplicativo e chame o módulo a partir daí. Você não adicionar automaticamente um módulo para arquivo PAM de outros serviços nem à queda-back othersde arquivos, pois isso pode quebrar outros aplicativos instalados no sistema. O gerenciamento da pilha de software PAM é uma tarefa para o administrador do sistema, não para os desenvolvedores de aplicativos.