SISTEMADEAUTENTICAOCOMOPAM

PAM a parte principal da autenticao em um sistema Linux. PAM

significaPluggable Authentication Modules, ou Mdulos de Autenticao
Plugveis/Modulares.
Originalmente a autenticao no Linux era apenas via senhas criptografadas
armazenadas em um arquivo local chamado /etc/passwd. Um programa como o login
pedia o nome do usurio e a senha, criptografava a senha e comparava o resultado
com o armazenado naquele arquivo. Se fossem iguais, garantia o acesso mquina.
Caso contrrio, retornava erro de autenticao. Isto at funciona muito bem para o
programa login, mas, digamos que agora eu queira usar isso tambm para
autenticao remota. Ou seja, a base de usurios no est mais na mesma mquina,
mas sim em alguma outra mquina da rede, o chamado servidor de autenticao.
Teremos que mudar o programa login para que ele tambm suporte esse tipo de
autenticao remota.
Surgiu um novo algoritmo de criptografia, muito mais avanado, mais rpido,
criptografa melhor, etc. Queremos usar esse novo algoritmo. Claro que teremos que
mudar novamente o programa login para que ele suporte este novo algoritmo
tambm. No Linux, muitos programas utilizam algum tipo de autenticao de
usurios. Imagine se todos eles tivessem que ser reescritos cada vez que se mudasse
algum dos critrios de autenticao.
Para resolver este tipo de problema, a Sun criou o PAM h alguns anos e liberou as
especificaes em forma de RFC. O Linux derivou sua implementao do PAM a
partir deste documento. Com PAM, o aplicativo login deste exemplo teria que ser
reescrito apenas uma vez, justamente para suportar PAM. A partir de ento, o
aplicativo delega a responsabilidade da autenticao para o PAM e no se envolve
mais com isso.
Voltando ao exemplo anterior, no caso de se querer utilizar um outro algoritmo de
criptografia para as senhas, basta que o mdulo PAM seja modificado para que todos
os aplicativos automaticamente e de forma transparente passem a usufruir desta nova
forma de autenticao. PAM possui uma outra vantagem: possvel configurar a
autenticao de forma individual para cada aplicativo. Com isto possvel fazer com
que, por exemplo, um usurio comum possa usar os dispositivos de udio do
computador desde que tenha se logado na mquina atravs do console. Se o login no
tiver sido feito no console (por exemplo, um login remoto via ssh), este tipo de
acesso ao hardware ser negado. Ser que os programas login ou ssh sabem alguma

coisa sobre o dispositivo de udio da mquina? claro que no. Eles no precisam.
Os mdulos PAM se encarregam disso.
Na verdade, PAM vai um pouco alm da autenticao. Os mdulos podem ser
divididos em quatro tipos:
auth:
a parte que verifica que o usurio realmente quem ele diz que . Pode ser
bem simples, pedindo apenas por um nome e uma senha, ou utilizando
autenticao biomtrica, por exemplo (como uma impresso de voz, uma
imagem da retina ou impresso digital).
account:
Esta parte verifica se o usurio em questo est autorizado a utilizar este servio
ao qual ele est se autenticando. Os mdulos aqui podem checar por horrio, dia
da semana, origem do login, login simultneo, etc.
passwd:
Este servio usado quando se deseja mudar a senha. Por exemplo, aqui podem
ser colocados mdulos que verificam se a senha forte ou fraca.
session:
Por fim, a parte session fica encarregada de fazer o que for necessrio para criar
o ambiente do usurio. 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 mdulo PAM pode ou no conter todas estas funes. O mdulo pam_pwdb, por
exemplo, pode ser usado nestes quatro tipos e possui aes diferentes em cada uma
das situaes, enquanto quepam_console normalmente usado apenas como session.
7.3.1.1. Instalao
Os mdulos PAM j vm instalados por padro no Conectiva Linux. Voc pode
verificar procurando, na lista de pacotes instalados do synaptic, pelo pacote pam.
7.3.1.2. PAM no Linux
Praticamente todos os aplicativos do Linux que requerem algum tipo de autenticao
suportam PAM. Na verdade, no funcionam sem PAM. Toda a configurao est

localizada no diretrio /etc/pam.d. Quando um aplicativo suporta PAM, ele necessita

de um arquivo de configurao neste diretrio. A Figura 7-1 ilustra como funciona a
autenticao com PAM usando o programa login como exemplo:
Figura 7-1. Autenticao com PAM

Um programa com suporte a PAM possui duas interfaces com a biblioteca: a de

autenticao e a de conversao. A interface de autenticao por onde a aplicao
pede que o PAM valide o usurio. A de conversao usada pelos mdulos que, por
exemplo, precisem passar alguma informao para o usurio, como um prompt, ou
um aviso de que a senha expirou. Isso tudo o que a aplicao sabe sobre o processo
de autenticao feito pelo PAM. A conversao est ilustrada na figura no
mdulo pam_pwdb (b).
A biblioteca PAM vai procurar o arquivo de configurao da aplicao login. Este
arquivo /etc/pam.d/login e vai dizer quais mdulos devem ser usados e com que
parmetros. Este arquivo est reproduzido a seguir:
#%PAM-1.0
auth
auth
auth
account
password
password
use_authtok
session
session

required
/lib/security/pam_securetty.so
required
/lib/security/pam_pwdb.so shadow nullok
required
/lib/security/pam_nologin.so
required
/lib/security/pam_pwdb.so
required
/lib/security/pam_cracklib.so
required
/lib/security/pam_pwdb.so shadow md5 nullok \
required
optional

/lib/security/pam_pwdb.so
/lib/security/pam_console.so

Este arquivo de configurao lista os mdulos PAM que este programa (login) deve
usar, e eles esto representados na figura atravs de letras. Estes mdulos sero
carregados e executados na ordem em que estiverem no arquivo de configurao.
Note que um mdulo pode aproveitar uma informao de um mdulo anterior, como
normalmente feito para username/senha. Isso usado para no pedir a mesma
informao novamente para o usurio.
A primeira coluna em um arquivo de configurao PAM representa o tipo de mdulo:
auth, account, password ou session. Neste exemplo, todos esto presentes, mas isto
no obrigatrio. Se um programa no tiver suporte troca de senha, o tipo
"password" no usado.
A segunda coluna define a flag de controle para o seu respectivo mdulo. O resultado
de cada mdulo pode influenciar de diversas formas o resultado do processo de

autenticao geral. H algumas categorias:

required:
O resultado deste mdulo influencia diretamente o resultado final. Uma falha em
um mdulo deste tipo s aparecer para o usurio aps todos os outros mdulos
desta classe serem executados.
requisite:
Semelhante a required, mas os outros mdulos no so executados e o controle
volta imediatamente para o aplicativo em caso de falha.
sufficient:
A falha deste mdulo no implica em falha da autenticao como um todo. Se o
mdulo falhar, o prximo da classe executado. Se no houver prximo, ento a
classe retorna com sucesso. Se, por outro lado, o mdulo terminar com sucesso,
ento os mdulos seguintes dessa classe no sero executados.
optional:
Os mdulos marcados como optional praticamente no influenciam o resultado
da autenticao como um todo. Eles apenas tero alguma influncia caso os
mdulos anteriores da mesma classe no apresentem um resultado definitivo.
Por fim, a terceira coluna define o nome do mdulo que ser usado e seus parmetros.
Todos os mdulos esto documentados em /usr/doc/pam-verso. Vamos aqui apenas
ilustrar como funcionam os usados no programa login.
Em primeiro lugar, observamos que todos os mdulos so required, ou seja, no
podem falhar. Com exceo do pam_console.
7.3.1.2.1. pam_securetty
Este o primeiro mdulo a ser usado e ele simplesmente verifica o terminal de onde
o login est ocorrendo. Este mdulo no usa parmetros, mas possui um arquivo de
configurao: /etc/securetty. Neste arquivo listamos os terminais a partir dos quais o
usurio root pode fazer login. Ou seja, so os terminais considerados seguros. Apesar
do nome terminais, conexes remotas tambm so controladas por aqui, pois elas
alocam pseudoterminais (telnet, etc). O mdulo retorna sucesso para qualquer usurio
diferente de root e, se for root, somente se o terminal de onde est vindo o login
estiver listado no arquivo/etc/securetty. Na srie 2.2.x do kernel, os pseudoterminais

so alocados dinamicamente em um sistema de arquivos virtual, o /dev/pts. Para

permitir o login de root via telnet, por exemplo, basta acrescentar
ao /etc/securetty: pts/0. Note que isto somente liberar o pseudoterminal pts/0. Veja
no exemplo seguir:
[darkangel@manticore darkangel]$ telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Conectiva Linux 7.0
Kernel 2.4.5-7cl
login: root
Password:
[root@manticore /root]# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Conectiva Linux 7.0
Kernel 2.4.5-7cl
login: root
Password:
Login incorrect
login:

A primeira conexo telnet ganhou o pseudoterminal pts/0. J a segunda teve o pts/1

alocada para si, e este pseudoterminal no estava listado no arquivo /etc/securetty.
Portanto, o acesso no foi autorizado. Por que isto no funciona com ssh, por
exemplo? Se olharmos o arquivo de configurao PAM para o ssh, veremos que o
mdulo pam_securetty no est presente ali. SSH possui seu prprio mecanismo de
acesso para o usurio root, mas nada impede que pam_securetty seja acrescentado no
arquivo PAM. O mdulo pam_securetty tambm pode ser usado para controlar o
login a partir do ambiente grfico, por exemplo. Basta acrescentar o mdulo ao
arquivo /etc/pam.d/kde (se o kdm estiver sendo usado para login grfico). A linha a
ser acrescentada ao arquivo /etc/securetty (alm de se acrescentar pam_securetty aos
respectivos arquivos PAM, claro) : :0. Isto para o display zero. Para permitir o
login de root em outros displays, a sintaxe : :DISPLAY .
O objetivo original deste mdulo o de evitar o login do root em terminais inseguros.
Este conceito de terminais foi estendido ao login remoto (atravs dos
pseudoterminais).
7.3.1.2.2. pam_pwdb
O mdulo pam_pwdb o mdulo principal da autenticao do programa login. Ele
vai pedir um nome de usurio e uma senha e verificar se esto corretos. Como tal, o
mdulo utiliza a funo de conversao para interrogar o usurio e pegar as

informaes desejadas.
Este mdulo aceita alguns parmetros, conforme seu uso (auth, account, etc.):
shadow: se estiverem sendo usadas senhas shadow ou convencionais.
nullok: permite o uso de senhas em branco. Note que, mesmo que a senha seja

em branco (nula), o usurio no conseguir fazer login se no existir nullok na

linha auth para este mdulo.
md5: usa criptografia (hash) md5 em vez do crypt padro. Pode ser usado na

linha password.
use_authtok: indica que o mdulo deve usar a autenticao j fornecida para os

mdulos anteriores, de forma a no interrogar o usurio novamente. Alguns

outros mdulos suportam o parmetrouse_first_pass, que funciona da mesma
forma. Existe ainda o try_first_pass, que primeiro tenta as mesmas credenciais:
se houver falha, pede novamente para o usurio. O use_first_pass no faz esse
novo pedido caso ocorra uma falha.
O try_first_pass ser usado mais adiante quando mostrarmos a autenticao via
LDAP. Este mdulo tambm possui seu prprio arquivo de
configurao: /etc/pwdb.conf. No entraremos em detalhes quanto sintaxe
deste arquivo, pois o mdulo pam_pwdb no muito extensvel. Na verdade,
o pam_unix bem mais genrico por usar as funes da glibc e, portanto,
suporta NIS, LDAP, arquivos texto, arquivos binrios e qualquer outra coisa
que a glibc vier a suportar (atravs de NSS). No caso de uso com a classe
session, o mdulo pam_pwdb apenas faz o log do usurio que entrou no
sistema. Sendo usado com a classe account, o mdulo vai verificar se a senha
do usurio expirou, h quanto tempo a senha no trocada, etc.
7.3.1.2.3. pam_nologin
O mdulo pam_nologin bastante simples, e muito til. uma forma rpida de
desabilitar o login de qualquer usurio que no seja o root. Para isto, basta criar o
arquivo /etc/nologin. Existindo este arquivo, o mdulo pam_nologin vai sempre
retornar ERRO para usurios diferentes de root e exibir o contedo
de /etc/nologin (onde se deve colocar o motivo da proibio), ou seja, s o usurio
root consegue se logar na mquina. Quando o arquivo for removido, a operao
voltar ao normal, com usurios comuns podendo se logar novamente. Isto pode ser
til quando se quer fazer alguma manuteno no sistema, por exemplo, situao em

que logins de usurios so indesejveis. Alguns aplicativos do prprio Linux tambm

podem criar este arquivo e depois remov-lo quando alguma operao crtica for
concluda.
Note que os usurios que j estiverem logados na mquina no so afetados pela
criao ou remoo do arquivo /etc/nologin.
7.3.1.2.4. pam_cracklib
Este mdulo especialmente importante para a segurana pr-ativa. Colocado apenas
na classe password, o mdulo vai verificar a senha do usurio antes que ela seja
trocada. Se for uma senha considerada fraca, ela ser rejeitada e o usurio no
conseguir trocar a senha. As verificaes que o mdulo faz atualmente so:
palndromo: a nova senha um palndromo?
caixa: a senha nova a antiga com apenas mudanas de maisculas /

minsculas?
similar: a nova senha muito similar antiga? Esta verificao pode ser

controlada por um parmetro que indica o nmero mnimo de caracteres

diferentes que a senha nova deve ter em relao senha antiga. O valor padro
10 ou metade do tamanho da senha atual, o que for menor.
Senha repetida: se existir o arquivo /etc/security/opasswd com as senhas

anteriores do usurio, o mdulo pam_cracklib vai tambm verificar se a senha

nova j no foi usada anteriormente. Esse arquivo de senhas antigas
atualmente gerado apenas pelo mdulo pam_unix, embora exista uma
discusso para se criar um mdulo especfico para esta tarefa (algo
como pam_saveoldpass) e remover esta funcionalidade do mdulo pam_unix.
Os parmetros normalmente utilizados com o mdulo cracklib so:
retry=N
"N" o nmero de tentativas que o usurio poder fazer para fornecer uma
senha considerada boa.
difok=N
"N" o nmero de letras diferentes que a senha nova deve ter em relao
senha antiga. Este parmetro controla o comportamento da checagem do tipo

"similar", vista h pouco. O valor padro 10 (e este o valor alterado por "N"
ou metade do tamanho da senha atual), aquele que for o menor.
minlen=N
Tamanho mnimo da nova senha mais um. Alm de contar a quantidade de
caracteres da senha nova, crditos tambm podem ser fornecidos com base na
quantidade de algarismos, caracteres maisculos/minsculos e smbolos. Ou
seja, se o valor de minlen for 10, o usurio pode usar uma senha com menos do
que 10 caracteres, desde que, somando a quantidade de caracteres mais os
crditos, o valor final ultrapasse 10. Por exemplo:
password required /lib/security/pam_cracklib.so retry=3 minlen=10

Especificamos um tamanho mnimo de 9 para a senha nova. Portanto, uma senha

igual a senharuim vai funcionar (possui nove caracteres). Mas uma senha igual
a am0Bb$ tambm funcionar, apesar de possuir apenas 6 caracteres. Como?
Por causa dos crditos.
am0Bb$=>6+1(B, maiscula)+1(0, dgito)+1($, smbolo)= 9=>OK,
passar.

Por outro lado:

am0Bbd => 6 + 1(B, maiscula) + 1(0, dgito) = 8 => no passar.

Por padro, cada um dos tipos de variao da senha (minsculo, maisculo,

algarismo e smbolo) conta no mximo um crdito. Ou seja:
am0b9$ => 6 + 1(0, dgito) + 1 ($, smbolo) = 8 => no passa

Note que o uso de dois algarismos no ajudou em termos de crditos. Mas isto
pode ser mudado se passarmos um outro parmetro para o mdulo:
password required /lib/security/pam_cracklib.so retry=3 \
minlen=10 dcredit=2

Atravs do parmetro dcredit estamos dizendo que toleraremos no mximo dois

crditos provenientes de algarismos na senha. Com esta alterao, a
senha am0b9$ passar como vlida pois usa dois algarismos e ento atingir o
mnimo de 9 exigido por esta configurao do mdulo. Estes parmetros de
crditos tambm existem para as outras variantes:
dcredit: nmero mximo de crditos fornecidos provenientes do uso de

algarismos na senha. O valor padro 1.

ucredit: nmero mximo de crditos fornecidos provenientes do uso de

letras maisculas na senha. O valor padro 1.

lcredit: nmero mximo de crditos fornecidos provenientes do uso de

letras minsculas na senha. O valor padro 1.

ocredit: nmero mximo de crditos fornecidos provenientes do uso de

outros caracteres (smbolos) na senha. O valor padro 1.

7.3.1.2.5. pam_console
O objetivo do mdulo pam_console permitir ao usurio local (ou seja, no console,
fisicamente na mquina) o acesso a diversos dispositivos normalmente restritos ao
superusurio, como placa de som, dispositivo de disquete e tambm permitir ao
usurio comum (local) executar certas tarefas, como desligar o computador, entrar no
ambiente grfico ou mesmo instalar pacotes RPM.
Essa capacidade adicional fornecida ao usurio no seu primeiro login e removida
aps o ltimo logout, e se d atravs da modificao das permisses de alguns
dispositivos e tambm atravs de autenticao.
Diz-se que o primeiro usurio que fizer login no console "ganha" o console e as
permisses definidas no arquivo de configurao /etc/security/console.perms. Quando
um usurio possui o console, um arquivo de lock criado em /var/lock com o
nome console.lock. O contedo do arquivo o nome do usurio que possui o console.
Se um outro usurio local fizer um login, ele no receber o console, pois j existe
um lock indicando que o console pertence a outro usurio. Quando o usurio do
console fizer logout, o arquivo de lock ser removido e o console novamente ficar
disposio do primeiro usurio (no root) que fizer o login.
Quando um usurio recebe o console, vrias permisses so alteradas no sistema de
arquivos, conforme indicado no arquivo de configurao deste mdulo PAM. Note
que este mdulo est como optional, ou seja, no usado para o sucesso ou no da
autenticao do usurio. Isso necessrio, pois ele pode falhar (um outro usurio j
possui o console, por exemplo).
A seguir, um arquivo de configurao tpico (sem os comentrios maiores):
# file classes -- these are regular expressions
<console>=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9]
<xconsole>=:[0-9]\.[0-9] :[0-9]
# device classes -- these are shell-style globs
<floppy>=/dev/fd[0-1]*
<sound>=/dev/dsp* /dev/audio* /dev/midi* \
/dev/mixer* /dev/sequencer
<cdrom>=/dev/cdrom
<pilot>=/dev/pilot
<jaz>=/dev/jaz
<zip>=/dev/zip
<fb>=/dev/fb /dev/fb[0-9]*
<kbd>=/dev/kbd
<joystick>=/dev/js*
<v4l>=/dev/video* /dev/radio* /dev/winradio* /dev/vtx* /dev/vbi*
# permission definitions
<console> 0660 <floppy>
<console> 0660 <sound>

0660 root.floppy
0660 root.audio

<console>
<console>
<console>
<console>
<console>
<console>
<console>
<console>

0660
0600
0600
0600
0600
0600
0600
0600

<cdrom>
<pilot>
<jaz>
<zip>
<fb>
<kbd>
<joystick>
<v4l>

0660
0660
0660
0660
0600
0600
0600
0600

root.cdrom
root.tty
root.disk
root.disk
root
root
root
root

<xconsole> 0600 /dev/console 0600 root.root

Em primeiro lugar, esta configurao define classes de arquivos e classes de

dispositivos. Por fim, especifica como devem ser as permisses quando o usurio
ganhou o console e quando faz logout. Por exemplo, os dispositivos do tipo floppy
devem ter permisso 0660 com o dono sendo o usurio (o grupo no alterado), e
0660 com donos root.floppy aps o logout do usurio. Este tipo de esquema de
permisses permite, por exemplo, que o usurio formate um disquete sem que seja
necessrio obter direitos de root na mquina.
7.3.1.3. Usando LDAP juntamente com PAM
Aqui mostraremos um exemplo rpido de como modificar o arquivo de
configurao PAM para o programa login passar a suportar LDAP tambm. Note que
isto no suficiente para se ter um sistema completamente dependente do LDAP,
para isso ainda necessrio o mdulo nss_ldap, que nada tem a ver com PAM. O
arquivo modificado fica da seguinte forma:
#%PAM-1.0
auth
required
/lib/security/pam_securetty.so
auth
required
/lib/security/pam_nologin.so
auth
sufficient /lib/security/pam_unix.so shadow nullok md5 \
use_authtok
auth
required
/lib/security/pam_ldap.so use_first_pass
account sufficient /lib/security/pam_unix.so
account required
/lib/security/pam_ldap.so
password required
/lib/security/pam_cracklib.so
password sufficient /lib/security/pam_unix.so nullok use_authtok \
md5 shadow
password required
/lib/security/pam_ldap.so use_first_pass
session optional
/lib/security/pam_console.so
session sufficient /lib/security/pam_unix.so
session required
/lib/security/pam_ldap.so

O mdulo pam_securetty fica inalterado, pois ainda queremos controlar os terminais

por onde o usurio root pode fazer login. Na verdade, o usurio root nem estar no
banco de dados LDAP (usurios de sistema devem sempre ser locais). O mesmo para
o mdulo pam_nologin: permanece inalterado.
A situao fica um pouco diferente quando chegamos nos mdulos que fazem a

autenticao propriamente dita. Por motivos diversos, o mdulo pam_pwdb no deve

ser usado em conjunto com o mdulopam_ldap[1].
OK, temos dois mdulos responsveis pela autenticao, pam_unix e pam_ldap;
como vamos us-los simultaneamente? Lembrem-se, queremos que usurios locais e
remotos possam se autenticar nesta mquina. Vamos usar as flags de controle.
Colocamos em primeiro lugar o mdulo pam_unix. Por qu? Bom, se o usurio for
local, poupamos uma consulta ao servidor LDAP. Mas marcamos este mdulo
como sufficient. Ou seja, se ele for bem-sucedido (= se o usurio for local e a senha
estiver correta) ento nenhum outro mdulo desta classe (auth) ser executado. Se o
resultado no for OK (o usurio s existe no LDAP, ou ento ele errou a senha
mesmo...) ento o prximo mdulo ser tentado.
O mdulo seguinte justamente o pam_ldap. Mas aqui ns o colocamos
como required, ou seja, se ele falhar, a autenticao como um todo falha tambm.
Para no pedir a senha novamente para o usurio, ns aproveitamos a senha j
fornecida antes e usamos o parmetro use_first_pass. Este parmetro diz para o
mdulo pam_ldap para pegar a senha fornecida anteriormente. Se ela estiver
incorreta, o mdulo falha. Se usssemos, por exemplo, o parmetro try_first_pass em
seu lugar, no caso de haver falha o mdulo pam_ldap novamente pediria a senha para
o usurio. O mesmo truque do sufficient e requiredns aplicamos s outras classes:
account, password e session. A classe session possui ainda uma pequena alterao no
posicionamento do mdulo pam_console. Como nada mais executado aps um
mdulo marcado como sufficient ter sido bem-sucedido, o pam_console no seria
chamado se ficasse no fim do arquivo como na configurao original para o programa
login. Assim, ns o colocamos na frente mesmo.
7.3.1.4. Outros mdulos interessantes
Existem diversos mdulos PAM em uma distribuio Linux. Nem todos so usados,
muitos so desconhecidos. Mostraremos aqui alguns dos mais interessantes do ponto
de vista de segurana. Todos estes mdulos esto bem descritos na documentao.
Veja em /usr/share/doc/pam-doc-verso para vrios formatos dessa documentao.
7.3.1.4.1. pam_deny, pam_warn
Estes dois mdulos so teis para se adotar o que chamado de fail-safe. Como j
vimos, cada programa que suporta PAM deve ter seu respectivo arquivo de
configurao no diretrio /etc/pam.d. Se o arquivo no existir, o PAM vai abrir o
arquivo other. interessante que este arquivo esteja da seguinte forma:

# default configuration: /etc/pam.d/other

#
auth
required
/usr/lib/security/pam_warn.so
auth
required
/usr/lib/security/pam_deny.so
account required
/usr/lib/security/pam_deny.so
password required
/usr/lib/security/pam_warn.so
password required
/usr/lib/security/pam_deny.so
session required
/usr/lib/security/pam_deny.so

O mdulo pam_deny simplesmente vai sempre retornar erro. O problema que ele
no faz log disso, e a que entra o pam_warn, cujo nico objetivo colocar uma
mensagem no log do sistema. O log tipicamente como ilustrado abaixo:
jul 19 10:53:51 manticore PAM-warn[8365]: service: su \
[on terminal: <unknown>]
jul 19 10:53:51 manticore PAM-warn[8365]: user: (uid=681) -> root \
[remote: ?nobody@?nowhere]

Para gerar este log, removi o arquivo /etc/pam.d/su e, como usurio comum, tentei
executar o comando su:
[darkangel@manticore darkangel]$ su
su: senha incorreta

Se o arquivo other no tivesse o pam_warn, nada seria registrado nos logs do sistema.
7.3.1.4.2. pam_access
O mdulo pam_access pode ser usado para controlar quais usurios podem fazer
login de qual local (terminal, remoto, domnio, etc.). Alguns servidores, como o
openssh, j possuem um controle parecido embutido, mas tambm podem usufruir
deste mdulo. O arquivo de configurao do
mdulo pam_access /etc/security/access.conf e contm alguns exemplos. A sintaxe
bastante simples. Por exemplo, a linha abaixo permite o login do usurio perigo (ou
de usurios do grupo perigo) apenas a partir dos terminais tty3 e tty4. O resto
(inclusive logins remotos) fica negado:
- : perigo : ALL EXCEPT tty3 tty4

Note que somente alterar o arquivo /etc/security/access.conf no o suficiente, o

mdulo pam_access precisa ser usado! Este mdulo entra na categoria account e
deve ser usado da seguinte forma:
account

required

/lib/security/pam_access.so

Mesmo que o servio esteja explicitamente permitindo o login de um dado usurio,

se pam_access estiver sendo usado e este mesmo usurio estiver bloqueado
no access.conf, o login no ser permitido.

7.3.1.4.3. pam_limits
Este mdulo muito importante quando se tem usurios com shell em um servidor.
Basicamente, ele configura limites para os recursos do sistema disponveis para o
usurio: uso de CPU, memria e outros que veremos a seguir. Note que estes limites
so aplicados por processo, e no por usurio[2]. Este mdulo entra apenas na
categoria session e seu arquivo de configurao, /etc/security/limits.conf, contm
vrios detalhes. As entradas do arquivo de configurao do mdulo pam_limits so da
seguinte forma:
<domnio>

<tipo>

<item>

<valor>

domnio:
Pode ser um nome de usurio, um nome de grupo (usando a sintaxe @grupo) ou
um asterisco (*), indicando qualquer domnio.
tipo:
Pode ter somente dois valores: hard e soft. Limites do tipo hard so aqueles
definidos pelo superusurio e impostos pelo kernel do Linux. O usurio no
pode aumentar estes limites. Por outro lado, limites do tipo soft so aqueles que
o usurio pode alterar, desde que no ultrapasse o que foi definido como um
limite hard. Pode-se pensar neste ltimo tipo de limites como sendo valores
padro para o usurio, ou seja, ele comea com estes valores.
item:
pode ser um dos seguintes:

core: tamanho mximo para arquivos core (KB).

data: tamanho mximo do segmento de dados de um processo na memria

(KB).
fsize: tamanho mximo para arquivos que forem criados.
memlock: tamanho mximo de memria que um processo pode bloquear

na memria fsica (KB).

nofile: quantidade mxima de arquivos abertos de cada vez.
rss: tamanho mximo de memria que um processo pode manter na

memria fsica (KB).

stack: tamanho mximo da pilha (KB).
cpu: tempo mximo de uso de CPU (em minutos).
nproc: quantidade mxima de processos disponveis para um nico

usurio.
as: limite para o espao de endereamento.
maxlogins: quantidade mxima de logins para este usurio.
priority: a prioridade com que os processos deste usurio sero

executados
valor:
Aqui deve ser colocado o valor para o item da coluna anterior.
importante notar que se tivermos limites para um usurio e para o seu grupo, os
limites para o usurio tero preferncia sobre os limites especificados para o seu
grupo. E, mais uma vez, no basta alterar o arquivo de configurao se o mdulo no
for usado. Este um mdulo da categoria session, e deve ser utilizado da seguinte
forma:
session

required

/lib/security/pam_limits.so

O mdulo aceita dois parmetros:

1. debug: aumenta a quantidade de mensagens que vo para o log do sistema;
2. conf=/caminho/para/arquivo.conf : indica um arquivo de configurao

alternativo.
A seguir mostraremos alguns exemplos. Nmero mximo de logins simultneos para
o grupo coitados:
@coitados

maxlogins

Ultrapassando este limite, o usurio receber uma mensagem na tela informando que
excedeu o nmero mximo de logins e o log mostrar:
Jul 19 16:39:52 manticore pam_limits[14659]:Too many logins (max 1) \
for darkangel
Jul 19 16:39:54 manticore login[14659]: Permission denied

Isto vale tambm para logins remotos? Desde que se use PAM, sim. Por exemplo,
vale direto para o telnet, pois ele usa o programa login. Para fazer valer para ssh
tambm basta acrescentar o mdulopam_limits ao /etc/pam.d/sshd.

[darkangel@manticore pam.d]# telnet localhost

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Conectiva Linux 7.0
Kernel 2.4.5-7cl
login: teste
Password:
[teste@manticore teste]$ telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Conectiva Linux 7.0
Kernel 2.4.5-7cl
login: teste
Password:
Too many logins for 'teste'
Permission denied
Connection closed by foreign host.

Nmero mximo de processos para o grupo newton:

@newton

nproc

Exemplo:
manticore login: usuario
Password:
[usuario@manticore newton]$ bash
[usuario@manticore newton]$ bash
[usuario@manticore newton]$ bash
bash: fork: Recurso temporariamente indisponvel
[usuario@manticore newton]$ ls
bash: fork: Recurso temporariamente indisponvel
[usuario@manticore newton]$ exit
[usuario@manticore newton]$ ls
Desktop GNUstep
[usuario@manticore newton]$

Este recurso de se limitar o nmero de processos bastante interessante, pois evita

uma fork bomb se usado em conjunto com os outros parmetros, como tempo
mximo de uso de CPU por processo e com os parmetros relacionados ao uso de
memria e tambm limitando o nmero de logins simultneos.
Note que alguns processos possuem seu prprio controle do uso de recursos, como
sendmail ou mesmo apache, e se recusam a criar mais subprocessos em conseqncia
de certas condies de carga da mquina.
7.3.1.4.4. pam_time
O mdulo pam_time pode ser usado para controlar o acesso a um servio baseado no
horrio e dia da semana. A sintaxe para o uso do mdulo :
account

required

/lib/security/pam_time.so

O seu arquivo de configurao padro /etc/security/time.conf e as entradas so no

formato:
servio;terminal;usurios;horrios

servio: o nome do servio, como, por exemplo, login ou sshd.

terminal: uma lista de terminais.
usurios: lista de usurios. Grupos no so suportados.
horrios: lista de horrios no formato DiaHorrio. Para indicar os dias, deve-se

usar a Tabela 7-2.

Tabela 7-2. Horrios de Restrio de Login
Dia

Valor a ser usado na lista de horrios

Segunda-feira

Mo

Tera-feira

Tu

Quarta-feira

We

Quinta-feira

Th

Sexta-feira

Fr

Sbado

Sa

Domingo

Su

Dias teis

Wk

Fim-de-semana Wd
Todos os dias

Al

Uma "lista" , da forma como pode ser usada aqui, uma seqncia de nomes e
opcionalmente alguns caracteres especiais: ! (negao), * (curinga), & (AND) e
| (OR). Por exemplo, usar !joao&!root na lista de usurios significa que a regra
no se aplica ao usurio root nem ao usurio joao.
Para especificar os horrios, deve-se sempre utilizar o primeiro valor referente
ao dia da semana e logo aps a faixa de horrios, como, por exemplo, Mo18000900 indica apenas a segunda-feira das 18h s 9 horas do dia seguinte

e, Wk0900-1800 indica dias teis (segunda a sexta) das 09 s 18 horas.

Para somente permitir o login no console nos dias teis das 8 at s 18 horas,
mas permitindo o login de root em qualquer horrio, use:
login ; tty* ; !root ; Wk0800-1800

Uma observao importante: o processo de verificao do horrio feito

apenas no incio da sesso. Ou seja, no existe nenhum mecanismo que force a
sada do usurio aps o trmino do horrio permitido de login. Por exemplo,
aproveitando a regra acima, se um usurio se logar s 17h59 e no fizer logout,
ele continuar na mquina mesmo aps s 18 horas. Se ele sair, no entanto, no
conseguir entrar de novo pelo menos at s 8 horas do dia seguinte. Para
contornar este problema pode-se usar a varivel de ambiente TMOUT[3] do
bash. Esta varivel especifica o tempo de inatividade mximo de uma sesso.
Passando esse tempo, o logout forado.