Contenuti del file LocalPolicy per i Mac dotati di chip Apple

Passaggio di proprietà tra sistemi operativi

L’accesso alla chiave OIK è conosciuto come “proprietà”. La proprietà è richiesta per consentire agli utenti di firmare nuovamente il LocalPolicy dopo aver effettuato modifiche alle politiche o al software. La OIK è protetta tramite la stessa gerarchia di chiavi descritta in Protezione SKP (Sealed Key Protection): la OIK è protetta dalla stessa chiave di codifica delle chiavi della chiave di codifica per il volume. Ciò significa che è normalmente protetta sia delle password dell’utente che dalle misurazioni del sistema operativo e dalle politiche di protezione. Sul Mac è presente una singola OIK per tutti i sistema operativi. Quindi, quando si installa un secondo sistema operativo, è richiesto un consenso esplicito da parte degli utenti del primo sistema operativo per passare la proprietà agli utenti del secondo. Tuttavia, gli utenti del secondo sistema operativo ancora non esistono quando il programma di installazione viene eseguito dal primo sistema operativo. Gli utenti del sistema operativo normalmente non vengono generati finché questo non viene avviato e Impostazione Assistita non è in esecuzione. Quindi sono necessarie due nuove azioni quando si installa un secondo sistema operativo su un Mac dotato di chip Apple.

• Creare un LocalPolicy per il secondo sistema operativo.

• Preparare un “utente di installazione” per il passaggio della proprietà.

Quando si esegue un’installazione assistita e si usa come destinazione un volume secondario vuoto, all’utente viene chiesto se vuole copiare un utente dal volume attuale per fare da primo utente nel secondo volume. Se l’utente accetta, l’utente di installazione che viene creato è, in realtà, una chiave di codifica delle chiavi derivata dalla password dell’utente e dalle chiavi hardware, che viene successivamente usata per codificare la OIK mentre viene passata al secondo sistema operativo. Successivamente, nell’installazione assistita del secondo sistema operativo, viene richiesta la password di tale utente, per consentire l’accesso alla OIK in Secure Enclave per il nuovo sistema operativo. Se l’utente non accetta di copiare un utente, l’utente di installazione viene creato nello stesso modo, ma viene usata una password vuota invece della password di un utente. Questa seconda procedura è pensata per determinate situazioni legate all’amministrazione del sistema. Tuttavia, per gli utenti che desiderano avere installazioni su più volumi e vogliono eseguire il passaggio della proprietà nel modo più sicuro, è consigliabile accettare sempre di copiare un utente dal primo sistema operativo sul secondo sistema operativo.

LocalPolicy sui Mac dotati di chip Apple

Nei Mac dotati di chip Apple, il controllo delle politiche di sicurezza locali è stato delegato a un’app in esecuzione su Secure Enclave. Tale software può usare le credenziali dell’utente e la modalità di avvio della CPU principale per determinare chi può modificare la politica di sicurezza e da quale ambiente di avvio. Ciò aiuta a impedire a software dannoso di utilizzare i controlli della politica di sicurezza contro l’utente, riducendoli per poter ottenere maggiori privilegi.

Proprietà del manifesto LocalPolicy

Il file LocalPolicy contiene alcuni codici di 4 caratteri strutturali che sono presenti in quasi tutti i file Image4, come BORD (che indica una scheda o un ID modello), CHIP (che indica un particolare chip Apple) o ECID (l’identificatore unico del processore). I seguenti codici di 4 caratteri invece si concentrano solo sulle politiche di sicurezza che possono essere configurate dall’utente.

Hash del nonce di LocalPolicy (lpnh)

• Tipo: OctetString (48)

• Ambienti mutabili: 1TR, recoveryOS, macOS

• Descrizione: Il nonce lpnh viene usato per impedire il riutilizzo di LocalPolicy. Si tratta di un hash SHA384 del nonce di LocalPolicy che viene archiviato nel componente Secure Storage ed è accessibile tramite la ROM di avvio di Secure Enclave o tramite Secure Enclave. L’effettivo valore anti-replay non è mai visibile al processore per le applicazioni, ma può essere visto solo dal sistema operativo Secure Enclave. Un hacker che vuole convincere il bootloader di livello inferiore che un LocalPolicy precedente di cui si è impossessato era valido dovrebbe posizionare un valore nel componente Secure Storage che produca un hash verso lo stesso valore lpnh trovato nel LocalPolicy che vuole riutilizzare. Normalmente si ha un singolo nonce di LocalPolicy valido, tranne durante gli aggiornamenti software, quando ce ne sono due validi simultaneamente, per consentire la possibilità di riavviare il software meno recente in caso di un errore di aggiornamento. Quando qualsiasi LocalPolicy per qualsiasi sistema operativo viene modificato, tutte le politiche vengono nuovamente firmate con il nuovo valore lpnh corrispondente al nuovo nonce della politica locale trovato nel componente Secure Storage. Questa modifica avviene quando un utente modifica le impostazioni di sicurezza o crea nuovi sistemi operativi, ciascuno con un nuovo LocalPolicy.

Hash del nonce della politica remota (rpnh)

• Tipo: OctetString (48)

• Ambienti mutabili: 1TR, recoveryOS, macOS

• Descrizione: Il nonce rpnh si comporta allo stesso modo di lpnh, ma si aggiorna solo quando viene aggiornata la politica remota, come ad esempio quando si cambia lo stato della registrazione di Dov’è. Questa modifica avviene quando l’utente cambia lo stato di Dov’è sul Mac.

Hash del nonce di recoveryOS (ronh)

• Tipo: OctetString (48)

• Ambienti mutabili: 1TR, recoveryOS, macOS

• Descrizione: Il nonce ronh si comporta allo stesso modo di <CodeBody>lpnh</CodeBody>, ma si trova esclusivamente nel LocalPolicy per il recoveryOS di sistema. Si aggiorna solo quando viene aggiornato il recoveryOS di sistema, ad esempio durante l’aggiornamento del software. Un valore anti-replay diverso da lpnh e rpnh viene usato affinché, quando un dispositivo viene disabilitato da Dov’è, i sistemi operativi possano essere disabilitati (rimuovendo i relativi LPN e RPN dal componente Secure Storage) ma il recoveryOS di sistema possa comunque essere avviato. In questo modo, i sistemi operativi possono essere riabilitati quando il proprietario del sistema dimostra di poterlo controllare inserendo la propria password di iCloud utilizzata per l’account di Dov’è. Questa modifica avviene quando un utente aggiorna il recoveryOS di sistema o crea nuovi sistemi operativi.

Hash del manifesto Image4 di fase successiva (nsih)

• Tipo: OctetString (48)

• Ambienti mutabili: 1TR, recoveryOS, macOS

• Descrizione: Il campo nsih rappresenta un hash SHA384 della struttura di dati del manifesto che descrive la copia di macOS avviata. Il manifesto Image4 di macOS contiene misurazioni relative a tutti gli oggetti di avvio come iBoot, la cache di affidabilità statica, la struttura ad albero del dispositivo, la raccolta del kernel di avvio e l’hash root del volume di sistema firmato. Quando al bootloader di livello inferiore viene chiesto di avviare una determinata copia di macOS, lo scopo è quello di garantire che l’hash del manifesto Image4 di macOS allegato ad iBoot corrisponda a ciò che viene rilevato nel campo nsih di LocalPolicy. In questo modo, nsih rileva per quale sistema operativo l’utente ha intenzionalmente creato un file LocalPolicy. Gli utenti modificano il valore nsih in modo implicito quando eseguono un aggiornamento software.

Hash del manifesto Image4 di Cryptex1 (spih)

• Tipo: OctetString (48)

• Ambienti mutabili: 1TR, recoveryOS, macOS

• Descrizione: Il campo spih rappresenta un hash SHA384 della struttura dei dati del manifesto Image4 di Cryptex1. Il manifesto Image4 di Cryptex1 contiene misurazioni relative ai propri cryptex, i sigilli dei relativi file system e la cache di attendibilità associata. All’avvio di macOS, il kernel XNU e il Page Protection Layer verificano che l’hash del manifesto Image4 di Cryptex1 corrisponda a quello pubblicato da iBoot nel campo spih di LocalPolicy. Gli utenti modificano il valore spih in modo implicito quando installano un intervento di sicurezza rapido o eseguono un aggiornamento software. L’hash del manifesto Image4 di Cryptex1 può essere aggiornato in maniera indipendente rispetto al manifesto Image4 di fase successiva.

Generazione Cryptex1 (stng)

• Tipo: intero non firmato di 64 bit

• Ambienti mutabili: 1TR, recoveryOS, macOS

• Descrizione: il campo stng è un valore contatore che rappresenta l’ultimo aggiornamento dell’hash del manifesto Image4 di Cryptex1 in LocalPolicy. Fornisce un valore anti-replay al posto di lpnh durante la valutazione di Page Protection Layer della policy locale per l’applicazione del cryptex in entrata. Gli utenti aumentano il valore stng in modo implicito quando installano un intervento di sicurezza rapido o eseguono un aggiornamento software.

Hash della politica per la raccolta del kernel ausiliaria (auxp)

• Tipo: OctetString (48)

• Ambienti mutabili: macOS

• Descrizione: Il campo auxp è un hash SHA384 della politica per l’elenco di estensioni del kernel autorizzate dall’utente. Esso viene usato durante la generazione della raccolta del kernel ausiliaria per aiutare a garantire che in essa siano incluse solo le estensioni del kernel autorizzate dall’utente. smb2 è un prerequisito per impostare questo campo. Gli utenti modificano il valore auxp in maniera implicita quando modificano l’elenco di estensioni del kernel autorizzate dall’utente approvando un’estensione del kernel da “Privacy e Sicurezza” in Impostazioni di Sistema (macOS 13 o versioni successive) o dal pannello “Sicurezza e Privacy” in Preferenze di Sistema (macOS 12 o versioni precedenti).

Hash del manifesto Image4 per la raccolta del kernel ausiliaria (auxi)

• Tipo: OctetString (48)

• Ambienti mutabili: macOS

• Descrizione: Una volta che il sistema ha verificato che l’hash dell’elenco di estensioni del kernel autorizzate dall’utente corrisponde al campo auxp di LocalPolicy, richiede che la raccolta del kernel ausiliaria venga firmata dall’app del processore Secure Enclave che è responsabile per la firma di LocalPolicy. Successivamente un hash SHA384 della firma del manifesto Image4 della raccolta del kernel ausiliaria viene posizionato in LocalPolicy, per evitare la potenziale applicazione errata di raccolte del kernel ausiliarie precedenti a un sistema operativo durante l’avvio. Se iBoot trova il campo auxi in LocalPolicy, tenta di caricare la raccolta del kernel ausiliaria dallo spazio di archiviazione e ne convalida la firma. Verifica anche che l’hash del manifesto Image4 allegato alla raccolta del kernel ausiliaria corrisponda al valore trovato nel campo auxi. Se per qualsiasi motivo il caricamento della raccolta del kernel ausiliaria non va a buon fine, il sistema continua l’avvio senza questo oggetto di avvio, quindi senza caricare estensioni del kernel di terze parti. Il campo auxp è un prerequisito per l’impostazione del campo auxi in LocalPolicy. Gli utenti modificano il valore auxi in maniera implicita quando modificano l’elenco di estensioni del kernel autorizzate dall’utente approvando un’estensione del kernel da “Privacy e Sicurezza” in Impostazioni di Sistema (macOS 13 o versioni successive) o dal pannello “Sicurezza e Privacy” in Preferenze di Sistema (macOS 12 o versioni precedenti).

Hash della ricevuta per la raccolta del kernel ausiliaria (auxr)

• Tipo: OctetString (48)

• Ambienti mutabili: macOS

• Descrizione: Il campo auxr è un hash SHA384 della ricevuta della raccolta del kernel ausiliaria, che indica l’esatto insieme di estensioni del kernel incluse all’interno della raccolta del kernel ausiliaria. La ricevuta della raccolta del kernel ausiliaria può essere un sottoinsieme dell’elenco di estensioni del kernel autorizzate dall’utente, perché le estensioni del kernel possono essere escluse dalla raccolta del kernel ausiliaria anche se sono autorizzate, se è noto che vengono utilizzate per effettuare attacchi. Inoltre, alcune estensioni del kernel che possono essere utilizzate per superare il confine tra utente e kernel potrebbero ridurre alcune funzionalità come la possibilità di usare Apple Pay o di riprodurre contenuti 4K e HDR. Gli utenti che desiderano avere tali possibilità sono disposti ad accettare un’inclusione all’interno della raccolta del kernel ausiliaria più restrittiva. Il campo auxp è un prerequisito per l’impostazione del campo auxr in LocalPolicy. Gli utenti modificano il valore auxr in maniera implicita quando creano una nuova raccolta del kernel ausiliaria da “Privacy e Sicurezza” in Impostazioni di Sistema (macOS 13 o versioni successive) o dal pannello “Sicurezza e Privacy” in Preferenze di Sistema (macOS 12 o versioni precedenti).

Hash del manifesto Image4 di CustomOS (coih)

• Tipo: OctetString (48)

• Ambienti mutabili: 1TR

• Descrizione: Il valore coih è un hash SHA384 del manifesto Image4 di CustomOS. Il payload di tale manifesto è utilizzato da iBoot (al posto del kernel XNU) per trasferire il controllo. L’utente modifica il valore coih in modo implicito quando utilizza lo strumento a linea di comando kmutil configure-boot nella modalità 1TR.

UUID del gruppo di volumi APFS (vuid)

• Tipo: OctetString (16)

• Ambienti mutabili: 1TR, recoveryOS, macOS

• Descrizione: Il valore vuid indica il gruppo di volumi che il kernel deve utilizzare come root. Questo campo ha uno scopo principalmente informativo e non è utilizzato per misure di sicurezza. Il valore vuid viene impostato in maniera implicita dall’utente durante la creazione dell’installazione di un nuovo sistema operativo.

UUID di gruppo della chiave di codifica delle chiavi (kuid)

• Tipo: OctetString (16)

• Ambienti mutabili: 1TR, recoveryOS, macOS

• Descrizione: Il valore kuid indica il volume che è stato avviato. La chiave di codifica delle chiavi era tipicamente usata per la protezione dei dati. Per ciascun LocalPolicy, viene utilizzata per proteggere la relativa chiave per la firma. Il valore kuid viene impostato in maniera implicita dall’utente durante la creazione dell’installazione di un nuovo sistema operativo.

Misurazione della politica di avvio attendibile abbinata a recoveryOS (prot)

• Tipo: OctetString (48)

• Ambienti mutabili: 1TR, recoveryOS, macOS

• Descrizione: La misurazione della politica di avvio attendibile abbinata a recoveryOS è un calcolo hash SHA384 iterativo speciale effettuato sul manifesto Image4 di un LocalPolicy questo caso i valori anti-replay vengono esclusi per poter fornire una misurazione coerente nel tempo (dato che i valori anti-replay come lpnh vengono aggiornati frequentemente). Il campo prot, che si trova solo in ciascun LocalPolicy di macOS, indica quale LocalPolicy di recoveryOS corrisponde al LocalPolicy di macOS.

Verifica della firma di Secure Enclave al LocalPolicy di recoveryOS (hrlp)

• Tipo: Booleano

• Ambienti mutabili: 1TR, recoveryOS, macOS

• Descrizione: Il valore hrlp indica se il valore prot descritto in precedenza è la misurazione di un LocalPolicy di recoveryOS firmato da Secure Enclave oppure no. Se non lo è, il LocalPolicy di recoveryOS viene firmato dal server di Apple online, che firma elementi come i file Image4 di macOS.

Versione locale del sistema operativo (Local Operating System Version, love)

• Tipo: Booleano

• Ambienti mutabili: 1TR, recoveryOS, macOS

• Descrizione: love indica la versione del sistema operativo per cui il file LocalPolicy è stato creato. La versione è ottenuta dal manifesto dello stato successivo durante la creazione del file LocalPolicy e viene utilizzata per applicare le restrizioni all’abbinamento di recoveryOS.

Avvio multiplo protetto (smb0)

• Tipo: Booleano

• Ambienti mutabili: 1TR, recoveryOS

• Descrizione: Se smb0 è presente e vero, il bootloader di livello inferiore consente la firma del manifesto Image4 di fase successiva, invece che richiedere una firma personalizzata. Gli utenti possono modificare questo campo tramite Utility Sicurezza Avvio o tramite bputil per impostare il sistema su “Sicurezza ridotta”.

Avvio multiplo protetto (smb1)

• Tipo: Booleano

• Ambienti mutabili: 1TR

• Descrizione: Se smb1 è presente e vero, iBoot consente che oggetti come una raccolta del kernel personalizzata vengano firmati da Secure Enclave con la stessa chiave di LocalPolicy. La presenza di smb0 è un prerequisito per la presenza di smb1. Gli utenti possono modificare questo campo tramite strumenti a riga di comando come csrutil o bputil per impostare il sistema su “Sicurezza assente”.

Avvio multiplo protetto (smb2)

• Tipo: Booleano

• Ambienti mutabili: 1TR

• Descrizione: Se smb2 è presente e vero, iBoot consente che la raccolta del kernel ausiliaria venga firmata da Secure Enclave con la stessa chiave di LocalPolicy. La presenza di smb0 è un prerequisito per la presenza di smb2. Gli utenti possono modificare questo campo tramite Utility Sicurezza Avvio o tramite bputil per impostare il sistema su “Sicurezza ridotta” e consentire estensioni del kernel di terze parti.

Avvio multiplo protetto (smb3)

• Tipo: Booleano

• Ambienti mutabili: 1TR

• Descrizione: Se smb3 è presente e vero, un utente sul dispositivo ha accettato il controllo del sistema tramite una soluzione di gestione dei dispositivi mobili (MDM). La presenza di questo campo fa in modo che l’app del processore Secure Enclave che controlla LocalPolicy accetti l’autenticazione MDM invece di richiedere un’autenticazione dall’utente locale. Gli utenti possono modificare questo campo tramite Utility Sicurezza Avvio o bputil per abilitare il controllo gestito su estensioni del kernel di terze parti e aggiornamenti software. (In macOS 11.2 o versioni successive, una soluzione MDM può anche avviare un aggiornamento all’ultima versione di macOS se la modalità di sicurezza attuale è “Sicurezza totale”).

Avvio multiplo protetto (smb4)

• Tipo: Booleano

• Ambienti mutabili: macOS

• Descrizione: Se smb4 è presente e vero, il dispositivo ha accettato il controllo del sistema operativo da parte di una soluzione MDM tramite Apple School Manager, Apple Business Manager o Apple Business Essentials. La presenza di questo campo fa in modo che l’app del processore Secure Enclave che controlla LocalPolicy accetti l’autenticazione MDM invece di richiedere un’autenticazione dall’utente locale. Questo campo viene modificato dalla soluzione MDM quando rileva che il numero di serie di un dispositivo compare in uno dei tre servizi.

Protezione dell’integrità del sistema (sip0)

• Tipo: Intero non firmato di 64 bit

• Ambienti mutabili: 1TR

• Descrizione: Il valore sip0 contiene i bit esistenti della politica per la protezione dell’integrità del sistema, precedentemente archiviati nella NVRAM. I nuovi bit della politica per la protezione dell’integrità del sistema vengono aggiunti qui (invece di utilizzare i campi di LocalPolicy come quello sotto) se vengono usati solo in macOS e non vengono usati dal bootloader di livello inferiore. Gli utenti possono modificare questo campo tramite csrutil da 1TR per disabilitare la protezione dell’integrità del sistema e impostare il sistema su “Sicurezza assente”.

Protezione dell’integrità del sistema (sip1)

• Tipo: Booleano

• Ambienti mutabili: 1TR

• Descrizione: se sip1 è presente e vero, iBoot consente la verifica dell’hash root del volume di sistema firmato in caso di operazioni non riuscite. Gli utenti possono modificare questo campo tramite csrutil o bputil da 1TR.

Protezione dell’integrità del sistema (sip2)

• Tipo: booleano

• Ambienti mutabili: 1TR

• Descrizione: se sip2 è presente e vero, iBoot non bloccherà il registro hardware Configurable Text Read-only Region (CTRR) che contrassegna la memoria del kernel come non scrivibile. Gli utenti possono modificare questo campo tramite csrutil o bputil da 1TR.

Protezione dell’integrità del sistema (sip3)

• Tipo: Booleano

• Ambienti mutabili: 1TR

• Descrizione: se sip3 è presente e vero, iBoot non applicherà l’elenco integrato di elementi consentiti per la variabile della NVRAM boot-args, che altrimenti filtrerebbe le opzioni trasmesse al kernel. Gli utenti possono modificare questo campo tramite csrutil o bputil da 1TR.

Certificati e RemotePolicy

Come descritto in Creazione e gestione della chiave per la firma di LocalPolicy, il file Image4 di LocalPolicy contiene anche il certificato OIC (Owner Identity Certificate) e il RemotePolicy integrato.