Hardening Time Machine Security

Aggiornamento dopo discussione con bmike (vedi sotto)

Durante un effettivo Time Machine Backup, backupd monta due condivisioni. / Volumi / Qualunque e / Volumi / Backup di Time Machine. Mentre il primo non può essere accessibile da un utente non root, quest'ultimo può. È infatti possibile cancellare ACL dei file e sovrascriverli successivamente. Quindi il problema di sicurezza è completamente aperto.

Risposta originale

Pensando un po 'di più al sistema di montaggio sottostante, sono giunto alla conclusione che la mia domanda originale contenesse un'ipotesi errata, la cui rimozione rende forse la domanda obsoleta. Ho deciso di scrivere una risposta invece di rimuovere la domanda per il beneficio del malinteso.

Quando ho controllato le autorizzazioni dei miei file sparsebundle, ho montato manualmente il disco Time Capsule. Poiché ho montato il disco come utente normale, questo utente è diventato il proprietario del punto di montaggio (verificando nel terminale, posso vedere che il mio account utente è il proprietario del punto di montaggio, "staff" è il gruppo).

Ora la mia ipotesi (che non era trasparente per me) era che se Time Machine montava il disco durante una sessione di backup, sarebbe presente nel sistema come se l'avessi montato manualmente. Ma questo è sbagliato. Poiché backupd viene eseguito come root, il punto di mount appartiene a root (controllare il terminale, il proprietario è "root", il gruppo è "wheel", group e world non hanno diritti.) E quindi un processo appartenente a un utente normale non sarebbe in grado di crittografare i file su un Time Machine Disk montato da backupd .

Quindi, in una configurazione di Time Capsule non sembra esserci, per il momento, il rischio di un ransomware di crittografare il backup. Tuttavia, potrebbe essere diverso con un hard disk esterno collegato localmente. Ricordo vagamente che quando usavo ancora un hard disk esterno, potevo vedere la partizione di Time Machine montata in Finder (qualcosa che non ho adesso) e quindi potrebbe essere montata con diritti utente. Non posso testarlo perché non ho un hard disk esterno della macchina del tempo, ma forse qualcun altro può dire qualcosa al riguardo.

I backup di Time Machine sono principalmente protetti da ACL che nega il permesso a chiunque di scrivere su un file.

$ ls -le /Volumes/Whatever/Backups.backupdb/Mac/Latest/Macintosh\ HD/Users/me/Desktop/file.text 
-rw-r--r--@ 1 me    staff  - 14 Mar  8 11:54 /Volumes/Whatever/Backups.backupdb/Mac/Latest/Macintosh\ HD/Users/me/Desktop/file.text
0: group:everyone deny write,delete,append,writeattr,writeextattr,chown

Affinché un programma dannoso possa modificare un file nel sottosistema di backup, dovrebbe prima leggere ed eliminare qualsiasi ACL e quindi sarebbe in grado di apportare una modifica a un file salvato nella directory di Time Machine.

$ chmod -a# 0 /Volumes/Whatever/Backups.backupdb/Mac/Latest/Macintosh\ HD/Users/me/Desktop/file.text 

Dopo il comando precedente, il file è aperto alle modifiche o alla cancellazione definitiva.

Il codice del programma non avrebbe bisogno di alcun accesso root speciale - solo che è stato eseguito da un normale utente admin per apportare questa modifica e quindi essere in grado di scrivere sui file.

Né sandboxing né System Integrity Protection fermerebbero qualsiasi processo dannoso eseguito come amministratore dalla crittografia / modifica / eliminazione di file di dati utente su un'unità di backup montabile (unità di rete) o collegata e già montata.

Per rafforzare i backup, è necessario disporre di una copia offline in un modo o nell'altro presumendo che l'attore malintenzionato sappia controllare e modificare / rimuovere ACL prima di manometterli.

Guarderei oltre le opzioni di crittografia per proteggere alcuni file che non ti puoi permettere un programma casuale e non puoi memorizzare la chiave di crittografia per un secondo volume di backup nel tuo portachiavi.

• Crittografia / protezione dell'unità di backup Time Machine?

In questo modo, la prima destinazione di backup potrebbe essere eseguita spesso ma vulnerabile al malware. La seconda destinazione ti richiederebbe ogni due settimane circa in modo che non sia aggiornata se non la monti e avvia un backup più manuale.

Non è l'ideale, ma presumerei che Apple potrebbe riprogettare il sistema se questo potenziale rischio diventa più di un rischio effettivo nel tempo su OS X. L'unica cosa che risparmia il gatekeeper e il codice firmato è che il malware più diffuso è, più è probabile che Apple lo impedisca di girare su macchine che optano per la protezione di Gatekeeper. In questo caso, sembra che siano trascorse meno di 48 ore dall'annuncio pubblico della minaccia al rimedio per renderlo disponibile su Apple.