Qual è la funzione "rootless" in El Capitan, davvero?

Ho appena appreso della funzione "Rootless" in El Capitan e sto ascoltando cose come "Non esiste un utente root", "Nulla può modificare /System" e "Il mondo finirà perché non possiamo ottenere root".

Qual è la funzionalità "Rootless" di El Capitan a livello tecnico? Cosa significa in realtà per l'esperienza dell'utente e l'esperienza degli sviluppatori? Funzionerà sudo -sancora e, in tal caso, come cambierà l'esperienza dell'uso di una shell root?

Primo: il nome "rootless" è fuorviante, poiché esiste ancora un account root e puoi ancora accedervi (il nome ufficiale "System Integrity Protection" è più preciso). Quello che fa davvero è limitare la potenza dell'account root, in modo che anche se diventi root, non hai il pieno controllo del sistema. Fondamentalmente, l'idea è che sia troppo facile per i malware ottenere l'accesso come root (ad es. Presentando una finestra di dialogo di autenticazione all'utente, che farà sì che l'utente inserisca di riflesso la password dell'amministratore). SIP aggiunge un altro livello di protezione, a cui il malware non riesce a penetrare anche se ottiene il root. La parte negativa di questo, ovviamente, è che deve applicarsi anche alle cose che stai facendo intenzionalmente. Ma le restrizioni che pone alla radice non sono poi così male; non impediscono la maggior parte "normale"

Ecco cosa limita, anche da root:

• Non è possibile modificare nulla in /System, /bin, /sbino /usr(tranne /usr/local); o una qualsiasi delle app e utility integrate. Solo l'aggiornamento dell'installer e del software possono modificare queste aree, e anche lo fanno solo quando installano pacchetti firmati Apple. Ma dal momento che le normali personalizzazioni in stile OS X vanno /Library(o ~/Library, o /Applications) e le personalizzazioni in stile unix (es. Homebrew) vanno /usr/local(o talvolta /etco /opt), questo non dovrebbe essere un grosso problema. Impedisce inoltre la scrittura a livello di blocco sul disco di avvio, quindi non è possibile ignorarlo in questo modo.

  L'elenco completo delle directory limitate (ed eccezioni come /usr/locale alcune altre) è disponibile /System/Library/Sandbox/rootless.conf. Naturalmente, questo file si trova in un'area riservata.

  Quando esegui l'upgrade a El Capitan, sposta tutti i file "non autorizzati" dalle aree riservate a /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/.

• Non è possibile collegarsi ai processi di sistema (ad esempio quelli in esecuzione da tali percorsi di sistema) per cose come il debug (o cambiare le librerie dinamiche che caricano o altre cose). Ancora una volta, non è un grosso problema; gli sviluppatori possono ancora eseguire il debug dei propri programmi.

  Questo blocca alcune cose significative come l'iniezione di codice nelle app Apple integrate (in particolare il Finder). Significa anche che dtracestrumenti basati sul monitoraggio del sistema (ad es. opensnoop) Non saranno in grado di monitorare e riferire su molti processi di sistema.

• Non è possibile caricare le estensioni del kernel (kexts) a meno che non siano firmate correttamente (ovvero da Apple o da uno sviluppatore approvato da Apple). Si noti che questo sostituisce il vecchio sistema per imporre la firma kext (e i vecchi modi per bypassarlo). Ma dalla v10.10.4 Apple ha avuto un modo per abilitare il supporto dell'assetto per SSD di terze parti , il motivo numero 1 per usare i kexts non firmati è scomparso.

• A partire da Sierra (10.12), alcune impostazioni di configurazione di launchd non possono essere modificate (ad esempio, alcuni daemon di lancio non possono essere scaricati).

• A partire da Mojave (10.14), l'accesso alle informazioni personali degli utenti (e-mail, contatti, ecc.) È limitato alle app che l'utente ha approvato per accedere a tali informazioni. Questa è generalmente considerata una funzionalità separata (chiamata protezione delle informazioni personali o TCC), ma si basa su SIP e disabilitando SIP la disabilita anche. Vedi: "Cosa e come implementa macOS Mojave per limitare l'accesso delle applicazioni ai dati personali?"

Se non vuoi queste restrizioni - o perché vuoi modificare il tuo sistema oltre ciò che ciò consente, o perché stai sviluppando e debug qualcosa come kexts che non sono pratici sotto queste restrizioni, puoi disattivare SIP. Attualmente ciò richiede il riavvio in modalità di ripristino e l'esecuzione del comando csrutil disable(e si può riattivare allo stesso modo con csrutil enable).

È inoltre possibile disabilitare in modo selettivo parti di SIP. Ad esempio, csrutil enable --without kextdisabiliterà la limitazione dell'estensione del kernel di SIP, ma lascerà le sue altre protezioni in atto.

Ma ti preghiamo di fermarti e pensare prima di disabilitare SIP, anche temporaneamente o parzialmente: hai davvero bisogno di disabilitarlo, o c'è un modo migliore (conforme a SIP) per fare quello che vuoi? Hai davvero bisogno di modificare qualcosa in /System/Libraryo /bino qualcos'altro, o potrebbe andare in un posto migliore come /Libraryo /usr/local/binecc? SIP può "sentirsi" vincolante se non ci si è abituati, e ci sono alcuni motivi legittimi per disabilitarlo, ma molte delle cose che lo impongono in realtà sono comunque solo le migliori pratiche.

Per sottolineare l'importanza di lasciare il maggior numero possibile di SIP il più spesso possibile, considera gli eventi del 23 settembre 2019. Google ha rilasciato un aggiornamento a Chrome che ha cercato di sostituire il collegamento simbolico da /vara /private/var. Sulla maggior parte dei sistemi, SIP ha bloccato questo e non ci sono stati effetti negativi. Sui sistemi con SIP disabilitato, ha reso macOS rotto e non avviabile. Il motivo più comune per disabilitare SIP era caricare estensioni del kernel non approvate (/ firmate in modo errato) (in particolare driver video); se avessero disabilitato solo la restrizione kext, non sarebbero stati interessati. Consulta la discussione di supporto ufficiale di Google , le domande e risposte di un superutente e un articolo Ars Technica .

Riferimenti e ulteriori informazioni: presentazione del WWDC su "Sicurezza e le tue app" , una buona spiegazione di Eldad Eilam su quora.com , la recensione di Ars Capitica su El Capitan e un articolo di supporto Apple su SIP , e un approfondimento di Rich Trouton ( che ha anche pubblicato una risposta a questa domanda ).

Per me, significa che DTrace non funziona più.

DTrace è simile a ptrace / strace in Linux, in quanto consente di vedere cosa sta dicendo un processo al kernel. Ogni volta che un processo vuole aprire un file, scrivere un file o aprire una porta, ecc., Deve chiedere al kernel. In Linux, questo processo di monitoraggio avviene al di fuori del kernel in "userland", e quindi i permessi sono abbastanza precisi. Un utente può monitorare le proprie applicazioni (per correggere bug, trovare perdite di memoria, ecc.) Ma dovrebbe essere root per monitorare il processo di un altro utente.

DTrace su OSX funziona tuttavia a livello di kernel, rendendolo molto più performante e potente, tuttavia richiede l'accesso root per aggiungere le sue sonde nel kernel e quindi fare qualsiasi cosa. Un utente non può tracciare i propri processi senza essere root, ma come root può non solo guardare i propri processi, ma in realtà TUTTI i processi sul sistema contemporaneamente. Ad esempio, puoi guardare un file (con iosnoop) e vedere quale processo lo legge. Questa è una delle funzionalità più utili di sempre per rilevare malware. Poiché il kernel si occupa anche dell'IO di rete, lo stesso vale qui. Wireshark rileva attività di rete insolite, DTrace ti dice il processo di invio dei dati, anche se è integrato nel sistema come il kernel stesso.

A partire da El Capitan, tuttavia, Apple ha deliberatamente impedito a DTrace di funzionare, in quanto è stato specificamente preso di mira e individuato come qualcosa che SIP limita. Perché dovrebbero farlo? Bene, in precedenza Apple ha modificato il proprio kernel e DTrace per consentire ad alcuni processi di non essere monitorati tramite DTrace (che all'epoca turbava molti ricercatori sulla sicurezza poiché alcuni processi erano ormai off-limits anche come root - incluso il malware). La loro ragione era di proteggere il DRM in app come iTunes poiché teoricamente qualcuno poteva DTrace e catturare dati non-DRM dalla memoria dei processi.

Tuttavia, c'è stato un importante work-around che ha permesso ai ricercatori di continuare a fare il loro lavoro, e che è stato quello di modificare il kernel per ignorare questo flag di opt-out, quindi DTrace poteva ancora essere usato su questi processi. Questo è stato davvero fantastico perché i programmi che cercano di eludere il rilevamento sono ora illuminati con questo flag no-DTrace. Qualunque cosa Apple o i cattivi volessero nascondere ora era in bella vista ...

Ma non funziona ora, quindi in che modo questo ti influenza? Bene, ti influenzerà sia direttamente che indirettamente. Direttamente, limiterà la tua capacità di monitorare il tuo sistema. Un gran numero di strumenti di amministrazione e monitoraggio del sistema di basso livello (su cui si basano gli strumenti di livello superiore) non funzionerà più. L'effetto indiretto sarà tuttavia molto più grande: i professionisti della sicurezza fanno affidamento sull'accesso al sistema per rilevare i peggiori tipi di minacce. Semplicemente non possiamo più farlo. È fondamentale durante l'analisi del malware che non sa che è in esecuzione in un debugger o honeypot. La disabilitazione di SIP dice a tutti i software, sia dei cattivi che di Apple, che questo sistema è sotto controllo. Non più guardare gli osservatori. Se SIP riguardava la sicurezza, avrebbero potuto istruire gli utenti sulla radice, invece l'hanno rimossa. In definitiva, ciò significa che Apple ha sostituito la barriera di sicurezza "be all and end all" della password di root, con il meccanismo di protezione SIP "be all and end all". O se sei bravo in ingegneria sociale, una password di root con un riavvio ...

C'è anche questo:

System Integrity Protection (SIP) è una politica di sicurezza globale con l'obiettivo di impedire che file e processi di sistema vengano modificati da terzi. Per raggiungere questo obiettivo, ha i seguenti concetti:

• Protezione del file system
• Protezione dell'estensione del kernel
• Protezione runtime

Protezione del file system

SIP impedisce alle parti diverse da Apple di aggiungere, eliminare o modificare directory e file archiviati in determinate directory:

/bin
/sbin
/usr
/System

Apple ha indicato che le seguenti directory sono disponibili per gli sviluppatori:

/usr/local
/Applications
/Library
~/Library

Tutte le directory in /usreccetto per /usr/localsono protette da SIP.

È possibile aggiungere, rimuovere o modificare file e directory protetti da SIP tramite un pacchetto di installazione firmato dall'autorità di certificazione di Apple. Ciò consente ad Apple di apportare modifiche alle parti del sistema operativo SIP protette senza dover modificare le protezioni SIP esistenti.

L'autorità di certificazione in questione è riservata da Apple per uso proprio; I pacchetti di installazione firmati con ID sviluppatore non sono in grado di modificare file o directory protetti da SIP.

Per definire quali directory sono protette, Apple ha attualmente definito due file di configurazione sul filesystem. Quello principale si trova nella posizione seguente:

/System/Library/Sandbox/rootless.conf

dove rootless.confelenca tutte le applicazioni e il livello superiore delle directory che SIP protegge.

applicazioni

SIP protegge le app principali installate da OS X in Applicazioni e Utilità applicazioni. Ciò significa che non sarà più possibile eliminare le applicazioni installate da OS X, anche dalla riga di comando quando si utilizzano i privilegi di root.

Elenchi

SIP protegge anche un numero di directory e collegamenti simbolici al di fuori /Applicationse anche il livello superiore di tali directory è elencato in rootless.conf.

Oltre alle protezioni, Apple ha anche definito alcune eccezioni alla protezione di SIP nel file rootless.conf e tali eccezioni sono contrassegnate da asterix. Queste esenzioni dalla protezione di SIP significano che è possibile aggiungere, rimuovere o modificare file e directory all'interno di tali posizioni.

Tra queste eccezioni ci sono le seguenti:

• /System/Library/User Template - dove OS X memorizza le directory dei modelli che utilizza durante la creazione di cartelle home per nuovi account.
• /usr/libexec/cups - dove OS X memorizza le informazioni di configurazione della stampante

Apple considera questo file come loro e che eventuali modifiche di terze parti verranno sovrascritte da Apple.

Per vedere quali file sono stati protetti da SIP, utilizzare il lscomando con trattino O nel Terminale:

ls -O

I file protetti con SIP saranno etichettati come limitati .

Una cosa importante da sapere è che anche se un collegamento simbolico è protetto da SIP, ciò non significa necessariamente che la directory a cui si stanno collegando sia protetta da SIP. A livello di root di un'unità di avvio di El Capitan per OS X, esistono diversi collegamenti simbolici protetti da SIP che puntano a directory memorizzate nella directory di livello principale denominata private.

Tuttavia, quando privatevengono esaminati i contenuti della directory, le directory a cui fanno riferimento tali collegamenti simbolici non sono protette da SIP e sia loro che i loro contenuti possono essere spostati, modificati o modificati da processi che utilizzano i privilegi di root.

Oltre all'elenco delle eccezioni SIP che Apple ha impostato rootless.conf, esiste un secondo elenco di eccezioni SIP. Questo elenco include una serie di directory e nomi di applicazioni per prodotti di terze parti. Simile a rootless.confquesto elenco di esclusione è di Apple e le eventuali modifiche di terze parti verranno sovrascritte da Apple.

/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

Protezione runtime

Le protezioni di SIP non si limitano a proteggere il sistema dalle modifiche al filesystem. Ci sono anche chiamate di sistema che ora sono limitate nella loro funzionalità.

• task_for_pid () / processor_set_tasks () non riesce con EPERM
• Le porte speciali Mach vengono ripristinate su exec (2)
• le variabili di ambiente dyld vengono ignorate
• Sonde DTrace non disponibili

Tuttavia, SIP non blocca l'ispezione da parte dello sviluppatore delle proprie applicazioni durante lo sviluppo. Gli strumenti di Xcode continueranno a consentire l'ispezione e il debug delle app durante il processo di sviluppo.

Per maggiori dettagli, ti consiglio di dare un'occhiata alla documentazione per sviluppatori Apple per SIP .

Protezione dell'estensione del kernel

SIP blocca l'installazione di estensioni del kernel senza segno. Per installare un'estensione del kernel su OS X El Capitan con SIP abilitato, un'estensione del kernel deve:

1. Essere firmato con un ID sviluppatore per la firma del certificato Kexts
2. Installa in / Libreria / Estensioni

Se si installa un'estensione del kernel senza segno, SIP dovrà prima essere disabilitato.

Per ulteriori informazioni sulla gestione di SIP, dai un'occhiata al link seguente:

Protezione dell'integrità del sistema: aggiunta di un altro livello al modello di sicurezza di Apple