[go: up one dir, main page]
Vai al contenuto

Security-Enhanced Linux

Da Wikipedia, l'enciclopedia libera.
SELinux
software
Logo
Logo
SELinux GUI amministratore in Fedora 8
SELinux GUI amministratore in Fedora 8
SELinux GUI amministratore in Fedora 8
GenereSicurezza informatica
SviluppatoreNSA e Red Hat
Data prima versione1º gennaio 1998
Ultima versione2.8 (24 maggio 2018)
Sistema operativoLinux
LinguaggioC
LicenzaGNU GPL
(licenza libera)
Sito webselinuxproject.org/
Modifica dati su Wikidata · Manuale

In informatica, il Security-Enhanced Linux (SELinux) è un modulo di sicurezza del kernel Linux che fornisce un insieme di strumenti per utilizzare e monitorare il controllo degli accessi incluso il mandatory access control (MAC), tutto questo utilizzando i framework Linux Security Modules (LSM).

SELinux è un set di modifiche che possono essere applicate a sistemi operativi di tipo Unix come Linux e BSD. La sua architettura cerca di separare l'uso delle regole di sicurezza dalla definizione delle regole stesse, riducendo il numero di software incaricati a verificare che queste vengano rispettate. I concetti base di SELinux possono essere ricondotti ad alcuni progetti della National Security Agency (NSA) statunitense.

Storia

[modifica | modifica wikitesto]

Il primo lavoro rivolto a standardizzare i controlli di accesso obbligatori e discrezionali (MAC e DAC) all'interno di un ambiente UNIX (più precisamente POSIX) può essere attribuito al gruppo di lavoro Trusted UNIX (TRUSIX) dell'agenzia di sicurezza nazionale americana (NSA) che dal 1987 al 1991 ha prodotto un modello formale (pubblicato in un Rainbow Book) ed un prototipo di valutazione che però non è mai stato pubblicato.

SELinux è stato progettato per dimostrare il valore dei controlli di accesso obbligatori alla comunità linux e come tali controlli potrebbero essere aggiunti a Linux. Originariamente, le patch che sono state integrate in SELinux dovevano essere esplicitamente applicate al codice sorgente del kernel linux, dalla versione 2.6 del kernel invece è stato completamente integrato di default.

Il primo sviluppatore di SELinux, ha rilasciato la prima versione alla comunità di sviluppo open source sotto la GNU GPL il 22 dicembre 2000.[1] Il software si è unito al main kernel Linux 2.6.0-test3, rilasciato l'8 agosto 2003.

Security-Enhanced Linux implementa il Flux Advanced Security Kernel (FLASK). Questo kernel contiene componenti architetturali progettati per il sistema operativo Fluke. I componenti di Fluke forniscono un ampio supporto per l'applicazione di molti tipi di politiche per il controllo degli accessi obbligatorie, incluse quelle basate su esecuzione, controllo degli accessi role-based (RBAC) e protezioni di sicurezza multilivello. FLASK, a sua volta, si basa su DTOS, un sistema operativo Trusted Mach, un progetto di ricerca fatto da Trusted Information Systems che ha influenzato la progettazione e l'implementazione di DTOS.

Descrizione

[modifica | modifica wikitesto]

Da NSA Security-enhanced Linux Team:[2]

NSA Security-Enhanced Linux è un insieme di strumenti del kernel Linux per monitorare il controllo degli accessi (MAC) installato nelle principali distribuzioni Linux.

Fornisce un meccanismo robusto per mantenere integre informazioni riservate che potrebbero, altrimenti, essere manomesse, consente di bypassare i meccanismi di sicurezza delle applicazioni, confina e risolve danni che potrebbero essere causati da applicazioni dannose o difettose.

SELinux comprende un insieme di file di configurazione e criteri di protezione progettati per soddisfare obiettivi di sicurezza comuni o general-purpose.

Un kernel Linux che integra SELinux impone politiche di controllo degli accessi obbligatori che limitano i programmi degli utenti, i software di sistema dei server, l'accesso ai file e alle risorse di rete. Limitando i permessi al minimo, sui sistemi Linux, riduce o elimina la capacità di programmi e processi demone di causare danni se difettosi o compromessi (ad esempio tramite overflow di buffer o errori di configurazione). Questo meccanismo di confinamento funziona indipendentemente dai meccanismi di controllo degli accessi di Linux. Non ha un concetto di superutente "root" e non possiede i tradizionali permessi speciali di sicurezza attribuiti a file e directory che modificano il comportamento del sistema nei confronti di utenti e/o gruppi (ad esempio setuid/setgid).

La sicurezza di un sistema senza SELinux dipende dalla correttezza del kernel, da tutti i privilegi delle applicazioni e da ogni loro configurazione. Un problema in alcune, o anche solo in una di esse, potrebbe genereare compromissioni di sicurezza all'intero sistema. Al contrario un sistema linux "modificato", cioè basato su un kernel SELinux, dipende dalla correttezza del kernel e dalle configurazioni delle politiche di sicurezza. Alcune imperfezioni di correttezza o configurazione di applicazioni potrebbero compromettere il funzionamento dei processi demone di sistema di ogni singolo utente, e anche, non necessariamente, reppresentano una minaccia ai demoni di sistema di altri utenti connessi o alla sicurezza dell'intero sistema. SELinux fornisce un insieme di concetti e funzionalità tratti da controlli di accesso, controlli di integrità e controllo degli accessi role-based (RBAC). Gli strumenti di "terze parti" consentono di creare versatilità sulle politiche di sicurezza.

Utenti, contesti e politiche di sicurezza

[modifica | modifica wikitesto]

Gli utenti e le politiche di SELinux non devono essere correlati agli utenti e alle politiche del sistema Linux. Per ogni utente o processo, SELinux assegna un context a tre stringhe costituito da nome utente, ruolo e dominio (o tipo). Di norma, la maggior parte degli utenti reali condivide lo stesso nome utente SELinux e tutto il controllo degli accessi è gestito tramite il terzo tag, il dominio. Questo sistema utilizzato è quindi più flessibile di quanto è normalmente richiesto. Un processo viene posto in un determinato dominio se la configurazione delle politiche lo permette. Per avviare un processo in un contesto esplicitamente specificato (utente, ruolo, dominio) deve essere lanciato con il comando runcon, SELinux può negare l'avvio se non è specificato nella configurazione della politica di sicurezza.

Hardware, porte di rete e file possiedono un contesto SELinux. Questo è costituito da un nome, un ruolo (raramente usato) e un tipo. In caso di file system, il mapping tra i file e i contesti di sicurezza è chiamato etichettatura. L'etichettatura è definita nei file delle politiche, ma può anche essere regolata manualmente senza modificare le configurazioni delle politiche. I tipi, nei contesti SELinux, vengono definiti in modo molto dettagliato. Ad esempio, bin_t (tutti i file nella cartella /bin) oppure postgresql_port_t (porta PostgreSQL, 5432). Il contesto SELinux per un file system remoto può essere specificato esplicitamente al momento del montaggio.

SELinux aggiunge l'opzione -Z ad alcuni comandi della shell tipo ls, ps (ed alcuni altri). Questo permette di vedere il contesto di sicurezza dei file o dei processi.

Una politica standard è costituita da: un file di mappatura (etichettatura), un file di regole e un file di interfaccia. Questi tre file, insieme, definiscono il dominio e devono essere sempre compilati insieme, con gli strumenti SELinux, in modo da produrre un unico file di criteri. Il file della politica risultante, per essere reso attivo, deve essere caricato nel kernel. Questi tipi di procedure (inserimento/rimozione su/dal kernel) non richiedono un riavvio del sistema per essere eseguite. I file dei criteri possono essere scritti a mano o essere generati dal SELinux Management che è nettamente di più facile utilizzo. Normalmente, i nuovi criteri, vengono prima testati in "modalità permissiva", dove le violazioni vengono appunto permesse e registrate. Lo strumento audit2allow può essere utilizzato per creare regole aggiuntive, che estendono la politica iniziale, per realizzare il confinamento di tutte le attività legittime che un'applicazione può eseguire.

Caratteristiche

[modifica | modifica wikitesto]

Le caratteristiche di SELinux comprendono:

  • Politiche di sicurezza ben definite
  • Separazione fra le politiche di sicurezza e le applicazioni
  • Supporto per le applicazioni che interrogano la politica di sicurezza ed il controllo degli accessi.
  • Indipendenza fra le diverse politiche di sicurezza
  • Indipendenza dei formati e dei contenuti di sicurezza
  • Controlli per servizi del kernel e [kernel objects] (kobj)
  • Supporto al cambiamento delle politiche di sicurezza
  • Mantenere separate la protezione dell'integrità del sistema e riservatezza dei dati (sicurezza [multilivello])
  • Politiche di sicurezza flessibili
  • Controlli sull'inizializzazione dei processi e sull'esecuzione dei programmi
  • Controlli sul file-system, directory, file e [file-descriptor] aperti
  • Controlli su sockets, messaggi e interfacce di rete
  • Controllo delle informazioni memorizzate nella cache tramite la AVC[3] (cache vettoriale di accesso dall'inglese Access Vector Cache)

Implementazioni

[modifica | modifica wikitesto]

SELinux è implementato e disponibile, dalla versione 4 in poi, nella distribuzione commerciale di Red Hat: "Red Hat Enterprise Linux (RHEL)". La politica di sicurezza in RHEL4 punta alla massima facilità d'uso e quindi è molto poco restrittiva. Dopo la quarta versione viene invece implementata una politica di sicurezza molto più restrittiva. SELinux lo si può anche trovare nelle versioni corrispondenti di CentOS e Scientific Linux e dalla versione 4.3[4] è anche implementato nel sistema operativo Android.

Una delle prime distribuzioni, supportate dalla comunità GNU/Linux, ad aver implementato SELinux è stata Fedora. Altre distribuzioni che oggi lo supportano sono Debian, Ubuntu 8.04 Hardy Heron[5] e dalla versione 11.1 Enterprise anche openSUSE ne ha un'implementazione come "anteprima tecnologica"[6].

SELinux è molto utilizzato nei sistemi basati su container linux, come Container Linux di CoreOS e rkt[7]. È utile come controllo di sicurezza aggiuntivo, per contribuire a rafforzare ulteriormente l'isolamento tra i container ed il loro host.

Possibili utilizzi

[modifica | modifica wikitesto]

SELinux, potenzialmente, potrebbe controllare, con specifiche molto precise, attività, processi o demoni di ogni utente che utilizza Linux. In ogni caso il modulo è principalmente utilizzato per limitare demoni come algoritmi per database o server web, che possiedono attività e accesso ai dati nettamente più definiti. Questa limitazione, previene un potenziale danno ad un processo demone che presenta alcune vulnerabilità. Di solito i processi "ordinari" degli utenti vengono eseguiti senza l'ausilio del modulo SELinux ma vengono comunque limitati dai classici permessi di accesso di Linux.

Alcuni command-line utilizzati sono:[8] chcon,[9] restorecon,[10] restorecond,[11] runcon,[12] secon,[13] fixfiles,[14] setfiles,[15] load_policy,[16] booleans,[17] getsebool,[18] setsebool,[19] togglesebool[20] setenforce, semodule, postfix-nochroot, check-selinux-installation, semodule_package, checkmodule, selinux-config-enforcing,[21] selinuxenabled,[22] and selinux-policy-upgrade[23].

Esempi

[modifica | modifica wikitesto]

Mettere SELinux in modalità enforcing:

$ sudo setenforce 1

Verificare lo stato di SELinux:

$ getenforce

Confronto con AppArmor

[modifica | modifica wikitesto]

SELinux rappresenta solo uno dei tanti possibili approcci al problema di limitare le azioni che il software installato può eseguire. Un'altra alternativa molto comune si chiama AppArmor ed è disponibile su distribuzioni come: SUSE Linux Enterprise Server (SLES), openSUSE e altre basate su Debian. AppArmor è stato sviluppato nella distribuzione, ormai inutilizzata, Immunix Linux. AppArmor e SELinux si differenziano radicalmente l'uno dall'altro. Per questo motivo formano alternative distinte per il controllo del software. Al contrario di SELinux, AppArmor è stato progettato per essere semplice, estende la stessa semantica amministrativa utilizzata per DAC fino al controllo di accesso obbligatorio.

Differenze

[modifica | modifica wikitesto]
  • Un'importante differenza riguarda il fatto che AppArmor identifica gli oggetti del filesystem in base al nome del percorso anziché l'utilizzo dell'inode. Ciò significa che, ad esempio, un file inaccessibile può diventare accessibile, in AppArmor, anche solo creando un collegamento fisico, mentre SELinux nega l'accesso tramite il nuovo collegamento fisico appena creato.
  • Si può affermare che AppArmor non sia un sistema "type enforcement", infatti ai file non viene assegnato un tipo ma vengono semplicemente referenziati in un file di configurazione.
  • SELinux e AppArmor differiscono anche in modo significativo nel modo in cui sono amministrati e in che modo si integrano nel sistema[24].
  • AppArmor utilizza i tradizionali controlli DAC a livello MAC, il set di operazioni è anche molto più piccolo di quelli disponibili nella maggior parte delle implementazioni di SELinux. Ad esempio, il set di operazioni di AppArmor consiste in: lettura, scrittura, aggiunta, esecuzione, blocco e collegamento[25]. SELinux di solito supporta le stesse autorizzazioni, ma include anche controlli per mknod, binding ai socket di rete, uso implicito delle funzionalità POSIX, caricamento e scaricamento dei moduli del kernel, vari modi per accedere alla memoria condivisa, ecc.
  • Non ci sono controlli in AppArmor per le funzionalità POSIX. AppArmor è in grado di impedire che i permessi vengano modificati ed impedire che i filesystem vengano montati/smontati, ma non fa nulla per impedire agli utenti di uscire dal loro dominio di controllo approvato da AppArmor.
  • Non esiste la nozione di sicurezza multilivello con AppArmor, quindi non è disponibile alcuna protezione BLP o Biba.
  • La configurazione di AppArmor viene eseguita utilizzando esclusivamente file flat regolari. SELinux (di default nella maggior parte delle implementazioni) usa una combinazione di file flat (usati da amministratori e sviluppatori per scrivere politiche di sicurezza leggibili prima che siano compilate) e attributi estesi.
  • SELinux supporta il "server remoto di gestione dei criteri" (configurabile tramite /etc/selinux/semanage.conf) come fonte alternativa per la configurazione dei criteri di sicurezza. La gestione centralizzata di AppArmor invece è notevolmente più complicata dal momento che gli amministratori devono decidere tra gli strumenti di distribuzione della configurazione eseguiti come root (per consentire gli aggiornamenti dei criteri) e le configurazioni eseguite manualmente su ciascun server.

Sistemi simili

[modifica | modifica wikitesto]

L'isolamento dei processi e delle applicazioni, per motivi di sicurezza, può essere realizzato anche da altri sistemi, tipo quelli virtualizzati. Il progetto OLPC, ad esempio, nella sua prima implementazione[26] eseguiva le applicazioni in server virtuali (Vserver) separati, fungendo da sandbox.

Anche la NSA ha utilizzato alcuni concetti di SELinux per la sicurezza dei sistemi operativi basati su Android[27].

Note

[modifica | modifica wikitesto]
  1. ^ Compare National Security Agency Shares Security Enhancements to Linux, in NSA Press Release, Fort George G. Meade, Maryland, National Security Agency Central Security Service, 2 gennaio 2001. URL consultato il 17 novembre 2011 (archiviato dall'url originale il 20 febbraio 2018).
    «The NSA is pleased to announce that it has developed, and is making available to the public, a prototype version of a security-enhanced Linux operating system.»
  2. ^ Security-Enhanced Linux - NSA/CSS, su nsa.gov, National Security Agency, 15 gennaio 2009. URL consultato il 6 febbraio 2013 (archiviato dall'url originale il 19 luglio 2019).
  3. ^ Fedora Documentation Project, Fedora 13 Security-Enhanced Linux User Guide, Fultus Corporation, 2010, p. 18, ISBN 978-1-59682-215-3. URL consultato il 22 febbraio 2012.
    «SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). Caching decisions decreases how often SELinux rules need to checked, which increases performance.»
  4. ^ Security-Enhanced Linux in Android, su source.android.com, Android Open Source Project. URL consultato il 31 gennaio 2016.
  5. ^ How To Install SELinux on Ubuntu 8.04 "Hardy Heron", in Ubuntu Tutorials.
  6. ^ Release Notes for SUSE Linux Enterprise Desktop 11, su novell.com, Novell. URL consultato il 6 febbraio 2013.
  7. ^ SELinux on CoreOS, in CoreOS Docs.
  8. ^ SELinux/Commands - FedoraProject, su fedoraproject.org. URL consultato il 25 novembre 2015.
  9. ^ chcon, su linuxcommand.org. URL consultato il 6 febbraio 2013 (archiviato dall'url originale il 24 ottobre 2004).
  10. ^ restorecon(8) - Linux man page, su linux.die.net. URL consultato il 6 febbraio 2013.
  11. ^ restorecond(8) - Linux man page, su linux.die.net. URL consultato il 6 febbraio 2013.
  12. ^ runcon(1) - Linux man page, su linux.die.net. URL consultato il 6 febbraio 2013.
  13. ^ secon(1) - Linux man page, su linux.die.net. URL consultato il 6 febbraio 2013.
  14. ^ fixfiles(8): fix file SELinux security contexts - Linux man page, su linux.die.net. URL consultato il 6 febbraio 2013.
  15. ^ setfiles(8): set file SELinux security contexts - Linux man page, su linux.die.net. URL consultato il 6 febbraio 2013.
  16. ^ load_policy(8) - Linux man page, su linux.die.net. URL consultato il 6 febbraio 2013.
  17. ^ booleans(8) - Linux man page, su linux.die.net. URL consultato il 6 febbraio 2013.
  18. ^ getsebool(8): SELinux boolean value - Linux man page, su linux.die.net. URL consultato il 6 febbraio 2013.
  19. ^ setsebool(8): set SELinux boolean value - Linux man page, su linux.die.net. URL consultato il 6 febbraio 2013.
  20. ^ togglesebool(8) - Linux man page, su linux.die.net. URL consultato il 6 febbraio 2013.
  21. ^ Ubuntu Manpage: selinux-config-enforcing - change /etc/selinux/config to set enforcing, su manpages.ubuntu.com, Canonical Ltd. URL consultato il 6 febbraio 2013 (archiviato dall'url originale il 20 dicembre 2012).
  22. ^ Ubuntu Manpage: selinuxenabled - tool to be used within shell scripts to determine if, su manpages.ubuntu.com, Canonical Ltd. URL consultato il 6 febbraio 2013 (archiviato dall'url originale il 9 febbraio 2013).
  23. ^ Ubuntu Manpage: selinux-policy-upgrade - upgrade the modules in the SE Linux policy, su manpages.ubuntu.com, Canonical Ltd. URL consultato il 6 febbraio 2013 (archiviato dall'url originale il 4 aprile 2012).
  24. ^ SELinux backgrounds, in SELinux, Security Guide, SUSE.
  25. ^ apparmor.d - syntax of security profiles for AppArmor, su manpages.ubuntu.com (archiviato dall'url originale il 17 ottobre 2013).
  26. ^ Rainbow, in laptop.org.
  27. ^ SELinux Related Work, in NSA.gov. URL consultato il 17 dicembre 2017 (archiviato dall'url originale il 20 febbraio 2018).

Voci correlate

[modifica | modifica wikitesto]

Altri progetti

[modifica | modifica wikitesto]

Collegamenti esterni

[modifica | modifica wikitesto]
Controllo di autoritàGND (DE) 4805017-9
Estratto da "https://it.wikipedia.org/w/index.php?title=Security-Enhanced_Linux&oldid=134853039"