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.
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
