/dev/mem (was: SucKIT)

[Karel Zak]

On Wed, Mar 27, 2002 at 05:40:49PM +0100, Pavel Kankovsky wrote:
> On Tue, 26 Mar 2002, Karel Zak wrote:
> 
> >  Proc potrebuje nejaky program _celou_ pamet kernelu? Nebylo by
> >  cistejsi mit nejake blize specifikovane API?
> 
> Mozna bylo. Ale problem je v tom, ze se to pouziva pro primy pristup
> k hw zarizenim (napr. graficke karte), a lepsi zarizeni (jak napr. lepsi
> graficke karty) vetsinou umi nejake DMA a podobne veci, takze ten, kdo
> chce skodit, si stejne pristup ke zbytku fyzicke pameti zaridi.

 Snad by bylo v silach jadra hlidat kam v tech souborech (pameti) kdo
 leze (pise) a nektere casti napr. sys_call_table ohodnotit SIGKILL
 pro dany program. Nevim do jadra nedelam...

 Problem veci jako je SickKIT je, ze v idelanim pripade, ze ten kit
 neopsahuje zadny bug tak ho nemuzete detekovat.

> On Tue, 26 Mar 2002, Jirka Kosina wrote:
> 
> > Sorry, to jsem se uklepl - psal jsem /dev/kmem a myslel jsem /dev/mem. 
> > Sypu si /dev/random na hlavu ;)
> 
> Rozdil mezi /dev/mem a /dev/kmem neni moc vyznamny, protoze v obou je
> videt cela fyzicka pamet (snad krome nulove stranky), akorat v kmem jsou
> navic (pri cteni) videt i jaderna virtualni pamet alokovana pres
> vmalloc().
> 
> > Kdyby fungovaly v kernelu nejak rozumne capability (o coz se mimo jine 
> > prave LIDS snazi), tak by to bylo celkem jednodusse resitelne - procesum, 
> > ktere to skutecne nezbytne potrebuji, by se (za predpokladu, ze by 
> > neexistovalo zadne API) proste pridelila CAP_SYS_RAWIO, a hotovo.
> 
> Primy pristup na I/O je v principu stejne nebezpecny, jako primy pristup
> do pameti jadra (resp. fyzicke pameti). What's the point?

 Jde o to co je to "nebezpecne", jde pomoci toho nerusene odposlouchavat
 hesla a poslat tak do kytek svet uzasneho sifrovaciho software? Nebo
 je ta nebezpecnost v tomto pripade jen v moznost neco znicit?

        Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz