SISTEMA DE AUTENTICAÇÃO COM O PAMPAM é a parte principal da autenticação em um sistema Linux. PAM significaPluggable Authentication Modules, ou Módulos de Autenticação Plugáveis/Modulares.

Originalmente a autenticação no Linux era apenas via senhas criptografadas armazenadas em um arquivo local chamado /etc/passwd. Um programa como o login pedia o nome do usuário e a senha, criptografava 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 usar isso 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 mudar 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, criptografa melhor, etc. Queremos usar esse novo algoritmo. Claro que teremos que mudar novamente o programa login para que ele suporte este novo algoritmo também. No Linux, muitos programas utilizam algum tipo de autenticação de usuários. Imagine se todos eles tivessem que ser reescritos cada vez que se mudasse algum dos critérios de autenticação.

Para resolver este tipo de problema, a Sun® criou o PAM há alguns anos e liberou as especificações em forma de RFC. O Linux derivou sua implementação 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 então, o aplicativo delega a responsabilidade da autenticação para o PAM e não 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 módulo PAM seja modificado para que todos os aplicativos automaticamente e de forma transparente passem a usufruir desta nova forma de autenticação. PAM possui uma outra vantagem: é possível configurar a autenticação de forma individual para cada aplicativo. Com isto é possível fazer com que, por exemplo, um usuário comum possa usar os dispositivos de áudio do computador desde que tenha se logado na máquina através do console. Se o login não 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 máquina? É claro que não. Eles não precisam. Os módulos PAM se encarregam disso.

Na verdade, PAM vai um pouco além da autenticação. Os módulos podem ser divididos em quatro tipos:

auth:

É a parte que verifica que o usuário é realmente quem ele diz que é. Pode ser bem simples, pedindo apenas por um nome e uma senha, ou utilizando autenticação biométrica, por exemplo (como uma impressão de voz, uma imagem da retina ou impressão digital).

account:

Esta parte verifica se o usuário em questão está autorizado a utilizar este serviço ao qual ele 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. Por exemplo, aqui podem ser colocados módulos que verificam se a senha é forte ou fraca.

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 módulo pam_pwdb, por exemplo, pode ser usado nestes quatro tipos e possui ações diferentes em cada uma das situações, enquanto quepam_console é normalmente usado apenas como session.

7.3.1.1. Instalação

Os módulos PAM já vêm instalados por padrão 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 autenticação suportam PAM. Na verdade, não funcionam sem PAM. Toda a configuração está localizada no diretório /etc/pam.d. Quando um aplicativo suporta PAM, ele necessita

de um arquivo de configuração neste diretório. A Figura 7-1 ilustra como funciona a autenticação com PAM usando o programa login como exemplo:

Figura 7-1. Autenticação com PAM

Um programa com suporte a PAM possui duas interfaces com a biblioteca: a de autenticação e a de conversação. A interface de autenticação é por onde a aplicação pede que o PAM valide o usuário. A de conversação é usada pelos módulos que, por exemplo, precisem 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. A conversação está ilustrada na figura no módulo pam_pwdb (b).

A biblioteca PAM vai procurar o arquivo de configuração da aplicação login. Este arquivo é /etc/pam.d/login e vai dizer quais módulos devem ser usados e com que parâmetros. Este arquivo está reproduzido a seguir:

#%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

Este arquivo de configuração lista os módulos PAM que este programa (login) deve usar, e eles estão representados na figura através de letras. Estes módulos serão carregados e executados na ordem em que estiverem no arquivo de configuração. Note que um módulo pode aproveitar uma informação de um módulo anterior, como normalmente é feito para username/senha. Isso é usado para não pedir a mesma informação novamente 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 isto não é obrigatório. Se um programa não tiver suporte à troca de senha, o tipo "password" não é usado.

A segunda coluna define a flag de controle para o seu respectivo módulo. O resultado de cada módulo pode influenciar de diversas formas o resultado do processo de autenticação geral. Há 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 os outros módulos não são executados e o controle volta imediatamente para o aplicativo em caso de falha.

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.

optional:

Os módulos marcados como optional praticamente não influenciam o resultado da autenticação como um todo. Eles apenas terão alguma influência 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/doc/pam-versão. Vamos aqui apenas ilustrar como funcionam os usados no programa login.

Em primeiro lugar, observamos que todos os módulos são required, ou seja, não podem falhar. Com exceção do pam_console.

7.3.1.2.1. pam_securetty

Este é o primeiro módulo a ser usado e ele simplesmente verifica o terminal de onde o login está ocorrendo. Este módulo não usa parâmetros, mas possui um arquivo de configuração: /etc/securetty. Neste arquivo listamos os terminais a partir dos quais o usuário root pode fazer login. Ou seja, são os terminais considerados seguros. Apesar do nome terminais, conexões remotas também são controladas por aqui, pois elas alocam pseudoterminais (telnet, etc). O módulo retorna sucesso para qualquer usuário diferente de root e, se for root, somente se o terminal de onde está vindo o login estiver listado no arquivo/etc/securetty. Na série 2.2.x do kernel, os pseudoterminais são 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 conexão telnet ganhou o pseudoterminal pts/0. Já a segunda teve o pts/1 alocada para si, e este pseudoterminal não estava listado no arquivo /etc/securetty. Portanto, o acesso não foi autorizado. Por que isto não funciona com ssh, por exemplo? Se olharmos o arquivo de configuração PAM para o ssh, veremos que o módulo pam_securetty não está presente ali. SSH possui seu próprio mecanismo de acesso para o usuário root, mas nada impede que pam_securetty seja acrescentado no arquivo PAM. O módulo pam_securetty também pode ser usado para controlar o login a partir do ambiente gráfico, por exemplo. Basta acrescentar o módulo ao arquivo /etc/pam.d/kde (se o kdm estiver sendo usado para login gráfico). A linha a ser acrescentada ao arquivo /etc/securetty (além 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 módulo é o de evitar o login do root em terminais inseguros. Este conceito de terminais foi estendido ao login remoto (através dos pseudoterminais).

7.3.1.2.2. pam_pwdb

O módulo pam_pwdb é o módulo principal da autenticação do programa login. Ele vai pedir um nome de usuário e uma senha e verificar se estão corretos. Como tal, o módulo utiliza a função de conversação para interrogar o usuário e pegar as informações desejadas.

Este módulo aceita alguns parâmetros, 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 usuário não conseguirá fazer login se não existir nullok na linha auth para este módulo.

md5: usa criptografia (hash) md5 em vez do crypt padrão. Pode ser usado na linha password.

use_authtok: indica que o módulo deve usar a autenticação já fornecida para os módulos anteriores, de forma a não interrogar o usuário novamente. Alguns outros módulos suportam o parâmetrouse_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 usuário. O use_first_pass não faz esse novo pedido caso ocorra uma falha.

O try_first_pass será usado mais adiante quando mostrarmos a autenticação via LDAP. Este módulo também possui seu próprio arquivo de configuração: /etc/pwdb.conf. Não entraremos em detalhes quanto à sintaxe deste arquivo, pois o módulo pam_pwdb não é muito extensível. Na verdade, o pam_unix é bem mais genérico por usar as funções da glibc e, portanto, suporta NIS, LDAP, arquivos texto, arquivos binários e qualquer outra coisa que a glibc vier a suportar (através de NSS). No caso de uso com a classe session, o módulo pam_pwdb apenas faz o log do usuário que entrou no sistema. Sendo usado com a classe account, o módulo vai verificar se a senha do usuário expirou, há quanto tempo a senha não é trocada, etc.

7.3.1.2.3. pam_nologin

O módulo pam_nologin é bastante simples, e muito útil. É uma forma rápida de desabilitar o login de qualquer usuário que não seja o root. Para isto, basta criar o arquivo /etc/nologin. Existindo este arquivo, o módulo pam_nologin vai sempre retornar ERRO para usuários diferentes de root e exibir o conteúdo de /etc/nologin (onde se deve colocar o motivo da proibição), ou seja, só o usuário root consegue se logar na máquina. Quando o arquivo for removido, a operação voltará ao normal, com usuários comuns podendo se logar novamente. Isto pode ser útil quando se quer fazer alguma manutenção no sistema, por exemplo, situação em que logins de usuários são indesejáveis. Alguns aplicativos do próprio Linux também podem criar este arquivo e depois removê-lo quando alguma operação crítica for concluída.

Note que os usuários que já estiverem logados na máquina não são afetados pela criação ou remoção do arquivo /etc/nologin.

7.3.1.2.4. pam_cracklib

Este módulo é especialmente importante para a segurança pró-ativa. Colocado apenas na classe password, o módulo vai verificar a senha do usuário antes que ela seja trocada. Se for uma senha considerada fraca, ela será rejeitada e o usuário não conseguirá trocar a senha. As verificações que o módulo faz atualmente são:

palíndromo: a nova senha é um palíndromo?

caixa: a senha nova é a antiga com apenas mudanças de maiúsculas / minúsculas?

similar: a nova senha é muito similar à antiga? Esta verificação pode ser controlada por um parâmetro que indica o número mínimo de caracteres diferentes que a senha nova deve ter em relação à senha antiga. O valor padrão é 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 usuário, o módulo pam_cracklib vai também verificar se a senha nova já não foi usada anteriormente. Esse arquivo de senhas antigas é atualmente gerado apenas pelo módulo pam_unix, embora exista uma discussão para se criar um módulo específico para esta tarefa (algo como pam_saveoldpass) e remover esta funcionalidade do módulo pam_unix.

Os parâmetros normalmente utilizados com o módulo cracklib são:

retry=N

"N" é o número de tentativas que o usuário poderá fazer para fornecer uma senha considerada boa.

difok=N

"N" é o número de letras diferentes que a senha nova deve ter em relação à senha antiga. Este parâmetro controla o comportamento da checagem do tipo "similar", vista há pouco. O valor padrão é 10 (e este é o valor alterado por "N" ou metade do tamanho da senha atual), aquele que for o menor.

minlen=N

Tamanho mínimo da nova senha mais um. Além de contar a quantidade de caracteres da senha nova, créditos também podem ser fornecidos com base na quantidade de algarismos, caracteres maiúsculos/minúsculos e símbolos. Ou seja, se o valor de minlen for 10, o usuário pode usar uma senha com menos do que 10 caracteres, desde que, somando a quantidade de caracteres mais os créditos, o valor final ultrapasse 10. Por exemplo:

password required /lib/security/pam_cracklib.so retry=3 minlen=10

Especificamos um tamanho mínimo de 9 para a senha nova. Portanto, uma senha igual a senharuim vai funcionar (possui nove caracteres). Mas uma senha igual a am0Bb$ também funcionará, apesar de possuir apenas 6 caracteres. Como? Por causa dos créditos. am0Bb$=>6+1(B, maiúscula)+1(0, dígito)+1($, símbolo)= 9=>OK, passará.

Por outro lado: am0Bbd => 6 + 1(B, maiúscula) + 1(0, dígito) = 8 => não passará.

Por padrão, cada um dos tipos de variação da senha (minúsculo, maiúsculo, algarismo e símbolo) conta no máximo um crédito. Ou seja: am0b9$ => 6 + 1(0, dígito) + 1 ($, símbolo) = 8 => não passa

Note que o uso de dois algarismos não ajudou em termos de créditos. Mas isto pode ser mudado se passarmos um outro parâmetro para o módulo: password required /lib/security/pam_cracklib.so retry=3 \ minlen=10 dcredit=2

Através do parâmetro dcredit estamos dizendo que toleraremos no máximo dois créditos provenientes de algarismos na senha. Com esta alteração, a senha am0b9$ passará como válida pois usa dois algarismos e então atingirá o mínimo de 9 exigido por esta configuração do módulo. Estes parâmetros de créditos também existem para as outras variantes: 

dcredit: número máximo de créditos fornecidos provenientes do uso de algarismos na senha. O valor padrão é 1.

ucredit: número máximo de créditos fornecidos provenientes do uso de letras maiúsculas na senha. O valor padrão é 1.

lcredit: número máximo de créditos fornecidos provenientes do uso de letras minúsculas na senha. O valor padrão é 1.

ocredit: número máximo de créditos fornecidos provenientes do uso de outros caracteres (símbolos) na senha. O valor padrão é 1.

7.3.1.2.5. pam_console

O objetivo do módulo pam_console é permitir ao usuário local (ou seja, no console, fisicamente na máquina) o acesso a diversos dispositivos normalmente restritos ao superusuário, como placa de som, dispositivo de disquete e também permitir ao

usuário comum (local) executar certas tarefas, como desligar o computador, entrar no ambiente gráfico ou mesmo instalar pacotes RPM.

Essa capacidade adicional é fornecida ao usuário no seu primeiro login e removida após o último logout, e se dá através da modificação das permissões de alguns dispositivos e também através de autenticação.

Diz-se que o primeiro usuário que fizer login no console "ganha" o console e as permissões definidas no arquivo de configuração /etc/security/console.perms. Quando um usuário possui o console, um arquivo de lock é criado em /var/lock com o nome console.lock. O conteúdo do arquivo é o nome do usuário que possui o console. Se um outro usuário local fizer um login, ele não receberá o console, pois já existe um lock indicando que o console pertence a outro usuário. Quando o usuário do console fizer logout, o arquivo de lock será removido e o console novamente ficará à disposição do primeiro usuário (não root) que fizer o login.

Quando um usuário recebe o console, várias permissões são alteradas no sistema de arquivos, conforme indicado no arquivo de configuração deste módulo PAM. Note que este módulo está como optional, ou seja, não é usado para o sucesso ou não da autenticação do usuário. Isso é necessário, pois ele pode falhar (um outro usuário já possui o console, por exemplo).

A seguir, um arquivo de configuração típico (sem os comentários 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> 0660 root.floppy <console> 0660 <sound> 0660 root.audio <console> 0660 <cdrom> 0660 root.cdrom <console> 0600 <pilot> 0660 root.tty <console> 0600 <jaz> 0660 root.disk <console> 0600 <zip> 0660 root.disk <console> 0600 <fb> 0600 root <console> 0600 <kbd> 0600 root <console> 0600 <joystick> 0600 root

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

Em primeiro lugar, esta configuração define classes de arquivos e classes de dispositivos. Por fim, especifica como devem ser as permissões quando o usuário ganhou o console e quando faz logout. Por exemplo, os dispositivos do tipo floppy devem ter permissão 0660 com o dono sendo o usuário (o grupo não é alterado), e 0660 com donos root.floppy após o logout do usuário. Este tipo de esquema de permissões permite, por exemplo, que o usuário formate um disquete sem que seja necessário obter direitos de root na máquina.

7.3.1.3. Usando LDAP juntamente com PAM

Aqui mostraremos um exemplo rápido de como modificar o arquivo de configuração PAM para o programa login passar a suportar LDAP também. Note que isto não é suficiente para se ter um sistema completamente dependente do LDAP, para isso ainda é necessário o módulo 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 módulo pam_securetty fica inalterado, pois ainda queremos controlar os terminais por onde o usuário root pode fazer login. Na verdade, o usuário root nem estará no banco de dados LDAP (usuários de sistema devem sempre ser locais). O mesmo para o módulo pam_nologin: permanece inalterado.

A situação fica um pouco diferente quando chegamos nos módulos que fazem a autenticação propriamente dita. Por motivos diversos, o módulo pam_pwdb não deve ser usado em conjunto com o módulopam_ldap[1].

OK, temos dois módulos responsáveis pela autenticação, pam_unix e pam_ldap; como vamos usá-los simultaneamente? Lembrem-se, queremos que usuários locais e

remotos possam se autenticar nesta máquina. Vamos usar as flags de controle. Colocamos em primeiro lugar o módulo pam_unix. Por quê? Bom, se o usuário for local, poupamos uma consulta ao servidor LDAP. Mas marcamos este módulo como sufficient. Ou seja, se ele for bem-sucedido (= se o usuário for local e a senha estiver correta) então nenhum outro módulo desta classe (auth) será executado. Se o resultado não for OK (o usuário só existe no LDAP, ou então ele errou a senha mesmo...) então o próximo módulo será tentado.

O módulo seguinte é justamente o pam_ldap. Mas aqui nós o colocamos como required, ou seja, se ele falhar, a autenticação como um todo falha também. Para não pedir a senha novamente para o usuário, nós aproveitamos a senha já fornecida antes e usamos o parâmetro use_first_pass. Este parâmetro diz para o módulo pam_ldap para pegar a senha fornecida anteriormente. Se ela estiver incorreta, o módulo falha. Se usássemos, por exemplo, o parâmetro try_first_pass em seu lugar, no caso de haver falha o módulo pam_ldap novamente pediria a senha para o usuário. O mesmo truque do sufficient e requirednós aplicamos às outras classes: account, password e session. A classe session possui ainda uma pequena alteração no posicionamento do módulo pam_console. Como nada mais é executado após um módulo marcado como sufficient ter sido bem-sucedido, o pam_console não seria chamado se ficasse no fim do arquivo como na configuração original para o programa login. Assim, nós o colocamos na frente mesmo.

7.3.1.4. Outros módulos interessantes

Existem diversos módulos PAM em uma distribuição Linux. Nem todos são usados, muitos são desconhecidos. Mostraremos aqui alguns dos mais interessantes do ponto de vista de segurança. Todos estes módulos estão bem descritos na documentação. Veja em /usr/share/doc/pam-doc-versão para vários formatos dessa documentação.

7.3.1.4.1. pam_deny, pam_warn

Estes dois módulos são úteis para se adotar o que é chamado de fail-safe. Como já vimos, cada programa que suporta PAM deve ter seu respectivo arquivo de configuração no diretório /etc/pam.d. Se o arquivo não 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 módulo pam_deny simplesmente vai sempre retornar erro. O problema é que ele não 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 usuário comum, tentei executar o comando su:

[darkangel@manticore darkangel]$ su su: senha incorreta

Se o arquivo other não tivesse o pam_warn, nada seria registrado nos logs do sistema.

7.3.1.4.2. pam_access

O módulo pam_access pode ser usado para controlar quais usuários podem fazer login de qual local (terminal, remoto, domínio, etc.). Alguns servidores, como o openssh, já possuem um controle parecido embutido, mas também podem usufruir deste módulo. O arquivo de configuração do módulo pam_access é /etc/security/access.conf e contém alguns exemplos. A sintaxe é bastante simples. Por exemplo, a linha abaixo permite o login do usuário perigo (ou de usuários 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 não é o suficiente, o módulo pam_access precisa ser usado! Este módulo entra na categoria account e deve ser usado da seguinte forma:

account required /lib/security/pam_access.so

Mesmo que o serviço esteja explicitamente permitindo o login de um dado usuário, se pam_access estiver sendo usado e este mesmo usuário estiver bloqueado no access.conf, o login não será permitido. 

7.3.1.4.3. pam_limits

Este módulo é muito importante quando se tem usuários com shell em um servidor. Basicamente, ele configura limites para os recursos do sistema disponíveis para o usuário: uso de CPU, memória e outros que veremos a seguir. Note que estes limites são aplicados por processo, e não por usuário[2]. Este módulo entra apenas na categoria session e seu arquivo de configuração, /etc/security/limits.conf, contém

vários detalhes. As entradas do arquivo de configuração do módulo pam_limits são da seguinte forma:

<domínio> <tipo> <item> <valor>

domínio:

Pode ser um nome de usuário, um nome de grupo (usando a sintaxe @grupo) ou um asterisco (*), indicando qualquer domínio.

tipo:

Pode ter somente dois valores: hard e soft. Limites do tipo hard são aqueles definidos pelo superusuário e impostos pelo kernel do Linux. O usuário não pode aumentar estes limites. Por outro lado, limites do tipo soft são aqueles que o usuário pode alterar, desde que não ultrapasse o que foi definido como um limite hard. Pode-se pensar neste último tipo de limites como sendo valores padrão para o usuário, ou seja, ele começa com estes valores.

item:

pode ser um dos seguintes:

core: tamanho máximo para arquivos core (KB).

data: tamanho máximo do segmento de dados de um processo na memória (KB).

fsize: tamanho máximo para arquivos que forem criados.

memlock: tamanho máximo de memória que um processo pode bloquear na memória física (KB).

nofile: quantidade máxima de arquivos abertos de cada vez.

rss: tamanho máximo de memória que um processo pode manter na memória física (KB).

stack: tamanho máximo da pilha (KB).

cpu: tempo máximo de uso de CPU (em minutos).

nproc: quantidade máxima de processos disponíveis para um único usuário.

as: limite para o espaço de endereçamento.

maxlogins: quantidade máxima de logins para este usuário.

priority: a prioridade com que os processos deste usuário serão executados

valor:

Aqui deve ser colocado o valor para o item da coluna anterior.

É importante notar que se tivermos limites para um usuário e para o seu grupo, os limites para o usuário terão preferência sobre os limites especificados para o seu grupo. E, mais uma vez, não basta alterar o arquivo de configuração se o módulo não for usado. Este é um módulo da categoria session, e deve ser utilizado da seguinte forma:

session required /lib/security/pam_limits.so

O módulo aceita dois parâmetros: 

1. debug: aumenta a quantidade de mensagens que vão para o log do sistema;

2. conf=/caminho/para/arquivo.conf : indica um arquivo de configuração alternativo.

A seguir mostraremos alguns exemplos. Número máximo de logins simultâneos para o grupo coitados:

@coitados - maxlogins 1

Ultrapassando este limite, o usuário receberá uma mensagem na tela informando que excedeu o número máximo 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 também 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 também basta acrescentar o módulopam_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.

Número máximo de processos para o grupo newton: @newton - nproc 3

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

Este recurso de se limitar o número de processos é bastante interessante, pois evita uma fork bomb se usado em conjunto com os outros parâmetros, como tempo máximo de uso de CPU por processo e com os parâmetros relacionados ao uso de memória e também limitando o número de logins simultâneos. 

Note que alguns processos possuem seu próprio controle do uso de recursos, como sendmail ou mesmo apache, e se recusam a criar mais subprocessos em conseqüência de certas condições de carga da máquina.

7.3.1.4.4. pam_time

O módulo pam_time pode ser usado para controlar o acesso a um serviço baseado no horário e dia da semana. A sintaxe para o uso do módulo é:

account required /lib/security/pam_time.so

O seu arquivo de configuração padrão é /etc/security/time.conf e as entradas são no formato: serviço;terminal;usuários;horários

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

terminal: uma lista de terminais.

usuários: lista de usuários. Grupos não são suportados.

horários: lista de horários no formato DiaHorário. Para indicar os dias, deve-se usar a Tabela 7-2.

Tabela 7-2. Horários de Restrição de Login

Dia Valor a ser usado na lista de horários

Segunda-feira Mo

Terça-feira Tu

Quarta-feira We

Quinta-feira Th

Sexta-feira Fr

Sábado Sa

Domingo Su

Dias úteis Wk

Fim-de-semana Wd

Todos os dias Al

Uma "lista" , da forma como pode ser usada aqui, é uma seqüência de nomes e opcionalmente alguns caracteres especiais: ! (negação), * (curinga), & (AND) e | (OR). Por exemplo, usar !joao&!root na lista de usuários significa que a regra não se aplica ao usuário root nem ao usuário joao.

Para especificar os horários, deve-se sempre utilizar o primeiro valor referente ao dia da semana e logo após a faixa de horários, como, por exemplo, Mo1800-0900 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 horário, use:

login ; tty* ; !root ; Wk0800-1800

Uma observação importante: o processo de verificação do horário é feito apenas no início da sessão. Ou seja, não existe nenhum mecanismo que force a

saída do usuário após o término do horário permitido de login. Por exemplo, aproveitando a regra acima, se um usuário se logar às 17h59 e não fizer logout, ele continuará na máquina mesmo após às 18 horas. Se ele sair, no entanto, não conseguirá entrar de novo pelo menos até às 8 horas do dia seguinte. Para contornar este problema pode-se usar a variável de ambiente TMOUT[3] do bash. Esta variável especifica o tempo de inatividade máximo de uma sessão. Passando esse tempo, o logout é forçado.