Názory k článku
Podepisování jaderných modulů

...by asi melo byt scripts/bin2c.

Velmi pravdepodobne :) Dik, fixed

Bohuzel to porad trpi stejnou slabinou jako monoliticky kernel - pres /dev/mem muzu zmenit bud zabudovany verejny klic, nebo primo patricnou funkcionalitu. Ale jinak celkem zajimavy patch i clanek :-)

Takovymto pristupum, jako je ten popsany v clanku, se rika security through obscurity. Pristup nijak bezpecnost nezvysuje, pouze to dela pro utocnika slozitejsi. Jakmile bude vyvinut rootkit, ktery jadro zmeni pres /dev/mem (takove uz existuji) nebo jadro prepise na disku (pripadne primo pres /dev/hda, pokud souboru dame immutable flag), tak cely pristup ztraci smysl a pouze zbytecne komplikuje natahovani modulu.

Techniky security through obscurity funguji spolehlive pouze tehdy, pokud si takovou techniku clovek sam vyvine a pouziva. Pokud je verejna a neni moc rozsirena, tak funguje trochu. Pokud by takova technika byla pridana do nejake popularni distribuce, tak se okamzite objevi rootkit, ktery ji zlomi.

Dalsimi priklady security through obscurity je napriklad appendonly/immutable flag na filesystemu nebo zakazani spousteni kodu na zasobniku.

a je vubec /dev/mem potreba? pouziva to nekdo nebo neco? ted me nenapada zadny program, ktery by potreboval pristup k pameti pres soubor.

afaik X.
ale kdyz si tak clovek hraje s kernelem, tak se dostane treba k tomuhle patchi:
--- /usr/src/linux/drivers/char/mem.c Mon Apr 9 13:19:05 2001
+++ /usr/src/linux/drivers/char/mem.c Sun Nov 4 15:50:27 2001
@@ -49,6 +51,8 @@
const char * buf, size_t count, loff_t *ppos)
{
ssize_t written;
+ /* zakaz zapis do kmem */
+ return -EPERM;

written = 0;
#if defined(__sparc__) || defined(__mc68000__)

Ale tohle zakazuje jenom syscall write. Jeste musite zakazat mmap pro zapis. Pak musite zakazat pristup na porty, protoze pomoci neho se ruzna zarizeni daji primet k bus-masteringu do pameti. Pak musite zakazat pristup na blokove zarizeni, aby si utocnik kernel nemodifikoval na disku a nerebootoval.

Skutecne existuji distribuce Linuxu, ktere dokazi prezit kompromitaci roota, ale jsou pro bezne pouziti skoro nepouzitelne --- musi tam byt zakazany nejen vyse popsane veci, ale taky ptrace (co kdyz si utocnik ptracne syslog nebo sshd a pak s nimi bude neco vyvadet), kill (co kdyz zabije syslog nebo sshd a pusti si misto toho vlastni), shutdown (nebot ten potrebuje kill). Vsecky dulezite soubory (binarky, knihovny, startovaci skripty, kernel) musi byt immutable a pokud je clovek chce modifikovat, musi fyzicky prijit k pocitaci a nabootobat z diskety jiny kernel.

Odpovim trochu kacirskou myslenkou: Vsechna bezpecnostni opatreni jsou do urcite miry security through obscurity (STO), lisi se jen tou mirou.
Napriklad: Existuje-li v systemu dira umoznujici ziskat roota, pak jsou pristupova prava k souborum pouze STO...

Ve skole nas vzdycky ucili, ze system je mozne zabezpecit jen do urcite miry. Cim vice je zabezpecen, tim mene utocniku je schopno tyto ochrany prolomit. Je tedy potreba najit kompromis mezi cenou zabezpeceni, mirou zabezpeceni, vzniklou skodou atd.... A popsane reseni je jednim z moznych prostredku ke zvyseni zabezpeceni. Nic vic, nic min a take je to v clanku napsane...

Nesouhlasim s tim, ze system je mozno zabezpecit pouze do urcite miry. Pokud nebudete mit bugu v kernelu ani v suid programech ani v daemonech poustenych pod rootem, tak mate absolutni bezpecnost.

Ale lide radeji davaji prednost velkemu rychlemu systemu se spoustou featur, ktery neni bezpecny, nez malemu pomalemu bezpecnemu systemu, ktery toho moc neumi.

Vsechna bezpecnosti opatreni nejsou security through obscurity --- security through obscurity je technika, ktera zajistuje "bezpecnost" predpokladem, ze utocnik nema urcite znalosti o systemu, ktery napada. Funguje samozrejme presne do te doby, nez dany system zacnete prodavat verejnosti nebo ho vystavovat na internetu --- pak potrebnou znalost muze ziskat kdokoli.

Pokud chcete problem modulu resit jednoduseji pomoci security through obscurity, muzete proste zmenit cislo syscallu pro zavadeni modulu a programy insmod a modprobe prejmenovat na neco nenapadneho. Stejne jako kryptograficke podepisovani modulu --- to bude spolehlive fungovat pouze do te doby nez se takovy system nestane rozsireny.

Ad absolutni bezpecnost:
Pokud neni v systemu zadna bezpecnostni dira (a mame na to treba i formalni dukazy), pak vzdycky staci prijit s taskou/puskou/tankem a server fyzicky odvezt...

Ad pomaly-bezpecny vs slozity-nebezpecny
Dalsim faktorem (a ne nepodstatnym) je, jake funkce majitel systemu od systemu ocekava... System ktery nedela nic (=bezpecnost limituje ke zminene absolutni bezpecnosti :) ) asi moc prakticky neni. Opakuji a stojim si za tim, ze cele je to o hledani kompromisu bezpecnost/cena/mozne ztraty/pouzitelnost/atd....

Ad zmena cisla syscalu:
Tohle reseni ma dve nevyhody:
1) ona zmenena binarka musi byt uvedena ve spoustecich skriptech, ktere zavadeji potrebne moduly
2) pokud je potreba pouzivat automaticke zavadeni modulu, pak musi byt jadru znama a lze ji snadno zjistit (cat /proc/sys/kernel/modprobe)
Obe tyto omezeni pro podepisovani neplati, takze obe reseni srovnatelna nejsou :)

1) ona zmenena binarka musi byt uvedena ve spoustecich skriptech, ktere zavadeji potrebne moduly

-- zavadet moduly ve startovacich skriptech je kravina, protoze takove moduly je lepsi zakompilovat napevno - delaji to akorat distribuce, protoze tam se neda nic predpokladat o masine, na ktere to pobezi.

2) pokud je potreba pouzivat automaticke zavadeni modulu, pak musi byt jadru znama a lze ji snadno zjistit

-- automaticke zavadeni modulu na serverech potreba neni (a predpokladam, ze pokud se bavime o tomto stupni bezpecnosti, tak se nebavime o pracovnich stanicich).

Cele je to o tom, zad mit ci nemit monoliticke jadro.. Uvedene veci jsou potom jenom zprijemneni prace s moduly, ktere samozrejme u monolitickeho kernelu nemaji vyznam...

pokud nedefinujeme, co je to presne bezpecnost a absolutni bezpecnost, tak to, co jste rekl o absolutni bezpecnosti, muze byt velmi zavadejici. Asi stejne jako kdyz reknu, ze nejaka sifra ne nerozsifrovatelna.

Ja jen, abychom nezili v desiluzi:-)

Nesouhlasim s tim, ze system je mozno zabezpecit pouze do urcite miry. Pokud nebudete mit bugu v kernelu ani v suid programech ani v daemonech poustenych pod rootem, tak mate absolutni bezpecnost.

-- Muzes specifikovat podobnej system? Jeste jsem o necem podobnem neslysel :o))

Kdysi (v prvaku) jsem mel takovej napad udelat formalni dukazy korektnosti techto kodu (tim bych efektivne odstranil problem bezpecnosti a stability). Jenomze cloveka prejde chut, kdyz si zkusi takovej dukaz udelat pro 100 radku kodu a pak se mrkne na ty desetitisice :o)))

Opravte me, pokud se pletu, ale tohle je proste prakticky neresitelnej problem - vyzadovalo by to praci nekolika tisic lidi po nekolik let...

Co ja vim, tak se takove dukazy opravdu delaji pro nasazeni, kde je potreba maximalni bezpecnost... Dukaz takoveho systemu pak samozrejme stoji radove vic nez jeho vyvoj :) Ale vsechno to mam z doslechu a prednasek, v realu jsem to nikdy nevidel :(

Souhlasim ze jako bezpecnostni featura je to rozpacite. Nicmene mohlo
by to byt uzitecne treba pro nejaky podnik - na cilova zarizeni nebude
mozne nahrat "neoficialni" moduly, coz u nejakeho dalkove spravovaneho
black boxu muze byt sikovne...

at se snazim, jak se snazim, stale mam tuto neprijemnou hlasku v dmesg... vi o tom nekdo neco?

ksign: Installing public key data
Loading keyring
- Added public key xxx
- User ID: LKM key
>>> ksign: invalid packet (ctb=00)

A obsahuje key.h pouze verejny klic? A je ten klic DSA sign only? Mne chvili trvalo, nez jsem donutil GnuPG aby mi exportovalo jen ten spravny klic (pricitam to ale me nedostatecne znalosti GnuPG).
Kazdopadne jsem se s takovou hlaskou nesetkal, ale protoze soucasti patche je "orezane GnuPG", tak bych ocekaval, ze se do jadra dostala data, kterym nerozumi.
Na druhou stranu, do jadra je mozno naimportovat vic klicu, takze je mozne se prvni klic spravne zavedl a chyba nastala pri importu druheho baliku dat, ktery obsahuje neco jineho...

aaha... tam bude asi problem.. klic neni DSA only ;] generovany klic je "(1) DSA a ElGamal (implicitní)" :)

zkusim jen DSA.. dik za nakopnuti ;]

hmm.. tak tam problem nebyl :(

Mam dojem, ze v SRPM balicku s jadrem od Fedory je i skript, ktery klice vygeneruje a zapise do key.h . Nenapada mne jiny smer patrani, ja jsem v teto fazi nikdy na problemy nenarazil... Pripadne muzu mailem poslat muj testovaci key.h

Radek

zdravim,

no.. rozchodil jsem s DSA only klicem. Chybu v dmesg ovsem vidim porad.. ale funguje to.. tak nevim... ;)

kazdopadne dik ;]

Jak rikam, videl bych to na to, ze vyexportovanej soubor s klicem obsahuje krome vlastniho klice jeste neco jinyho.
Skoncil jsem tak, ze pro GnuPG vytvorim tmp adresar, nastavim mu ho jako gpghome, vytvorim klic, vyexportuju private a public key a adresar smazu. Osobne mi GnuPG/PGP nejak k srdci neprirostlo (subjektivni nazor).

Skusal niekto pls systrace?
http://www.systrace.org

V linuxu existuji "jaderne moduly"? Neni to moc nebezpecne? :)))