Dotaz: Je disk po instalaci opravdu zašifrovaný?

[-HOST-]

Ahoj, nainstaloval jsem na server Ubuntu 20.x, zvolil instalaci na cely disk, zasifroval cely disk. Po instalaci restartoval server, zadal heslo pro unlock disku a cekal az najede system. Nyni system najel a zastavilo se to na možnosti prihlaseni (byl jsem fyzicky u toho hw) ale ja se klavesnice ani nedotkl a najednou se zacaly vypisovat nejake jako by ssh klice nebo neco takoveho, trvalo to jen chvili. Neví někdo co to mohlo byt? Diky

Jsou ty disky opravdu zasifrovane?

sudo fdisk -l

Disk /dev/loop0: 48,92 MiB, 51277824 bytes, 100152 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop1: 28,7 MiB, 29433856 bytes, 57488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop2: 61,98 MiB, 64962560 bytes, 126880 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/nvme0n1: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 02175BAD-C72A-4EC8-95C1-8095869539C0


Device           Start      End  Sectors  Size Type
/dev/nvme0n1p1    2048  1050623  1048576  512M EFI System
/dev/nvme0n1p2 1050624  3147775  2097152    1G Linux filesystem
/dev/nvme0n1p3 3147776 41940991 38793216 18,5G Linux filesystem


Disk /dev/mapper/dm_crypt-0: 18,49 GiB, 19845349376 bytes, 38760448 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/ubuntu--vg-ubuntu--lv: 18,49 GiB, 19843252224 bytes, 38756352 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

---

---

Odpovědi

[Max]

"/dev/mapper/dm_crypt-0" značí zašifrovaný oddíl.
Pokud jsi byl v konzoli, kde to chtělo login a heslo, tak takovou věc můžou přepsat třeba nějaké hlášky z kernelu.
Příště to vyfoť a je možné ti říci více.
Zdar Max

[-HOST-]

Díky. Tak že jsem chtěl vytvořit jednu partition ale systém patrně nesouhlasil a vytvořil rovnou 8 partitions? a pouze jednu zašifroval? Ach jo.

[Max]

Ne, vytvořil tři:

/dev/nvme0n1p1    2048  1050623  1048576  512M EFI System
/dev/nvme0n1p2 1050624  3147775  2097152    1G Linux filesystem
/dev/nvme0n1p3 3147776 41940991 38793216 18,5G Linux filesystem

První je EFI, kde je základní boot (Windows to mají stejné). Druhá je 1GB pro bootloader a třetí je 18,5GB, nad kterou je vytvořený zašifrovaný luks "/dev/mapper/dm_crypt-0". A na tom zašifrovaném luksu je Ubuntu "/dev/mapper/ubuntu--vg-ubuntu--lv".
Zdar Max

[-HOST-]

Děkuji za objasnění

[Josef Kufner]

"nejake jako by ssh klice" mohl server při prvním spouštění vytvářet pro pozdější připojení přes ssh. Pravděpodobně se vytvářejí paralelně, skončily a vypsaly otisk pro ověření až po zobrazení loginu.

[Peter Golis]

Pokiaľ fdisk -l vypisoval

/dev/nvme0n1p3 3147776 41940991 38793216 18,5G Linux filesystem
Disk /dev/mapper/dm_crypt-0: 18,49 GiB, 19845349376 bytes, 38760448 sectors

Tak to vyzerá že máš klasické rozdelenie:

1. sda1 /boot/EFI
2. sda2 /boot
3. sda3 encrypted, na ktorom sa po odomknutí nájde LVM s jediným systémovým diskom a SWAPom

Skús sem hodiť výstup z príkazu:

lsblk |grep -v snap

Akurát by ma zaujímalo aký server má dnes tak malý 20G disk. To je nejaká hračka?

[-HOST-]

Taky díky, ten příkaz lsblk |grep -v snap už nespustím, nainstaloval jsem tam Debian 11.x, ten umí zašifrovat celý disk. K tomu disku 20GB, využívám jen cca 500 - 700 MB a menší jsem nesehnal.

[Peter Golis]

Debian a ani iný OS nedokáže naštartovať z kompletne zašifrovaného disku, Ak teda firmware nevie ten disk rozšifrovať disk. To ale nie je limitácia OS.

Ale NVMe disk o veľkosti 20G je pekná vec, kde to predávajú? Rád si také niečo kúpim ako prívesok.

[Fredy72]

Kompletně sice né, ale vyjma zavaděče ano.

[k3dAR]

v Debian instalatoru jde "naklepat" sifrovani vcetne /boot oddilu, resp. nepotrebuje si vytvaret oddelenej nesifrovanej oddil pro boot jako to dela *buntu, kdyz instaluju *buntu pripravim si sifrovanej disk bez oddeleneho boot sam

[-HOST-]

A prozradíš jak to děláš?

[Fredy72]

https://www.dwarmstrong.org/fde-debian/

[k3dAR]

Příloha:

• luksuntu-20210808.sh (20371 bytů)

uz sem prozradil, tady to zacalo aktualni davam do prilohy... na zacatku skriptu je hromadka promenej i s vysvetlivkama, snad jsou tam vse, po nastaveni tech promenejch podle sebe pustis skript z live pres sudo...

obecne jde o ukony:

- vytvorit na disku GPT
- oddil 1 cca 1MB, s priznakem bios_grub (pro pripadnej boot v legacy rezimu, pokud nehrozi neni treba vytvaret)
- oddil 2 cca 750MB-1GB s priznaky boot a esp (EFI oddil)
- oddil 3 zbytek

oddil 2 zformatovat jako FAT32, na oddil 3 vytvorit LUKS, na nem LVM, v nem minimalne LV rootfs a swap(pokud chces hibernovat), pripadne home, boot, var, ~atd
instalator pustit s parametrem -b aby neinstaloval zavadec, priradit LV prislusnejm "dir" pripojeni (rootfs jako / atd)
po dokonceni instalatoru nerestartovat, ale v /target/etc/default/grub pridat radek: GRUB_ENABLE_CRYPTODISK=y
provest chroot do /target (nutno pripravit chroot, instalator i kdyz nechas okno "restartovat nebo dale zkouset" tak odpojuje z target dev,dev/pts,proc,sys) a nainstalovat grub v uefi (a pripadne i legacy) rezimu... mozna sem na neco zapomel, pokud te zajima co se ma presne udelat a neches jen spustit ten skript, projdi si ho

[k3dAR]

zapomel sem uvest a Max mi to dole pripomel, pri rucni pripravce je LUKS potreva udelat ve verzi 1 volbou u crypsetup "--type=luks1"
v luksuntu skriptu to je v nastavovaci sekci uvedene:

# verze LUKS, Grub podporuje (zatim?) pouze verzi "luks1", od *buntu 19.10 je vychozi pri luksFormat "luks2", pro odemceni Grubem je NUTNO vynutit "luks1"
LUKS_VER="luks1"

[Peter Golis]

Až na drobnosť, EFI oddiel ktorý ostane nezašifrovaný.

[Fredy72]

V případě EFI ano, ale na něm je opět jen zavaděč.

[k3dAR]

nesifrovane EFI mi nevadi, misto Grubu pouzivam Sicherboot podepsanej vlastnima klicema a v UEFI odstranene vsechny ostatni

[Max]

Pokud člověk používá grub, tak ten má myslím v případě šifrovaného /boot omezení v tom, že nelze použít LUKS2, ale musí se použít LUKS1. Osobně jsem to nezkoušel, jen jsem o tom četl, myslím, že ArchWiki to má také zmíněné. Jak je to v případě Sicherboot?
Zdar Max

[k3dAR]

ze Grub2 nejde pouzit s LUKS2 potvrzuju, sicherboot sem s LUKS2 nezkousel...

[Josef Kufner]

Sicherboot umí to, co umí kernel.

[Max]

Pokud to správně chápu, tak se Sicherboot nemáš kernel na šifrované partition, ale přímo na EFI partition a prostě spoléháš na to, že je podepsaný a nikdo ti ho nemůže pod rukama změnit / podvrhnout?
Zdar Max

[Peter Golis]

Na to bol predsa vyvinutý Secure Boot, a Sicherboot je jeden z nástrojov na jeho správne použitie.

Ale lepšie by bolo, keby bol nejaký rozširujúci modul pre UEFI ktorý by zrušil potrebu mať nešifrovaný ESP oddiel. No ale to zatiaľ asi nie je ani pre Tiano. A vlastne to bola aj podstata otázky, či má celý disk zašifrovaný. Nemá, a asi ani nepotrebuje mať.

I keď mi stále vŕta hlavou ten 20G NVMe. Ona to asi bude len virtuálka na ktorej si to najlepšie vyskúša.

[k3dAR]

samozrejme by bylo lepsi kdyby UEFI dokazalo dotazat LUKS heslo a efi binarku zavadece si brat primo z LUKS :)
nicmene se sicherboot ses o 2 "stupne" na tom lepe, nez grub s /boot v luks (to by vyzadovalo aby utocnik do grub stage 1.5 naimplementoval krome keylogeru i podporu site a clienta pro odeslani hesla) nebo grub s /boot na nesifrovanem oddilu (tam utocnik naprosto snadno prebali initramfs s "keylogerem"(resp. prida radek do skriptu co se pta na luks heslo))

u sicherboot asi hrozi "jen" ze vynda/zkratne CMOS baterku v horsim pripade preflashne bios aby zrusil heslo do BIOSu a/nebo vypnul SecureBoot...

[Peter Golis]

U sicherboot a iných implementácií je ešte nejaké iné riziko. Ak si človek odzálohuje kľúče na kompromitovateľný disk, alebo zabudne vyhodiť tie čo tam boli pred tým. Alebo že má napadnuté UEFI ktoré nemusí kontroloxať podpis, aj keď to má nastavené. Toto posledné je už paranoia, ale človek nikdy nevie. Audit binárneho firmware je rovnako nemožný, ako audit vzdialeného prístupu cez MEI či ako sa volalo to KVM over IP s priamym prístupom do RAM a zvyšného HW.