Firma / Checksumming del kernel per prevenire / rilevare manipolazioni

8

Tutte le mie partizioni sono crittografate ( /e /home), ma la /bootpartizione deve rimanere non crittografata ed è aperta alla manipolazione. Stavo pensando di eseguire l'hashing del kernel all'avvio e di verificare il risultato rispetto a un valore memorizzato (generato durante la compilazione, salvato sul mio disco crittografato) per vedere se qualcuno, in qualche modo, ha manipolato il kernel dall'ultimo avvio (forse anche fisicamente). C'è un problema con la scrittura di una tale sceneggiatura? Ci sono già programmi che lo fanno?

kernel security encryption

— SkaveRat
fonte

6

Quello che stai cercando - verificare che il sistema operativo in esecuzione sul computer sia quello di cui ti fidi - si chiama avvio sicuro . (È una delle molte cose che a volte vengono chiamate avvio attendibile). Il metodo proposto non raggiunge questo obiettivo.

La crittografia non fornisce integrità o autenticità dei dati . In altre parole, non impedisce a un utente malintenzionato di modificare il contenuto del disco e sostituirlo con un sistema operativo dannoso. Questo sistema operativo dannoso potrebbe essere facilmente programmato per mostrare il checksum previsto per il kernel caricato.

Il percorso di attacco più semplice è un man-in-the-middle in cui l'attaccante esegue il tuo normale sistema operativo sotto una sorta di macchina virtuale. Il livello della macchina virtuale trasmette l'input al sistema operativo desiderato e trasmette l'output. Ma registra anche i tasti premuti (mmmm, password) sul lato, snoop le chiavi private dalla memoria del sistema operativo e così via.

Per evitare questa forma di attacco, devi avere una radice di fiducia : un componente del sistema di cui ti fidi per un motivo diverso da quello che dice qualche altro componente del sistema. In altre parole, devi iniziare da qualche parte. Iniziare con l'hardware in tuo possesso è un buon inizio; potresti mantenere il tuo sistema operativo su una chiave USB che non lasci la vista e collegarlo solo all'hardware di cui hai abbastanza fiducia (l' hardware può avere malware !). Mente, se sei disposto a fidarti del computer, potresti fidarti anche del suo disco rigido.

Esiste una soluzione tecnica per colmare il divario tra la fiducia di un piccolo chip e la fiducia di un intero computer desktop o laptop. Alcuni PC dispongono di un TPM (modulo di piattaforma attendibile) che può, tra l'altro, verificare che sia possibile avviare solo un sistema operativo noto. Trusted Grub supporta i TPM, quindi con un TPM più Trusted Grub, puoi avere la certezza che il kernel che stai eseguendo è uno che hai approvato.

Nota che l'adozione del TPM può funzionare a tuo favore o contro di te. Tutto dipende da chi ha le chiavi. Se hai la chiave privata per il tuo TPM, puoi controllare esattamente cosa gira sul tuo computer. Se solo il produttore ha la chiave privata, è un modo per trasformare una piattaforma per scopi generici in un'appliance bloccata.

— Gilles 'SO- smetti di essere malvagio'
fonte

+1 per il riferimento a un grande potenziale trabocchetto del TPM (aka Treacherous Computing)

— Eli Heady

Non fornisci soluzioni reali , menziona solo frasi popolari relative alla sicurezza. Quello che dici di un attacco MITM è una minaccia che ignora l'idea principale della domanda del PO: Usare uno script di verifica del checksum che consente al sistema di avviarsi solo se sono soddisfatte determinate condizioni. A quel punto, non ci sarebbe alcuna problema nel verificare che l'hardware sottostante effettivo è quello che dovrebbe essere, non una VM.

— rozcietrzewiacz,

-1

Il kernel avviato si trova in memoria. Puoi creare uno script che lo localizzerà /dev/meme, conoscendo la dimensione, calcolerà e verificherà il suo checksum.

Puoi anche avere l'intero HD crittografato, senza bisogno di /bootpartizioni e (quasi) nessun modo per modificare il kernel. Come? due modi in cui posso pensare:

Posiziona il kernel su un CD, al di fuori del quale verrà avviato il computer. Questo non è così difficile; alcune persone hanno riferito di aver usato tale configurazione diversi anni fa - vedi il secondo post in questo thread del forum .
Se la tua scheda madre è supportata da coreboot e ha spazio sufficiente per contenere un kernel minimo, potresti avere un kernel abilitato alla crittografia sul tuo chip BIOS. (Non ho avuto la possibilità di testare, ma non vedo alcun motivo per cui questo potrebbe non funzionare.)

Modifica: si noti che tutti questi sono solo singoli passi verso l' avvio "attendibile" o "verificato" (che Gilles ha giustamente indicato). Il meccanismo completo dovrebbe anche tenere conto di ciò che sta accadendo nella fase del bootloader e di come viene identificato l'hardware sottostante. Dai un'occhiata a come funziona Google Chromium OS .

— rozcietrzewiacz
fonte

Funzionerà? Non ne sono sicuro; Non so a caso se il kernel modifica il suo codice in memoria dopo l'avvio. So che non puoi verificare un modulo in quel modo, perché il modulo è collegato al kernel (cambiando alcuni indirizzi qua e là) quando viene caricato. Fornirà le proprietà di sicurezza desiderate? No, vedi la mia risposta. L'integrità è complicata!

— Gilles 'SO- smetti di essere malvagio' il

Sembra che tu non abbia letto tutta la mia risposta. Il primo paragrafo, a cui si fa riferimento, è solo una risposta diretta a ciò che è stato realmente chiesto. Il resto della mia risposta presenta opzioni simili al metodo che hai menzionato, ma meglio , perché sono sicure contro la modifica del kernel (a differenza di una chiavetta USB).

— rozcietrzewiacz,

@Gilles Hai dimenticato di "@" nel commento precedente. Inoltre, ho appena verificato ciò di cui non sei sicuro: ha fatto un dump dell'immagine del kernel in memoria, quindi ha aggiunto un gruppo di moduli, ha fatto un secondo dump della regione, confrontato - lo stesso. È possibile utilizzare questo.

— rozcietrzewiacz,