[Sipi]

Idézet: YleGreg - Dátum: 2015. 02. 18. 13:13

Ezt kéne meglépni win alatt is, a hyper-v integrálásával taáln van is rá lehetõség, - nem ismerem annyira a windowst hogy lássam mi mindent kéne változtatni ehhez, és hogy meg fog-e történni, van-e erre igény Redmont szerint.

A Linux iskolapéldája a monolitikus kernelnek. A Windows viszont az NT óta már elment a mikrokernel irányába.

[YleGreg]

@Sipi: Szóval szerinted van arra lehetõség, hogy gyárilag úgy legyen, vagy be lehessen konfigurálni azt, hogy az a kernel amin a GUI szolgáltatás fut, ne lássa a hálózatot, míg a GUI-t igénybe vevõ browsert futtató kernel lásson ki az internetre, de ne lássa azokat a fileokat amiket a GUI futtatásához használ az elõzõ kernel?

Vagyis képessé lehet tenni a programok teljes szeparációjára, hogy ha az egyik program (mondjuk a browser, vagy a pdf olvasó) egy exploit miatt NTAUTHORITY/SYSTEM jogosultságokat szerez, akkor se tudjon egyetlen másik alkalmazáshoz (mondjuk a mellette futó levelezõklienshez) hozzáférni, valamint a filerendszer azon részeihez se, amik nem szükségesek a mûködéséhez, teszem azt a etc/hosts filehoz?

[iasatan]

@YleGreg: A windows phone kb ezt tudja(sandboxban fut minden program), szidja is mindenki, mert ezt meg azt nem tud(/ott)

[auth.gabor]

@iasatan: "A windows phone kb ezt tudja(sandboxban fut minden program)"

Nahát... Android és iOS esetén is. És?

[YleGreg]

@iasatan: A Windows Phone és az asztali Windows kódja között szerintem kicsi az átfedés, így én most nem mennék el telefon irányába, engem a sima, közönséges, asztali Windows érdekel, elvégre a laptopomra nem igazán akarok Windows Phone -t telepíteni...

A sima, "nagy" windows az mennyire képes a szeparációra?

No offense, ha van rá kényelmes mód, azt szeretném használni.

Jelenleg amit ismerek az az, hogy VirtualBox -ba (vagy tetszõleges virtualizációs megoldással) telepítem azokat a gépeket amiket használok, ezeket kibridgelem a hálókártyára, a host gépnek meg nullás ip címet adok, így onnan nem megy ki és nem jön be semmi.
Jelenleg a windowst így használom ha csak lehet, de ez kényelmetlenebb mint amilyen lehetne, - szerintem.

[Sparow2]

Idézet: YleGreg - Dátum: 2015. 02. 18. 13:13

Nekem az egy vékonyabb (butább, egyszerûbb) kernel és az onnan kiinduló szeparált rendszerek alkotta architektúra szimpatikusabb, mert a hibák/támadások egy része ki sem tud alakulni, mert a malware számára nem állnak rendelkezésére a szükséges erõforrások, mint például hálózati kapcsolat (abban a gépben ami a vinyókat kezeli) vagy IO elérés a diskek felé (abban a gépben ami kilát az internetre) vagy úgy egyáltalán merevlemez (abban a gépben amiben megnyílik a PDF viewer).
Külön-külön minden van, nekem a szemem elõtt egymás melletti ablakokban ott van minden mint egy windowsban, de ezek a részek soha nem kerülnek egy címtér, egy kernel, egy userspace fenhatósága alá.

Ettől függetlenül hogy a diszk nem beépített diszk, hanem egy külön SAN, NAS vagy akármi, attól még ugyanúgy lehet rá írni az adott gépnek kiajánlott részre.

[Sparow2]

Idézet: YleGreg - Dátum: 2015. 02. 18. 16:48

@Sipi: Szóval szerinted van arra lehetõség, hogy gyárilag úgy legyen, vagy be lehessen konfigurálni azt, hogy az a kernel amin a GUI szolgáltatás fut, ne lássa a hálózatot, míg a GUI-t igénybe vevõ browsert futtató kernel lásson ki az internetre, de ne lássa azokat a fileokat amiket a GUI futtatásához használ az elõzõ kernel?

Vagyis képessé lehet tenni a programok teljes szeparációjára, hogy ha az egyik program (mondjuk a browser, vagy a pdf olvasó) egy exploit miatt NTAUTHORITY/SYSTEM jogosultságokat szerez, akkor se tudjon egyetlen másik alkalmazáshoz (mondjuk a mellette futó levelezõklienshez) hozzáférni, valamint a filerendszer azon részeihez se, amik nem szükségesek a mûködéséhez, teszem azt a etc/hosts filehoz?

Persze, lehet külön memóriatérben futtatni az alkalmazásokat, sőt, alapból úgy is futnak.
A filerendszer beli jogosultságok az már más téma. Ott őgy kell beállítani az adott file jogosultságait, hogy az lássa, akik futtat (pl. root).

[mzso]

Idézet: YleGreg - Dátum: 2015. 02. 18. 13:57

@mzso: "Ja ott közvetlenül a kernelbe annyi rejtett kiskaput építenek amennyit csak akarnak...
Fölösleges ilyesmivel szarakodni."

Így van, pont ezért van sokkal több kártevõ linuxra mint bármi másra, és ez a cucc is azért fut linuxon ugyanúgy mint windowson, mert igazad van. Ugye? Vagy valahol tévedek?

Mivel lófasz sem használja így nem csoda, hogy kevés kártevő van rajta. Az NSA meg valószínüleg úgy járkál ki-be ahogy akar a linuxodon. Csak nem fogsz tudni róla.

[YleGreg]

@mzso: " ... Az NSA meg valószínüleg úgy járkál ... "

Azt én pont lekakilom.
Az NSA-val megegyeztem egy külön háttéralku keretében: Én nem érdeklem õket, és õk sem érdekelnek engem.

Ami engem érdekel az a sima, hétköznapi, söréttel lövünk tipusú támadások, mint például a legutóbbi ransomware. Ezek ellen keresem a legkényelmesebb, de mégis hatásos védekezést.

[YleGreg]

@Sparow2: "Persze, lehet külön memóriatérben futtatni az alkalmazásokat, sõt, alapból úgy is futnak."

Ez jól hangzik, de ez még nem elég.

Ha egy alkalmazás SYSTEM jogosultsággal bír, akkor simán elkérhet a kerneltõl bármi olyat amivel az a kernel rendelkezik. Például portot nyithat. Vagy létrehoz egy felhasználót. Vagy letölt és letesz egy dll-t, majd újraindít egy szolgáltatás ami ezt a dll-t használja, és ezzel máris befolyásolta a többi program mûködését.

Szóval, az ellen hogyan védekezünk ha egy program jogosultságemelést* ér el, majd olyan kódot futtat** amit belé injektáltak***?

Ha egy kernelünk van és azt már korrumpálták**** akkor mit ér az, hogy a többi programot külön memóriatérben futtatja a kernel?

Természetesen nem azt mondom, hogy a linux vagy akármi az sérthetetlen, nem akarok elmenni ebbe az irányba.
Azt szeretném tudni, hogy a security by isolation mûködhet-e windows alatt effektívebben, mint ahogy most (szerintem nem igazán) mûködik.

* google keresés "windows exploit remote privilege escalation": 347 ezer találat
** google keresés "windows remote code execution": 1.7 millió találat
*** google keresés "windows remote code injection": 19 millió találat
**** google keresés "windows kernel local exploit": 480 ezer találat
Ezek szerint történtek már ilyenek, elég nagy számban, így én valószínûsítem, hogy történni is fognak még.

[Sparow2]

Idézet: YleGreg - Dátum: 2015. 02. 18. 18:39

@Sparow2: "Persze, lehet külön memóriatérben futtatni az alkalmazásokat, sõt, alapból úgy is futnak."

Ez jól hangzik, de ez még nem elég.

Ha egy alkalmazás SYSTEM jogosultsággal bír, akkor simán elkérhet a kerneltõl bármi olyat amivel az a kernel rendelkezik. Például portot nyithat. Vagy létrehoz egy felhasználót. Vagy letölt és letesz egy dll-t, majd újraindít egy szolgáltatás ami ezt a dll-t használja, és ezzel máris befolyásolta a többi program mûködését.

Szóval, az ellen hogyan védekezünk ha egy program jogosultságemelést* ér el, majd olyan kódot futtat** amit belé injektáltak***?

Ha egy kernelünk van és azt már korrumpálták**** akkor mit ér az, hogy a többi programot külön memóriatérben futtatja a kernel?

Természetesen nem azt mondom, hogy a linux vagy akármi az sérthetetlen, nem akarok elmenni ebbe az irányba.
Azt szeretném tudni, hogy a security by isolation mûködhet-e windows alatt effektívebben, mint ahogy most (szerintem nem igazán) mûködik.

* google keresés "windows exploit remote privilege escalation": 347 ezer találat
** google keresés "windows remote code execution": 1.7 millió találat
*** google keresés "windows remote code injection": 19 millió találat
**** google keresés "windows kernel local exploit": 480 ezer találat
Ezek szerint történtek már ilyenek, elég nagy számban, így én valószínûsítem, hogy történni is fognak még.

A jogosultságemelés kernel hiba eredménye. (Vagy root jogosultsággal futó hibás felhasználói szoftver eredménye, ilyen is volt már sok.)
Kernelhiba ellen semmi nem véd 100%-osan. "Az ellen nem véd."
Maximum ha külön virtuális gépben fut minden, amit el akarunk különíteni egymástól.

Szerkesztette: Sparow2 2015. 02. 18. 18:48 -kor

[YleGreg]

@Sparow2: "Kernelhiba ellen semmi nem véd 100%-osan. ... Maximum ha külön virtuális gépben fut minden, amit el akarunk különíteni egymástól."

Pont errõl beszélek.
Hogy túl nagy _a_ kernel, túl sokat akar tudni, és emiatt könnyebben támadható mint _több_ butább, egyszerûbb kernel, amelyek a valódi, felhasználói programokat hostolnák.

Na, szóval hogyan lehet ezt elérni a legkényelmesebben windowson, hogy minden (nyílván értelmesen csoportosítva) külön virtuális gépen fusson?
Amit ha kompromittál (nem "ha", hanem "amikor" ugye) akkor nem kompromittálja az egész gépet, csak azt az egy virtuális gépet?

[lolwut]

mi minden rendelkezik update-elhetõ firmware-el? processzor, bios, rooter, egyebek...
szép világ, mondhatom

[lolwut]

ja és a linux ezért van tele annyi buggal, hogy ne tudd, mikor crashel backdoortól. nem reszponzív a gnome? szándékos félrefejlesztés, a vak is láthatja

[Sparow2]

Idézet: YleGreg - Dátum: 2015. 02. 18. 19:21

@Sparow2: "Kernelhiba ellen semmi nem véd 100%-osan. ... Maximum ha külön virtuális gépben fut minden, amit el akarunk különíteni egymástól."

Pont errõl beszélek.
Hogy túl nagy _a_ kernel, túl sokat akar tudni, és emiatt könnyebben támadható mint _több_ butább, egyszerûbb kernel, amelyek a valódi, felhasználói programokat hostolnák.

Na, szóval hogyan lehet ezt elérni a legkényelmesebben windowson, hogy minden (nyílván értelmesen csoportosítva) külön virtuális gépen fusson?
Amit ha kompromittál (nem "ha", hanem "amikor" ugye) akkor nem kompromittálja az egész gépet, csak azt az egy virtuális gépet?

Hát pl. vmWare Player. Vagy akármilyen virtuális gép.
De ha a hostot törik meg, akkor eleve bukók lehetnek a virtuális gépek is, hiszen az image file-juk a hoston elérhető, akár olvashatő/írható is lehet a kártevőnek. Persze ez csak elmélet most.

Ha 100% biztonságot akarsz, akkor nem kapcsolod be a számítógépet. Sőt, kihúzod az áramot, a hálózatot, és bezárod egy péncélszekrénybe.
Vagy inkább eladod és eliszod az árát, jobban jársz

[Sparow2]

Idézet: lolwut - Dátum: 2015. 02. 18. 20:33

mi minden rendelkezik update-elhetõ firmware-el? processzor, bios, rooter, egyebek...
szép világ, mondhatom

Ma már gyakorlatilag minden kicsit értelmesebb periféria: videókártya, hálókártya, alaplap, diszkek és optikai tárolók, némelyik nyomtatók, de még pendrive-ok is.

A processzorból kiesik a firmware update kikapcsoláskor. A BIOS tölti bele. Mondjuk a BIOS-t ha megtörik, akkor minden bekapcsoláskor beletölti. Viszont nehéz kivitelezni, mert a CPU firmware valami titkosított, aláírt fileban van, nem egyszerű hamisítani.

Egyébként nincs itt olyna nagy probléma, majd kitalálnak erre is valamit.
Anno a 80-as évek elején még szinte minden plain text-ben ment, egy-két incidens miatt találták ki pl. az SSH-t is.

A nehézég ott van, hogy ahány gyártó, annyi fajta firmware kell hozzá. Plusz még azon belül is minden verzió más és más lehet, pl. egy alaplaphoz ha van 15 firmware update, simán lehet nem mindhez működik egy adott kártevő, mert más a firmware gépi kódja.

[Sipi]

Idézet: YleGreg - Dátum: 2015. 02. 18. 16:48

@Sipi: Szóval szerinted van arra lehetõség, hogy ...

Nem tudom, nem vagyok ennyire otthon a Win kernelfelépítésében, csak arra írtam, hogy a vékonyabb, egyszerűbb kernelfelépítés a szimpatikusabb.

Szerkesztette: Sipi 2015. 02. 18. 21:56 -kor

[Sparow2]

Idézet: lolwut - Dátum: 2015. 02. 18. 20:35

ja és a linux ezért van tele annyi buggal, hogy ne tudd, mikor crashel backdoortól. nem reszponzív a gnome? szándékos félrefejlesztés, a vak is láthatja

HAHAHAHA
Gyula-e vagy?

[Sipi]

Idézet: Sparow2 - Dátum: 2015. 02. 18. 21:52

A processzorból kiesik a firmware update kikapcsoláskor.

Processzorokban mióta van firmware?

[iasatan]

@YleGreg:

http://www.sandboxie.com de ezer meg egy sandbox program van windowsra is