Difendendosi dalla malvagia cameriera, come gestire la rimozione della partizione / boot

Quando si utilizza la crittografia del disco completo LUKS, come si farebbe per proteggersi dalle donne malvagie ?

Il malvagio attacco da cameriera è quando qualcuno ottiene l'accesso fisico al tuo computer mentre sei assente e compromette la partizione non crittografata / di avvio per acquisire la tua password FDE al prossimo avvio del computer

Una delle soluzioni è quella di lasciare la partizione / boot su una chiavetta USB che è sempre con te (la cameriera non riesce ad accedervi), ma quale filesystem dovrei usare su di essa e come posso configurare il mio sistema per gestire con grazia la rimozione della chiavetta USB (e quindi la partizione / boot stessa)?

Sto usando CentOS, ma le risposte generiche e distro-agnostiche sono certamente benvenute. Grazie.

Finalmente capito. Questo sembra ancora molto confuso e sporco perché il sistema non è mai consapevole del fatto che /bootpotrebbe non essere montato e dovrai montarlo manualmente prima di fare qualsiasi cosa che possa scrivergli (pensa agli aggiornamenti di sistema, ecc.), Ma a parte questo funziona perfettamente .

• preparare l'unità flash con una singola partizione con il flag di avvio impostato su di esso. È possibile eseguirlo shred -n 1 -v /dev/sdXper cancellarlo completamente, inclusi eventuali settori di avvio precedenti; una volta fatto, esegui fdiskper creare una partizione e il mkfstuo filesystem preferito su di essa.
• monta la tua chiavetta USB da qualche parte, /mnt/booto addirittura /newbootfarà bene.
• spostati su tutto dall'unità /bootflash con mv /boot/* /newboot.
• modifica il tuo /etc/fstabe cambia l'UUID della partizione di avvio originale (o crea una voce se non ce n'è) per abbinare quella della tua unità flash. È possibile ottenere l'UUID con lsblk -o name,uuid. Aggiungete anche l' noautoopzione in modo che l'unità non venga montata automaticamente per poterla rimuovere non appena il sistema inizia l'avvio (una volta caricato il kernel) senza rischiare di corrompere l'FS su di esso.
• smontare la partizione di avvio originale e l'unità flash ( umount /boot && umount /newboot) e montare l'unità flash; se la tua voce fstab è corretta, puoi semplicemente eseguirla mount /boote la monterà automaticamente in base all'UUID specificato in fstab.
• rigenera la configurazione del tuo bootloader per riflettere gli UUID della nuova partizione e la posizione "fisica", per GRUB l'unità flash apparirà effettivamente come il primo disco rigido nel computer ( hd0). Se stai bene usando gli script di configurazione di GRUB predefiniti forniti dalla maggior parte delle distribuzioni, puoi eseguire grub-mkconfig -o /path/to/grub.cfge genererà il file in base alle partizioni attualmente montate e / o fstab. Si noti che per CentOS 7, il corretto grub.cfgsi trova effettivamente in /boot/grub2/grub.cfg.

Quando si esegue qualsiasi operazione che può accedere alla partizione di avvio, collegare la chiavetta USB ed eseguire mount /boot. Una volta fatto, puoi correre umount /boot. Si noti che il completamento di quest'ultimo comando può richiedere alcuni minuti perché sta scaricando i buffer sul disco (il disco stesso è lento, quindi il kernel memorizza alcune operazioni di scrittura per velocizzare le cose).

Un altro approccio a questo particolare problema consiste nell'utilizzare il TPM per archiviare una chiave di crittografia, ma la difesa si basa sull'utente per renderla efficace. Una soluzione rudimentale basata su RHEL7 è tpm-luks ( https://github.com/GeisingerBTI/tpm-luks ).

Il modo in cui funziona è all'avvio, ogni fase del processo di avvio misura la successiva e memorizza questa misura nelle PCR sul TPM. Una volta completato il processo di avvio, tpm-luks verifica lo stato delle PCR rispetto a una configurazione "noto buono". Se in una configurazione "noto", il TPM annullerà la chiusura della chiave LUKS e tpm-luks passerà questi dati per sbloccare la partizione LUKS radice.

Poiché tutto ciò che è importante viene misurato con un hash crittografico, essenzialmente non c'è modo per una cameriera malvagia di sostituire il tuo GRUB / kernel / ramdisk per raccogliere in modo nefasto la tua passphrase FDE. Come bonus aggiuntivo, non hai bisogno di una passphrase FDE! In teoria potresti rimuovere completamente la passphrase leggibile dall'uomo e fare affidamento interamente su tpm-luks, ma se segui questa strada, è probabilmente una buona idea archiviare l'intestazione LUKS e conservarla come backup.

Come ho già detto, ciò richiede una certa diligenza per l'utente. Se hai lasciato il computer incustodito e ti viene presentato un prompt di passphrase, è probabilmente una cattiva idea digitarlo fino a quando non hai fatto alcune indagini. A quel punto, dovresti avviare un ambiente live CD e dare un'occhiata per vedere se c'è un bug in tpm-luks o se la /bootpartizione è stata veramente modificata. Stai ancora lasciando la /bootpartizione non crittografata, ma se qualcosa di importante viene alterato, il disco principale non viene mai decrittografato.