zfs + geli + dropbear

[Dan Lukes]

On 01/09/12 14:45, Honza Klokanek Sipek:
> dik. vicemene to jsem potreboval slyset.

Tak ja si budu chvili premyslet nahlas.

Chapu, ze pred pripadnym zlodejem, ktery uloupi disk a odnese ho chranis 
"uzivatelska data". Ale nevidim smysl v ochrane /bin nebo /sbin - u toho 
stejne vsichni vedi co v nich mas.

Pokdu se snad bojis, ze by pripadny zlodej disk vytahnul z pocitace jen 
na chvilku a pak ho vratil s pozmenenymi binary (aby se tka dostal k 
uzivatelskym datum), no je potreba videt, ze schopny zlodej ti v takovem 
pripade predevsim proste vymeni kernel. A ten, jak vime, sifrovanej byt 
nemuze.

A kdyz budu chtit bejt svine, tak ti tam dokonce vymenim BIOS - ono to 
neni az tak slozite, a v ramci zavadeni si misto tveho /boot/loader 
natahnu muj /boot/loader - a ten navic bud tahat z tech par cylindru, 
ktere na konci kazdeho disku skoro vzdycky zbudou. Vubec o tom nebudes 
vedet. Klidne si ze sveho /boot/loader klidne pocitej checksumy to je mi 
uplne fuk.

Tim chci rict, ze urcite veci v soucasne chvili proste nevyresis bez 
zajisteni fyzicke bezpecnosti. V tom smyslu, ze vstupu utocnika k 
serveru nemuzes dokonal zabranit - takze uzitecna data jsou sirovana, 
ale musis byt schopen takovy neopravneny vstup alespon zdetekovat - a v 
takovem pripade povazovat stroj za uspesne napadeny a neduveryhodny i 
kdyz se nic neztrati a podle vseho tam ten divnej pan neudelal vubec nic.

K cemu smeruju ? Pokud mas uzivatelska citliva data na vyhrazenem 
svazku, kteru lze moutovat jako "late" tak ej tvoej uloha v podstate 
trivialni - v dobe mountovani "late" disku je uz sit k dispozici. Staci 
tomu predradit jeden sript, ktery nejak sezene to heslo, ktere prislusny 
svazek potrebuje.


Rekneme ale, ze jsem neco prehledl, a ma skutecne nejaky rozumny smysl 
sifrovat i vseobecne znama data.

Jednu cestu uz jsem naznacil - jenze - to znamena uplne prevorat 
soucasny rc.d subsystem (zmenit poradi). Nejenze je to prace pro vraha v 
tomhle okamziku a ohromnu prostor k ruznejm chybam. Ale taky to ze 
systemu dela obtizne udrzovatelny unikat. Po nejblizsim upgrade to budes 
muset cele delat znovu. Nebo ten system neaktualizovat - oboji nevypada 
lakave.

Takze jinak. Co si takhle na zacatku jen vymenit /etc/rc - v nem si 
nainicializovat sitovku, spustit to ssh, prevzit heslo, predat ho geli, 
smazat konfiguraci site (protoze standardni start by se s 
nakonfigurovanou siti nemusel srovnat dobre) a spustit puvodni /etc/rc

To je podstatne min prace.

Furt jsem ale prepsal standardni systemovy soubor /etc/rc a pokud si pri 
upgradu nedam pozor, prepise se mi zpatky a zas to bude v coudu.

Takze nakonec bych mozna preci jen napsal vlastni "init".

No, napsal, no, vlastni - to jsou trochu silny slova. Vzal bych 
originalni zdrojak a provedl dve upravy ve funkci runcom() - zaprve bych 
spoustel svuj script misto /etc/rc a za druhe bych pri uspesnem skonceni 
nevolal read_ttys ale docela obycejne bych execnul originalni "init" (i 
s puvodnimi parametry). A jeste nesmime zapomenout na "single user mode" 
- coz obnasi zakomentovani radku "initial_transition = single_user;"

Zbyva jen v loader.conf nastavit kernelu v environmentu promennou 
init_path a tim zajistit, ze se spusti ten "muj" init, ktery spusti 
"muj" script - ten at si dela co chce, hlavne at ot na konci uvede do 
puvodniho stavu, protoze "muj" init v te chvili preda rizeni 
standardnimu initu a vse uz pojede v klasickych kolejich. A ani vitr, 
ani mraz a ani pitomec co mi tam pripadn eudela upgrade (vcetne me) to 
nerozbije, protoze pri upgrade se ani muj init ani muj startovaci script 
neprepise - a odkaz na nej v loader.conf taky ne. A zbytek systemu je ve 
"standardnim" stavu, tudiz bezne udrzovatelny obvyklym zpusobem ...

Toz ja bych to delal si takhle nejak. Tedy, pomineme-li uplny uvod, kde 
vysvetluju, proc bych to takhle nedelal vubec ...

Pisu to "z ruky" - nemam v umyslu to delat, takze se tam mohou objevit 
jeste nejake ty zadrhelicky ...

Dan

>>> ze /boot musi zustat nesifrovany, je jasne.
>>> ale maximum ostatniho (urcite /var, /usr, nejlepe i /sbin a /bin) bych mel
>>> rad sifrovane (geli a na nem zfs).
>>> otazka je, jak to udelat, aby se mi v _co nejrannejsi_ fazi bootu pustil
>>> ssh daemon, treba staticky slinkovany dropbear, spolu treba s busyboxem,
>>> ktery by mi umoznil pripojit se a dat kernelu heslo k pripojeni zbytku.