Mandatory access control: differenze tra le versioni

Versione delle 18:02, 1 nov 2018

Versione attuale delle 15:15, 21 lug 2025

(40 versioni intermedie di 16 utenti non mostrate)

Riga 1:

{{NN|informatica|settembre 2018}}

Nella [[sicurezza informatica]], il termine '''mandatory access control''' ('''MAC''', in italiano: "controllo d'accesso vincolato") indica un tipo di controllo d'accesso alle risorse del sistema attraverso ilnel quale il [[sistema operativo]] vincola la capacità di un soggetto (es. utente) di eseguire diverse operazioni su un oggetto o un obiettivo del sistema stesso.

==Descrizione==

Un soggetto è un ente attivo, come può essere, ad esempio, un [[processo (informatica)|processo]] o un [[Thread (informatica)|thread]], edmentre gli oggetti possono essere i [[file]], le [[directory|cartelle]], le [[porta (reti)|porte]] [[Transmission Control Protocol|TCP]]/[[User Datagram Protocol|UDP]], segmenti di [[memoria (informatica)|memoria]] condivisa e altro.

Il controllo di accesso si basa sulla specifica a priori di una serie di attributi di sicurezza rispettivamente per soggetti e oggetti: quando un soggetto tenta l'accesso a un oggetto, il [[kernel]] del sistema operativo avvia una regola di [[Autorizzazione (informatica)|autorizzazione]] che esamina gli attributi di sicurezza di soggetti e oggetti e decide se l'accesso può aver luogo oppure deve essere negato.

Anche un sistema di gestione della [[base di dati]] ([[DBMS]]), può applicare il MAC come meccanismo di controllo degli accessi può applicare MAC. In questo caso gli oggetti sono rappresentati dalle [[tabella (database)|tabelle]], dalle [[vista (database)|viste]], dalle procedure etcecc.

Per storia e tradizione, il MAC è strettamente correlato con i sistemi che operano in modalità di [[sicurezza multilivello]] (MLS).

== Retroscena storico e implicazioni con sicurezzela sicurezza multilivello ==

In passato, MAC era fortemente associato con sicurezzela sicurezza multilivello (multilevel security – MLS) in modo da proteggere le informazioni classificate americane.

La [[Trusted Computer System Evaluation_CriteriaEvaluation Criteria]] (TCSEC) hafornì provvedutola alladefinizione originale definizioneoriginaria del MAC come “una forma di restrizione d’accessodell'accesso adagli oggetti basata sulla sensibilità delle informazioni contenute in oggettiessi e l’autorizzazione formale diai soggetti diper accedere alle formazioni di tale sensibilità”.

Più recenti implementazioni di MAC come Honeywell’s SCOMP, USAF SACDIN, NSA Blacker, e Boeing’s MLS LAN incentrata su MLS per proteggere livelli classificati di orientamento militare con rinforzi robusti.

Il termine "mandatory ("obbligatorio in MAC") ha acquisito un significato speciale nel MAC, derivante dal suo utilizzo nei sistemi militari.

In questo contesto, MAC implica un estremamente elevato grado di robustezza cheestremamente elevato, tale da assicuraassicurare che i meccanismi di controllo possano resistere a ogni tipo di sovversione, in modo da permetter loro di imporre controlli d’accesso che sono affidati su ordine di un governo come “l’Executive Order 12958” per le informazioni classificate americane.

L’imposizione dovrebbe essere più imperativa che per applicazioni commerciali.

Questo preclude l’applicazione di meccanismi efficienti; solo meccanismi che possono provvedere assolutamente o quasi al compito sono accettabili nel MAC.

Questo è un altogrado ordinedi esicurezza acosì volteelevato risultada apparire irrealistico a coloro che non sono familiari con strategie benche certerichiedono certezza assoluta, e molto difficile anche per coloro che invece lo sono.

==Robustezza del controllo ==

=== GradiGerarchia didei potenzaprivilegi delnei sistemasistemi MAC ===

In alcuni sistemi, l’utente ha l’autorità di decidere se garantire l’accesso ad ogni altro utente.

Per permettere questo, tutti gli utenti hanno autorizzazioni su tutti i dati.

Questo non è necessariamente vero in un sistema MLAmultilivello.

Se esistono individui o processi a cui può essere negato l’accesso ad alcuni dati del sistema, allora il sistema deve imporre il MAC.

Dal momento che ci possono essere diversi livelli di classificazione dei dati e utenti autorizzati, questo implica una quantificazione su scala per robustezza.

Riga 32 ⟶ 34:

Entrambi sono stati specificati con livelli di precisione che garantiscono confidenze significative in certificazioni basate su questi criteri.

=== EvoluzioneValutazione della potenzasicurezza dei sistemi MAC ===

IlI [[Common Criteria]] èsono basatobasati su questaquesti scienzaconcetti e il suoloro intento è quello di preservare l’Assuranceil [[Evaluation assurance level|livello di garanzia]], Levelinteso come livellilivello EAL e i funzionamenti specificati come "Protection ProfilesProfile".

Di questi due componenti essenziali di obiettiva robustezza dei segni di riferimento, solo i livelli EAL sono fedelmente preservati fedelmente.

Nel caso del TCSEC il livello C2 è abbastanza fedelmente preservato nel Common Criteria, come il Controlled Access Protection Profile (CAPP).

La sicurezza multilivello pernel laProtection protezione dei profiliProfile è più generale rispetto al livello B2 di TCSEC.

SonoI Common Criteria sono a conoscenza del MLS, ma manca una dettagliata implementazione dei requisiti degli Orange Book dei loro predecessori, concentrandosi maggiormente sugli obiettivi.

Questo dà ai certificatori maggior flessibilità soggettiva nelle decisioni se le caratteristiche tecniche del prodotto raggiungono adeguatamente l’obiettivo, potenzialmente l’erosione della consistenza della valutazione dei prodotti e rendendo più facile ottenere la certificazione per la certificazione per prodotti meno affidabili.

Per queste ragioni, l’importanza deii dettagli tecnici delladei protezione deiProtection profiliProfile èsono criticacritici pernel determinare l’adeguatezza di un prodotto.

Una tale architettura previene l’autenticazionel’accesso di utenti o processi, diautenticati per una determinatedeterminata classificazione o livello di fiducia, delledall'accesso informazionia di accessoinformazioni, processi, o dispositivi susituati diversia un livello livellidifferente.

Questo fornisce un meccanismo di contenimento per utenti e processi, che entrambi lo sappiano oppure no.

== Implementazioni ==

Alcune implementazioni di MAC, come il progetto Unisys’BlankerBlanker di Unisys, erano certificate in modo abbastanzasufficientemente robusto da separare le informazioni Top Secret da Classificati più tardiquelle nell’ultimoNon millennioClassificate.

La loro tecnologia non è diventatastata obsoletaaggiornata eed nonè “rinfrescate”diventata obsoleta.

Oggi non ci sono implementazioni certificate da TCSEC a quel livello di robustezza.

Esistono comunque prodotti meno robusti:

*AmonRSBAC Ott’sdi RSBACAmon Ott fornisce un framework per i nuclei dikernel Linux che ammette la presenza di diversi modelli decisionali sulla sicurezza. Uno dei modelli implementato è il controllo obbligatorio d’accesso. Un obiettivo generale del designprogetto RSBAC era quello di provare a raggiungere il livello B1 dell'“Orange Book” (TCSEC) livello B1. Il modello di MAC usato nel RSBAC è quasi lo stesso usato nei sistemi Unix V/MLS, versione 1.2.1 (sviluppato nel 1989 dal National Computer Security Center degli Stati Uniti d’America con una classificazione B1/TCSEC). RSBAC richiede ununa serie di aggiustamenti al magazzino, che sono mantenuti abbastanza bene dal proprietario del prodotto.

*Un progetto di ricerca deldella [[NSANational Security Agency]] chiamato SELinux ha aggiunto un 'architettura di tipo MAC al Linux Kernel, che è stata poi implementata nella versione principale di Linux nell’agosto del 2003. Utilizza caratteristiche del nucleo Linux 2.6 chiamate LSM ([[Linux Security Modules]] interface). [[Red Hat Linux|Red Hat Enterprise Linux]] versione 4 viene fornito con un kernel abilitato per SELinux. Sebbene SELinux sia in grado di limitare tutti i processi del sistema, il criterio di destinazione predefinito in RHEL limita i programmi più vulnerabili dal dominio non confinato in cui vengono eseguiti tutti gli altri programmi. RHEL 5 spedisce altri2 tipi di politiche binarie: strict, che tenta di implementare il minimo privilegio, e MLS, che si basa su strict e aggiunge etichette MLS. RHEL 5 contiene ulteriori miglioramenti MLS e ha ricevuto 2 certificazioni LSPP/RBACPP/CAPP/EAL4 nel Giugno del 2007.

*[[TOMOYO Linux]] è un'implementazione leggera di Mac per Linux e [[Embedded Linux]], sviluppata da NTT Data Corporation. È stata implementata nella versione principale di Linux Kernel 2.6.30 nel Giugno del 2009. A differenza degli approcci basati sulle etichette usati da SELinux, TOMOYO Linux esegue un Controllo d’Accesso Obbligatorio basato sul percorso del nome, separando domini della sicurezza in accordo con il processo di invocazione della storia, che descrive il sistema contemporaneo. Le politiche sono descritte in base al percorso. Una sicurezza dominante è semplicemente definita da un processo chiamato catena, e rappresentato da una stringa. Ci sono 4 modalità: disabilitato, apprendimento, permissivo, forzante. Gli amministratori possono assegnare diverse modalità a diversi domini. TOMOYO Linux introduce la modalità di “apprendimento”, nella quale gli accessi avvenuti nel nucleo sono automaticamente analizzati e memorizzati per generare politiche MAC: questa modalità potrebbe quindi essere il primo passo verso una politica di scrittura, rendendola più facile da personalizzare in seguito.

*[[SUSE Linux]] e [[Ubuntu]] 7.10 hanno aggiunto una implementazione MAC chiamata [[AppArmor]]. AppArmor utilizza una funzione del kernel Linux 2.6 chiamata LSM (Linux Security Modules interfaces). LSM fornisce un’ un'API del kernel che permette ai moduli del codice del kernel di gestire ACL (DAC ACL, liste di controllo d’accesso). AppArmor non è in grado di limitare tutti i programmi ed è opzionale nei kernel Linux dalla versione 2.6.36.

*[[Linux]] e molte altre distribuzioni Unix hanno MAC per CPU, dischi, e memoria; mentre il software del sistema operativo non può gestire bene i privilegi, Linux è diventato famoso durante il 1990 essendo più sicuro e molto più stabile rispetto alle alternative non-Unix. I distributori Linux disabilitano MAC per essere i migliori DAC per alcuni dispositivi – anche se questo è vero per qualsiasi [[elettronica di consumo]] oggi.

*grsecurity è una versione per il kernel Linux che fornisce un’implementazione MAC (precisamente, è una implementazione [[RBAC]]). grsecurity non è implementato attraverso LSM API.

*[[Microsoft]] a partire da [[Windows Vista]] e [[Windows Server 2008|Server 2008]], Windows incorpora un controllo obbligatorio dell’integrità (Mandatory Integrity Control – MIC), che aggiunge livelli d’integrità (Integrity Level – IL) ai processi in esecuzione in una sessione logica. MIC restringe i permessi di accesso alle applicazioni che sono eseguite nello stesso account utente e che potrebbero essere meno affidabili. I cinque livelli di integrità sono: basso, medio, alto, sistema e programma di installazione affidabile. I processi iniziati da un utente regolare guadagnano un livello di integrità medio; processi elevati hanno un alto livello di integrità. Mentre i processi ereditano il livello di integrità dal processo da cui sono stati creati, il livello d’integrità può essere personalizzato in base al pre-processo: per esempio IE7 e gli eseguibili scaricati vengono eseguiti con un livello d’integrità basso. Windows controlla l’accesso agli oggetti attraverso il livello d’integrità, e inoltre definisce il limite per i messaggi di windows attraverso l’isolamento del privilegio dell’interfacciadell’[[interfaccia utente]] (User Inteface Privilege Isolation). Oggetti con nome, inclusi file, chiavi di registri o altri processi e threads, hanno una voce nell’ACL che governa l’accesso ad essi che definisce il livello d’integrità minimo del processo che può utilizzare l’oggetto. MIC impone che un processo possa scrivere o cancellare un oggetto solo quando il suo livello d’integrità è uguale o superiore al livello d’integrità dell’oggetto. Inoltre, per impedire l’accesso ai [[dati sensibili]] in memoria, i processi non possono aprire processi con un livello d’integrità più alto per l’accesso in lettura.

*[[FreeBSD]] supporta il controllo di accesso obbligatorio (Mandatory Access Control – MAC), implementato come una parte del progetto TrustedBSD. È stato introdotto nel FreeBSD 5.0. Dal FreeBSD 7.2, il supporto MAC è disponibile di default. La struttura è estensibile; vari modelli MAC implementano politiche come Biba e sicurezze multilivello.

*[[Trusted Solaris]] di Sun usa un meccanismo di controllo sull’accesso obbligatorio e imposto dal sistema (MAC), dove vengono utilizzati nulla osta e etichette per applicare una politica di sicurezza. Tuttavia, si noti che la capacità di gestire le etichette non implica la forza del kernel di operare in modalità di sicurezza multilivello. L’accesso alle etichette e ai meccanismi di controllo non è adeguatamente protetto dalla corruzione di domini protetti gestiti dal kernel. Le applicazioni eseguite da un utente sono combinate con le etichette di sicurezza della sessione in cui l’utente lavora. L’accesso a informazioni, programmi e dispositivi è scarsamente controllato.

*La struttura MAC OS X MAC di Apple è un’implementazione della struttura [[TrustedBSD]] MAC. Un’interfaccia sandboxing di alto livello limitata è fornita dalla funzione della linea di comando sandbox_int. Consultare la pagina sandbox_int del manuale per documentazione.

Riga 62 ⟶ 64:

*[[Trusted RUBIX]] è un controllo di accesso obbligatorio (MAC) che impone il DBMS che si integra completamente con SE-Linux per limitare l’accesso a tutti gli oggetti del database.

*Il sistema operativo [[Astra Linux]] sviluppato per l’esercito russo ha il proprio controllo di accesso obbligatorio (MAC).

*[https://www.kernel.org/doc/html/latest/admin-guide/LSM/Smack.html (software)|Smack] (Simplified Mandatory Access Control Kernel) è un modulo di sicurezza del kernel Linux che protegge i dati e processa l’interazione manipolazioni dannose usando una serie di regole di controllo d’accesso obbligatorie e personalizzate, con la semplicità come obiettivo principale di progettazione. È stato ufficialmente unito dalla versione rilasciata di Linux 2.6.25.

== Note ==

Riga 69 ⟶ 71:

1. [https://web.archive.org/web/20070715134110/http://csrc.nist.gov/secpubs/rainbow/std004.txt "Technical Rational Behind CSC-STD-003-85: Computer Security Requirements"]. 1985-06-25. Archiviato dall'originale il 15 luglio del 2007. Recuperato il 15-03-2008.

2. {{Collegamento interrotto|1=[httphttps://www.commoncriteriaportal.org/ "The Common Criteria Portal"] {{Webarchive|dateurl=novembre 2018https://web.archive.org/web/20060718074701/http://www.commoncriteriaportal.org/ |botdata=InternetArchiveBot18 luglio 2006 }}. Recuperato il 15-03-2008.

3. Dipartimento della Difesa Americano (Dicembre 1985). [https://fas.org/irp/nsa/rainbow/std001.htm "DoD 5200.28-STD: Trusted Computer System Evaluation Criteria"]. Recuperato il 15-03-2008.

4. {{Collegamento interrotto|1=[httphttps://www.niap-ccevs.org/cc-scheme/pp/pp.cfm/id/PP_OS_CA_V1.d/ "Controlled Access Protection Profile, Version 1.d"] {{Webarchive|dateurl=novembre 2018https://web.archive.org/web/20120207001837/http://www.niap-ccevs.org/cc-scheme/pp/pp.cfm/id/PP_OS_CA_V1.d/ |botdata=InternetArchiveBot7 febbraio 2012 }}. Agenzia della Sicurezza Nazionale. 10-08-1999. Recuperato il 15-03-10082008.

5. "Protection Profile for Multi-Level Operating Systems in Environments Requiring Medium Robustness, Version 1.22". Agenzia della Sicurezza Nazionale. 23-05-2001. Recuperato il 15-03-2008.

Riga 79 ⟶ 81:

6. National Information Assurance Partnership. [https://web.archive.org/web/20080314060625/http://www.niap-ccevs.org/cc-scheme/vpl/ "The Common Criteria Evaluation and Validation Scheme Validated Products List"]. Archiviato dall’originale il 14-03-2008. Recuperato il 15-03-2008.

7. [httphttps://kernelnewbies.org/Linux_2_6_30#head-eeb259e0ba81d96d59015b8f79456d9a5283c650 "TOMOYO Linux, an alternative Mandatory Access Control"]. Linux 2 6 30. Linux Kernel Newbies.

8. [httphttps://kernelnewbies.org/Linux_2_6_36 "Linux 2.6.36 released 20 October 2010". Linux 2.6.36]. Linux Kernel Newbies.

9. [httphttps://grsecurity.net/lsm.php "Why doesn't grsecurity use LSM?"].

10. Matthew Conover. [https://web.archive.org/web/20080325024250/http://www.symantec.com/enterprise/security_response/weblog/2006/08/windows_vista_windows_security.html "Analysis of the Windows Vista Security Model"]. Symantec Corporation. Archiviato dall’originale il 25-03-2008. Recuperato il 08-10-2007.

11. Steve Riley. [https://web.archive.org/web/20070929084227/http://blogs.technet.com/steriley/archive/2006/07/21/442870.aspx "Mandatory Integrity Control in Windows Vista"]. Retrieved 2007-10-08.

12. Mark Russinovich. [https://web.archive.org/web/20100415164810/http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx "PsExec, User Account Control and Security Boundaries"]. Recuperato il 08-10-2007.

13. TrustedBSD Project. [http://www.trustedbsd.org/mac.html "TrustedBSD Mandatory Access Control (MAC) Framework"]. Recuperato il 15-03-2008.

Riga 95 ⟶ 97:

14. [https://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man3/sandbox_init.3.html "sandbox_init(3) man page"]. O7-07-2007. Recuperato il 15-03-2008.

15. [httphttps://wiki.postgresql.org/wiki/SEPostgreSQL-patch "SEPostgreSQL-patch"].

16. [httphttps://code.google.com/p/sepgsql/ "Security Enhanced PostgreSQL"].

17. [https://web.archive.org/web/20081121215622/http://www.rubix.com/ "Trusted RUBIX"].

Riga 103 ⟶ 105:

18. (in Russo) [https://web.archive.org/web/20140716115137/http://astra-linux.com/klyuchevye-osobennosti.html Ключевые особенности Astra Linux Special Edition по реализации требований безопасности информации]

19. [https://wwwweb.webcitationarchive.org/6AqzohCXq?url=web/20130501010740/http://schaufler-ca.com/description_from_the_linux_source_tree "Official SMACK documentation from the Linux source tree"]. Archiviato dall’originale il 21-09-2012.

20. Jonathan Corbet. [https://wwwweb.webcitationarchive.org/6AqxbHgv3?url=web/20121102083054/http://lwn.net/Articles/267849/ "More stuff for 2.6.25"]. Archiviato dall’originale il 21-09-2012.

== Bibliografia ==

*P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell. ''[https://web.archive.org/web/20070621155813/http://jya.com/paperF1.htm The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments]''. Negli Atti della 21esima21ª Conferenza sulla sicurezza di sistemi di informazione nazionale, pagine 303-314, ottobre 1998.

*P. A. Loscocco, S. D. Smalley, ''[httphttps://web.archive.org/web/20180910094808/https://www.nsa.gov/selinux/papers/ottawa01-abs.cfm Meeting Critical Security Objectives with Security-Enhanced Linux]'' Atti dell’Ottawa Linux Symposium del 2001.

*ISO/IEC DIS 10181-3, Information Technology, OSI Security Model, Security FrameWorks, Part 3: Access Control, 1993.

* Robert N. M. Watson. "[httphttps://dl.acm.org/citation.cfm?id=2428616.2430732 A decade of OS access-control extensibility]". Commun. ACM 56, 2 (February 2013), 52–63.

== Voci correlate ==

Riga 120 ⟶ 122:

== Collegamenti esterni ==

*[https://web.archive.org/web/20060504192215/http://rentzsch.com/notes/virtualizationAsAnAntivirus Weblog post] sul modo in cui la virtualizzazione può essere usata per l’implementazione del controllo obbligatorio d’accesso.

* [https://web.archive.org/web/20070929084227/http://blogs.technet.com/steriley/archive/2006/07/21/442870.aspx Weblog post] da un impiegato Microsoft che descrive il controllo obbligatorio dell’integrità (Mandatory Integrity Control) e come differisce dalle implementazioni MAC.

* [http://hokiepokie.org/docs/acl22003/security-policy.pdf GWV Formal Security Policy Model] Una politica di sicurezza formale del kernel di separazione, David Greve, Matthew Wilding e W. Mark Vanfleet.

{{portale|sicurezza informatica}}

[[Categoria:SicurezzaControllo degli accessi (informatica)]]