| |
SEGURANÇA
Neste primeiro artigo sobre o assunto,
conheça o PAM (Pluggable Authentication Modules), a biblioteca que permite
autenticar usuários
Originalmente a autenticação no
Linux era feita apenas através de senhas cripto-grafadas armazenadas em um
arquivo local chamado
/etc/passwd. Um
programa como o login pedia o nome do usuário e a senha, crip-tografava a
senha e comparava o resultado com o armazenado naquele arquivo. Se fossem
iguais, garantia o acesso à máquina. Caso contrário, retornava erro de
autenticação.
Isto até funciona muito bem para
o programa login, mas, digamos que agora eu queira usá-lo também para
autenticação remota. Ou seja, a base de usuários não está mais na mesma
máquina, mas sim em alguma outra máquina da rede, o chamado servidor de
autenticação. Teremos que modificar o programa login para que ele também
suporte esse tipo de autenticação remota.
Surgiu um novo algoritmo de
criptografia, muito mais avançado, mais rápido e que criptografa melhor.
Queremos usar esse novo algoritmo. Mas certamente teremos que alterar
novamente o programa login para que ele possa suportá-lo também.
No Linux, muitos programas
utilizam algum tipo de autenticação de usuários. Imagine se todos tivessem
que ser reescritos cada vez que algum dos critérios de auten-ti-cação fosse
alterado.
Para resolver este tipo de
problema, há alguns anos a Sun criou o PAM e liberou as especificações em
forma de RFC. O Linux derivou sua im-ple-mentação do PAM a partir deste
documento.
Com o PAM, o aplicativo login
deste exemplo teria que ser reescrito apenas uma vez, justamente para
suportar o próprio PAM. A partir daí, o aplicativo delega a
responsabilidade da autenticação para o PAM e não se envolve mais.
Voltando ao primeiro exemplo, no
caso de se querer utilizar um outro algoritmo de criptografia para as
senhas, basta que o módulo PAM seja modificado para que todos os
aplica-tivos passem, automaticamente e de forma transparente, a usufruir
desta nova forma de autenticação.
O PAM possui uma outra vantagem:
é possível configurar a autenticação de forma individual para cada
aplica-tivo. Com isto é possível fazer com que, por exemplo, um usuário
comum possa usar os dispositivos de áudio do computador, desde que tenha acessa-do
a máquina através do console. Se o login não tiver sido feito no console
(por exemplo, um lo-gin remoto via ssh), esse tipo de acesso ao hardware
será negado. Será que os programas login ou ssh sabem alguma coisa sobre o
dispositivo de áudio da máquina? É claro que não. Eles não precisam. Os
módulos PAM se encarregam disso.
Na verdade, o PAM vai um pouco
além da autenticação. Os módulos podem ser divididos em quatro tipos:
auth: é a parte que verifica se o usuário é
realmente quem ele diz que é. Pode ser bem simples, pedindo apenas um nome
e uma senha, ou utilizando autenticação biométrica, por exemplo (impressão
de voz, imagem da retina ou impressão digital).
account: esta parte verifica se o usuário em
questão está autorizado a utilizar o serviço ao qual está se autenticando.
Os módulos aqui podem checar por horário, dia da semana, origem do login,
login simultâneo, etc.
passwd: este serviço é usado quando se deseja
mudar a senha. Aqui, por exemplo, podem ser colocados mó-du-los que
verificam se a senha é forte ou fraca (mais informações na próxima edição).
session: por fim, a parte session fica
encarregada de fazer o que for necessário para criar o ambiente do usuário.
Por exemplo, fornecer o acesso a alguns dispositivos locais como o de áudio
ou cdrom, montar sistemas de arquivos ou simplesmente fazer o registro do
evento nos arquivos de log do sistema.
Um módulo PAM pode ou não conter
todas estas funções. O
pam_pwdb, por exemplo,
pode ser usado nestes quatro tipos e possui, para cada uma das situações,
diferentes ações, enquanto que o pam_console
é normalmente usado apenas como session.
Desvendando
o PAM no Linux
Praticamente todos os
aplicati-vos do Linux que requerem algum tipo de autenticação suportam PAM,
cuja configuração está localizada no diretório /etc/pam.d. Todo aplica-tivo que suporta PAM,
necessita de um arquivo de configuração neste diretório.
Um programa com suporte a PAM
possui duas interfaces com esta biblioteca: uma de autenticação e outra de
conversação. A de autenticação é a interface através da qual a aplicação
pede que o PAM valide o usuário. A de conversação é usada pelos módulos que
precisem, por exemplo, passar alguma informação para o usuário, como um
prompt, ou um aviso de que a senha expirou. Isso é tudo o que a aplicação
sabe sobre o processo de autenticação feito pelo PAM.
No caso do programa login, a
biblioteca PAM procura o arquivo de configuração desta aplicação, /etc/pam.d/login, e diz quais módulos devem ser usados
e com que parâmetros. Este arquivo está reproduzido na Tabela 1.
Os módulos serão carregados e
executados na mesma ordem em que se encontram no arquivo de configuração.
Note que um módulo pode apro-veitar uma informação de um módulo anterior,
como se faz normalmente para nome_do_usuário/senha, para não ter de pedir
a mesma informação no-vamente para o usuário.
A primeira coluna em um arquivo
de configuração PAM representa o tipo de módulo: auth, account, password ou
session. Neste exemplo, todos estão presentes, mas não é obrigatório. Por
exemplo: Se o programa não tiver suporte para troca de senha, o tipo
“password” não é usado.
A segunda coluna define a flag de
controle para o respectivo módulo. O resultado de cada módulo pode
influenciar de diversas formas o resultado do processo de autenticação
geral. Eis algumas categorias:
required: o resultado deste módulo influencia
diretamente o resultado final. Uma falha em um módulo deste tipo só
aparecerá para o usuário após todos os outros módulos desta classe serem
executados.
requisite: semelhante a required, mas, em caso de
falha, os outros mó-dulos não são executados e o controle volta
imediatamente para o apli-cativo.
sufficient: a falha deste módulo não implica em
falha da autenticação como um todo. Se o módulo falhar, o próximo da classe
é executado. Se não houver próximo, então a classe retorna com sucesso. Se,
por outro lado, o módulo terminar com sucesso, então os módulos seguintes
dessa classe não serão executados. Este parâmetro é bastante usado no caso
de se usar LDAP para a autenticação, por exemplo, ou outra fonte de dados.
optional: módulos marcados como optional
praticamente não influenciam o resultado da autenticação como um todo. Eles
terão alguma influência somente caso os módulos anteriores da mesma classe
não apresentem um resultado definitivo.
Por fim, a terceira coluna define
o nome do módulo que será usado e seus parâmetros. Todos os módulos estão
documentados em
/usr/[share]/doc/pam-versão. Vamos aqui apenas ilustrar como funcionam os usados no programa
login.
Em primeiro lugar, observamos que
todos os módulos, com exceção do pam_console, são required, ou seja, não
podem falhar. No próximo artigo apresentaremos os módulos do PAM e suas
principais características.
Tabela 1
#%PAM-1.0
auth
required /lib/security/pam_securetty.so
auth
required /lib/security/pam_pwdb.so shadow nullok
auth
required /lib/security/pam_nologin.so
account
required /lib/security/pam_pwdb.so
password
required /lib/security/pam_cracklib.so
password
required /lib/security/pam_pwdb.so shadow md5 nullok use_authtok
session
required /lib/security/pam_pwdb.so
session
optional /lib/security/pam_console.so
Com o PAM
é possível configurar a autenticação de forma individual para cada
aplicativo
Quase
todos os aplicativos do Linux que requerem algum tipo de autenticação
suportam PAM
| |
