Capitolo 4. Autenticazione e controllo degli accessi

Quelli che seguono sono alcuni file degni di nota letti da PAM e NSS.

Le restrizioni sulla scelta delle password sono implementate dai moduli PAM pam_unix(8) e pam_cracklib(8). Possono essere configurati tramite i loro argomenti.

	Suggerimento
	I moduli PAM usano il suffisso ".so" nei loro nomi file.

La moderna gestione centralizzata del sistema può essere messa in atto usando il server del Protocollo LDAP (Lightweight Directory Access Protocol) per amministrare molti sistemi *nix e non *nix in rete. L'implementazione open source del protocollo LDAP è il software OpenLDAP.

Il server LDAP fornisce le informazioni sugli account attraverso l'uso di PAM e NSS con i pacchetti per il sistema Debian libpam-ldap e libnss-ldap. Per abilitare ciò sono necessarie diverse azioni. (Non ho mai usato questa configurazione e le informazioni che seguono sono di seconda mano. Tenerlo a mente quando si legge quanto segue.)

Vedere la documentazione in pam_ldap.conf(5) e "/usr/share/doc/libpam-doc/html/" fornita dal pacchetto libpam-doc e in "info libc 'Name Service Switch'" fornita dal pacchetto glibc-doc.

In modo simile si possono impostare sistemi centralizzati alternativi con altri metodi.

Questa è la famosa sezione scritta da Richard M. Stallman, alla fine della vecchia pagina "info su. Non c'è da preoccuparsi: l'attuale comando su in Debian usa PAM, perciò questo può limitare la possibilità di usare su verso il gruppo root abilitando la riga con "pam_wheel.so" in "/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

Molti servizi per livello di trasporto popolari comunicano i loro messaggi, compresa l'autenticazione con password, in puro testo. È una pessima idea trasmettere password in puro testo attraverso l'Internet selvaggia dove possono essere intercettate. Si possono eseguire questi servizi attraverso "TLS" (Transport Layer Security, sicurezza del livello di trasporto), o il suo predecessore "SSL" (Secure Sockets Layer, livello per socket sicuri), per rendere sicura tramite cifratura tutta la comunicazione, compresa la password.

La cifratura ha un costo in termini di tempo CPU. Come alternativa leggera per la CPU, si può mantenere la comunicazione in testo semplice, rendendo allo stesso tempo sicura la sola password con un protocollo di autenticazione sicura come "APOP" (Authenticated Post Office Protocol) per POP e "CRAMD-MD5" (Challenge-Response Authentication Mechanism MD5) per SMTP e IMAP. (Per inviare messaggi di posta elettronica via Internet dal proprio programma di posta al proprio server di posta è diventato popolare recentemente l'uso per SMTP della porta 587 invece della porta tradizionale 25, per evitare il blocco da parte del fornitore del servizio Internet della porta 25 autenticandosi allo stesso tempo con CRAM-MD5.)

Il programma Secure Shell (SSH fornisce comunicazioni sicure cifrate tra due host non fidati attraverso una rete non sicura, grazie ad un'autenticazione sicura. Consiste del client OpenSSH, ssh(1) e del demone OpenSSH, sshd(8). SSH può essere usato per fare da tunnel sicuro attraverso Internet per le comunicazioni con protocollo non sicuro come POP ed X, con la funzionalità di inoltro delle porte.

Il client cerca di autenticarsi usando un'autenticazione basata sull'host, su una chiave pubblica, challenge-response o con password. L'uso di un'autenticazione con chiave pubblica permette il login remoto senza password. Vedere Sezione 6.3, «Il server e le utilità per l'accesso remoto (SSH)».

Anche quando si eseguono servizi sicuri, come server SSH (Secure shell) e PPTP (Point-to-Point Tunneling Protocol), esiste sempre la possibilità di un'intrusione da Internet con attacchi basati sull'indovinare la password usando metodi con forza bruta, ecc. L'uso di una politica di firewall (vedere Sezione 5.6, «Infrastruttura netfilter») insieme agli strumenti di sicurezza elencati in seguito, può migliorare la sicurezza generale.

Per impedire che qualcuno possa accedere alla propria macchina con privilegi di root, è necessario compiere le azioni seguenti.

• Impedire l'accesso fisico al disco fisso

• Bloccare UEFI/BIOS ed impedire l'avvio da supporti removibili

• Impostare una password per la sessione interattiva di GRUB

• Bloccare il menu di GRUB impedendo i cambiamenti

Avendo accesso fisico al disco fisso, reimpostare la password di root è relativamente semplice seguendo i passi seguenti.

1. Spostare il disco fisso in un PC con UEFI/BIOS che permette l'avvio da CD.

2. Avviare il sistema con un supporto di ripristino (disco di avvio di Debian, CD Knoppix, CD GRUB, …).

3. Montare la partizione root con accesso in lettura e scrittura

4. Modificare il file "/etc/passwd" nella partizione root e rendere la seconda voce per l'account di root vuota.

Se si ha l'accesso in modifica alle voci di menu di GRUB (vedere Sezione 3.1.2, «Stadio 2: il bootloader») per grub-rescue-pc all'avvio, è ancora più semplice, seguendo i passi seguenti.

Si può ora accedere alla shell di root del sistema senza password.

L'unica soluzione software ragionevole per evitare tutte queste preoccupazioni è l'uso di una partizione root (o partizione "/etc") cifrata, usando dm-crypt e initramfs (vedere Sezione 9.9, «Suggerimenti per la cifratura dei dati»). Tuttavia è sempre necessaria la password per avviare il sistema.

sudo(8) è un programma progettato per permettere ad un amministratore di sistema di dare privilegi di root limitati ad utenti, e di registrare l'attività come root. sudo richiede solo la password di un utente regolare. Installare il pacchetto sudo e attivarlo impostando le opzioni in "/etc/sudoers". Vedere esempi di configurazione in "/usr/share/doc/sudo/examples/sudoers" e Sezione 1.1.12, «Configurazione di sudo».

Il mio uso di sudo per un sistema con un singolo utente (vedere Sezione 1.1.12, «Configurazione di sudo») è mirato a proteggere me stesso dalla mia stupidità. Personalmente condidero l'uso di sudo come un'alternativa migliore all'uso costante del sistema dall'account root. Per esempio, il comando seguente cambia il proprietario di "un_certo_file" in "mio_nome".

$ sudo chown my_name some_file

Naturalmente se si conosce la password di root (come accade per ogni utente Debian che ha installato il proprio sistema), qualsiasi comando può essere eseguito come utente root da qualsiasi account utente usando "su -c".

PolicyKit è un componente del sistema operativo per controllare privilegi a livello di sistema in sistemi operativi simil-Unix.

Le applicazioni GUI più recenti non sono pensate per essere eseguite come processi privilegiati. Per effettuare operazioni amministrative comunicano con processi privilegiati attraverso PolicyKit.

PolicyKit limita tali operazioni agli account utente che appartengono al gruppo sudo, in sistemi Debian.

Vedere polkit(8).

Per la sicurezza del sistema è una buona idea disabilitare il maggior numero di programmi server possibile. Questo aspetto diventa critico per i server di rete. Avere server inutilizzati, attivati direttamente come demoni o attraverso un programma super-server, è considerato un rischio per la sicurezza.

Molti programmi, come sshd(8), usano un controllo degli accessi basato su PAM. Ci sono molti modi per limitare gli accessi ad un qualche servizio server.

Vedere Sezione 3.5, «Gestione del sistema», Sezione 4.5.1, «File di configurazione letti da PAM e NSS» e Sezione 5.6, «Infrastruttura netfilter».

Il kernel Linux si è evoluto e gestisce funzionalità di sicurezza che non sono presenti nelle implementazioni UNIX tradizionali.

Linux gestisce gli attributi estesi che estendono gli attributi UNIX tradizionali (vedere xattr(7)).

Linux divide i privilegi tradizionalmente associati con il superutente in unità distinte, note come capabilities(7), che possono essere abilitate e disabilitate in modo indipendente. Le capabilities sono un attributo per singolo thread a partire dalla versione 2.2 del kernel.

L'infrastruttura Linux Security Module (LSM) fornisce un meccanismo per vari controlli di sicurezza in modo che nuove estensioni del kernel si aggancino ad essi. Per esempio:

Dato che queste estensioni possono restringere il modello dei privilegi in modo più stringente delle politiche del normale modello di sicurezza in stile Unix, anche i poteri di root possono essere ristretti. È consigliato leggere la documentazione dell'infrastruttura Linux Security Module (LSM) su kernel.org.

Gli spazi dei nomi Linux creano un involucro (wrap) per una risorsa di sistema globale come astrazione che fa sembrare ai processi all'interno dello spazio dei nomi di avere una propria istanza isolata della risorsa globale. Le modifiche alla risorsa globale sono visibile agli altri processi che sono membri dello spazio dei nomi, ma sono invisibili agli altri processi. A partire dalla versione 5.6 del kernel, ci sono 8 tipi di spazi dei nomi (vedere namespaces(7), unshare(1), nsenter(1)).

In Debian 11 Bullseye (2021) Debian usa la gerarchia cgroup unificata (alias cgroups-v2).

Esempi di uso di spazi dei nomi con cgroups per isolare i loro processi e permettere il controllo delle risorse sono:

Queste funzionalità non possono essere realizzate con. Questi argomenti avanzati sono per lo più al di fuori di questo documento introduttivo.