2. Termos e convenções

2.1. Definições

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.

conta (account)

Um conjunto de credenciais que o requerente está solicitando ao mediador.

requerente (applicant)

Usuário ou entidade que solicita autenticação

Mediador (arbitrator)

Usuário ou entidade a qual tem privilégios necessários para verificar as credenciais do requerente e autorizar ou não a solicitação

chain

Uma sequência de módulos que irá ser chamada em resposta a uma solicitação do PAM. A chain inclui informações sobre a ordem a qual invocar os módulos, quais argumentos foram passados e como interpretar os resultados.

client

A aplicação responsável por inicializar uma solicitação de autenticação em nome do requerente para obter as informações necessárias da autenticação dele.

recursos

Um dos quatro grupos básicos de funcionalidades fornecidos pelo PAM: autenticação, gerenciamento de conta, gerenciamento de sessão e atualização de token de autenticação.

módulo

Uma coleção de uma ou mais funções relacionadas implementando um recurso de autenticação específico, reunidas em um único arquivo binário (normalmente carregável dinamicamente) e identificadas por um único nome.

política

O conjunto completo de instruções de configuração que descrevem como lidar com solicitações do PAM para um serviço específico. Uma política normalmente consiste em quatro chains, uma para cada recurso, embora alguns serviços não utilizem os quatro recursos.

servidor

O aplicativo agindo em nome do mediador para conversar com o cliente, recuperar informações de autenticação, verificar as credenciais do requerente e conceder ou negar solicitações.

serviço

Classe de servidores que provêm recursos similares ou relacionados e requerem autenticação similar. As políticas do PAM são definidas por serviço, portanto, todos os servidores que reivindicam o mesmo nome de serviço estarão sujeitos à mesma política.

sessão

O contexto com o qual serviços são apresentados para o requerente pelo servidor. Um dos quatro recursos do PAM, gerenciamento de sessão, é concedido exclusivamente configurando e derrubando esse contexto.

token

Um pedaço de informação associada à conta, como uma senha sendo uma palavra ou uma frase, que o solicitante deve fornecer para provar sua identidade.

transação

Uma sequência de solicitações do mesmo requerente para a mesma instância do mesmo servidor, começando com a configuração de autenticação e sessão e terminando com a desmontagem da sessão.

2.2. Exemplos de uso

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

2.2.1. O cliente e o servidor são um

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

% whoami
alice
% ls -l `which su`
-r-sr-xr-x  1 root  wheel  10744 Dec  6 19:06 /usr/bin/su
% su -
Password: xi3kiune
# whoami
root
  • O requerente é alice.

  • A conta é root.

  • O processo su(1) é ao mesmo tempo, o cliente e o servidor.

  • O token de autenticação é xi3kiune.

  • O mediador é root, e é por isso que su(1) possui setuid para root.

2.2.2. O cliente e o servidor são separados

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!

% whoami
eve
% ssh bob@login.example.com
bob@login.example.com's password: god
Last login: Thu Oct 11 09:52:57 2001 from 192.168.0.1
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
	The Regents of the University of California.  All rights reserved.
FreeBSD 4.4-STABLE (LOGIN) #4: Tue Nov 27 18:10:34 PST 2001

Welcome to FreeBSD!
%
  • O requerente é eve.

  • O cliente é o processo ssh(1) de Eve.

  • O servidor é o processo sshd(8) em login.example.com

  • A conta é bob.

  • O token de autenticação é god.

  • Embora isso não seja mostrado neste exemplo, o mediador é root.

2.2.3. Exemplo de política

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

sshd	auth		required	pam_nologin.so	no_warn
sshd	auth		required	pam_unix.so	no_warn try_first_pass
sshd	account		required	pam_login_access.so
sshd	account		required	pam_unix.so
sshd	session		required	pam_lastlog.so	no_fail
sshd	password	required	pam_permit.so
  • Esta política se aplica ao serviço sshd (que não é necessariamente restrito ao servidor sshd(8)).

  • auth, account, session e password são recursos.

  • pam_nologin.so, pam_unix.so, pam_login_access.so, pam_lastlog.so e pam_permit.so são módulos. Fica claro neste exemplo que o pam_unix.so fornece pelo menos dois recursos (autenticação e gerenciamento de conta).

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.