Capítulo 4. Autenticação e controlos de acesso

Aqui estão alguns ficheiros de configuração notáveis acedidos pelo PAM e NSS.

A limitação da seleção da palavra-passe é implementada pelos módulos do PAM, pam_unix(8) e pam_cracklib(8). Eles podem ser configurados com os argumentos deles.

	Dica
	Os módulos PAM utilizam o sufixo ".so" para os nomes de ficheiros deles.

A moderna gestão de sistema centralizada pode ser implantada a utilizar o servidor centralizado Lightweight diretory Access Protocol (LDAP) para administrar muitos sistemas tipo-Unix e não-tipo-Unix na rede. A implementação de código aberto do Lightweight diretory Access Protocol é o Software OpenLDAP.

O servidor LDAP disponibiliza para o sistema Debian a informação de conta através do uso de PAM e NSS com os pacotes libpam-ldap e libnss-ldap. São necessárias várias acções para ativar isto (não utilizei esta configuração e o seguinte é puramente informação secundária. Por favor leia isto neste contexto.).

Veja as documentações em pam_ldap.conf(5) e "/usr/share/doc/libpam-doc/html/" oferecidas pelo pacote libpam-doc e "info libc 'Name Service Switch'" oferecida pelo pacote glibc-doc.

De modo semelhante, pode configurar sistemas centralizados alternativos com outros métodos.

Esta é a famosa frase no fundo da antiga página "info su" por Richard M. Stallman. Não se preocupe, o comando su atual em Debian utiliza PAM, portanto esse pode recadeiair a habilidade de utilizar su ao grupo root ao ativar a linha com "pam_wheel.so" em "/etc/pam.d/su".

# here are the per-package modules (the "Primary" block)
password	requisite			pam_cracklib.so retry=3 minlen=8 difok=3
password	[success=1 default=ignore]	pam_unix.so obscure use_authtok try_first_pass yescrypt
# here's the fallback if no module succeeds
password	requisite			pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password	required			pam_permit.so
# and here are more per-package modules (the "Additional" block)
password	optional	pam_gnome_keyring.so
# end of pam-auth-update config

Muitos serviços de transporte populares comunicam mensagens incluindo a a autenticação de palavra-passe em texto simples. É má ideia transmitir as palavras-passe em texto simples pela Internet onde podem ser interceptadas. Pode correr estes serviços sobre "Transport Layer Security" (TLS) ou o antecessor dele, "Secure Sockets Layer" (SSL) para assegurar toda a comunicação incluindo a palavra-passe pela encriptação.

A encriptação custa tempo de CPU. Como uma alternativa amiga para o CPU, pode manter a comunicação em texto simples enquanto segura apenas a palavra-passe com um protocolo de autenticação de segurança como o "Authenticated Post Office Protocol" (APOP) para POP e "Challenge-Response Authentication Mechanism MD5" (CRAM-MD5) para SMTP e IMAP. (Para enviar mensagens de mail pela Internet para o seu servidor de mail a partir do seu cliente de mail, recentemente é popular utilizar o porto 587 para submissão de novas mensagens em vez do tradicional porto 25 do SMTP para evitar o bloqueio do porto 25 pelo provedor de Internet enquanto se autentica com CRAM-MD5.)

O programa Secure Shell (SSH) disponibiliza comunicações encriptadas e seguras entre duas máquinas sem confiança sobre uma rede insegura com a autenticação de segurança. Consiste no cliente OpenSSH, ssh(1) e no daemon OpenSSH, sshd(8). Este SSH pode ser utilizado como túnel de segurança para protocolos de comunicação inseguros como o POP e X pela Internet com a funcionalidade de reencaminhamento de portos.

O cliente tenta autenticar-se a si próprio a utilizar autenticação baseada na máquina, autenticação de chave pública, autenticação por resposta a desafio, ou autenticação por palavra-passe. O uso de autenticação de chave pública activa o login remoto sem-palavra-passe. Veja Secção 6.3, “O servidor de acesso remoto e utilitários (SSH)”.

Mesmo quando correr serviços seguros como o Secure Shell (SSH) e servidores de Protocolo de túnel ponto-para-ponto (PPTP), ainda existe hipótese de invasões que utilizam ataques de força bruta à palavra-passe, etc. a partir da Internet. A utilização de politicas de firewall (veja Secção 5.7, “Infraestrutura netfilter”) juntamente com as seguinte ferramentas de segurança podem melhorar a situação de segurança.

Para prevenir que pessoas acedam à sua máquina com privilégios de root, precisa de tomar as seguintes acções.

• Prevenir acesso físico ao disco rígido

• Bloquear UEFI/BIOS e impedir o arranque a partir de suportes amovíveis

• Definir palavra-passe para sessão interactiva do GRUB

• Bloquear o menu do GRUB de ser editado

Com acesso físico ao disco rígido, redefinir a palavra-passe é relativamente fácil com os seguintes passos.

1. Mova o disco rígido para um PC com UEFI/BIOS configurável para arranque a partir de CD.

2. Arrancar o sistema com um suporte de recuperação (disco de arranque Debian, CD Knoppix, CD GRUB, ...).

3. Montar a partição raiz com acesso de leitura/escrita.

4. Editar "/etc/passwd" na partição raiz e esvaziar a segunda entrada para a conta root.

Se tiver acesso de edição à entrada do menu do GRUB (veja Secção 3.1.2, “Estágio 2: o gestor de arranque”) grub-rescue-pc no momento do arranque, é ainda mais fácil com os seguintes passos.

A shell de root do sistema está agora acessível sem palavra-passe.

A única solução de software razoável para evitar estas preocupações é usar uma partição raiz encriptada por software (ou uma partição "/etc" a utilizar dm-crypt e initramfs (veja Secção 9.9, “Dicas de encriptação de dados”). Assim, vai necessitar sempre de palavra-passe para arrancar o sistema.

As ACLs são um superconjunto das permissões regulares, conforme explicado em Secção 1.2.3, “Permissões do sistema de ficheiros”.

Encontramos ACLs em ação no ambiente de trabalho moderno. Quando um dispositivo de armazenamento USB formatado é montado automaticamente como, por exemplo, "/media/penguin/USBSTICK", um utilizador normal, o pinguim, pode executá-lo:

 $ cd /media/penguin
 $ ls -la
total 16
drwxr-x---+ 1 root    root    16 Jan 17 22:55 .
drwxr-xr-x  1 root    root    28 Sep 17 19:03 ..
drwxr-xr-x  1 penguin penguin 18 Jan  6 07:05 USBSTICK

"+" na 11ª coluna indica que as ACLs estão em ação. Sem ACLs, um utilizador normal, o pinguim, não deveria ser capaz de fazer uma lista como esta, uma vez que o pinguim não está no grupo de raiz. Você pode ver as ACLs como:

 $ getfacl .
# file: .
# owner: root
# group: root
user::rwx
user:penguin:r-x
group::---
mask::r-x
other::---

Aqui:

Consulte"Listas de Controlo de Acesso POSIX em Linux", acl(5), getfacl(1) e setfacl(1) para mais informações.

O sudo(8) é um programa desenhado para permitir a um administrador de sistema dar privilégios de root limitados a utilizadores e registar a atividade do root. O sudo necessita apenas da palavra-passe de um utilizador normal. Instale o pacote sudo e active-o ao definir opções em "/etc/sudoers". Veja um exemplo de configuração em "/usr/share/doc/sudo/examples/sudoers" e Secção 1.1.12, “Configuração do sudo”.

A minha utilização do sudo para o sistema de único utilizador (veja Secção 1.1.12, “Configuração do sudo”) destina-se a proteger-me da minha própria estupidez. Pessoalmente, Considero utilizar o sudo uma melhor alternativa do que utilizar o sistema a partir da conta de root a toda a hora. Por exemplo, o seguinte muda o dono de "algum_ficheiro" para "meu_nome".

$ sudo chown my_name some_file

Claro que se conhecer a palavra-passe de root (como os utilizadores de sistemas Debian auto-instalados conhecem), qualquer comando pode ser executado sob root a partir da conta de qualquer utilizador a usar "su -c".

PolicyKit é um componente do sistema operativo para controlar privilégios a nível global em sistemas operativos tipo-Unix.

Aplicações GUI mais recentes não são desenhadas para correr como processos privilegiados. Estas falam com os processos privilegiados através de PolicyKit para executar operações administrativas.

O PolicyKit limita tais operações a contas de utilizador pertencentes ao grupo sudo no sistema Debian.

Veja polkit(8).

Para a segurança do sistema, é uma boa ideia desativar o máximo de programas de serviços possíveis. Isto torna-se crítico em servidores na rede. Ter servidores não utilizados, activados directamente como daemon ou via programa super-server, são considerados riscos de segurança.

Muito programas, como o sshd(8), utilizam controlos de acesso baseados no PAM. Existem muitas maneiras de restringir o acesso a alguns serviços de servidor.

Ver Secção 3.5, “Gestão do sistema”, Secção 4.5.1, “Ficheiros de configuração acedidos pelo PAM e NSS”, e Secção 5.7, “Infraestrutura netfilter”.

O kernel do Linux evoluiu e suporta caraterísticas de segurança que não se encontram nas implementações tradicionais do UNIX.

O Linux suporta atributos alargados que estendem os atributos UNIX tradicionais (ver xattr(7)).

O Linux divide os privilégios tradicionalmente associados ao super utilizador em unidades distintas, conhecidas como capacidades(7), que podem ser ativadas e desativadas independentemente. As capacidades são um atributo por sub-processo desde a versão 2.2 do kernel.

A estrutura do Módulo de Segurança do Linux (LSM) fornece um mecanismo para que várias verificações de segurança sejam conectadas por novas extensões do kernel. Por exemplo:

Uma vez que estas extensões podem apertar mais o modelo de privilégios do que as políticas normais do modelo de segurança tipo Unix, até o poder de root pode ser restringido. Aconselha-se a ler o documento da estrutura do Módulo de Segurança Linux (LSM) em kernel.org.

Os namespaces Linux envolvem um recurso global do sistema numa abstração que faz parecer aos processos dentro do namespace que têm a sua própria instância isolada do recurso global. As alterações ao recurso global são visíveis para outros processos que são membros do espaço de nomes, mas são invisíveis para outros processos. Desde a versão 5.6 do kernel, existem 8 tipos de espaços de nomes (veja namespaces(7), unshare(1), nsenter(1)).

A partir da Debian 11 Bullseye (2021), a Debian usa uma hierarquia de cgroups unificada (a.k.a. cgroups-v2).

Exemplos de utilização de namespaces com cgroups para isolar os seus processos e permitir o controlo de recursos:

Estas funcionalidades não podem ser realizadas por Secção 4.1, “Autenticação normal de Unix”. Estes tópicos avançados estão, na sua maioria, fora do âmbito deste documento introdutório.