1. Nem csinál /var/run/zorp dirt, ezért nem indul el 2. Nem dependel a python2.1-extclass-ra, anélkül meg nem találja az ExtensionCLass-t, a 2.2-extclass nem jó neki (arra viszont dependel), viszont fura parsing error-okat dobál az ellenség megtévesztésére ilyen formában: Jul 7 11:33:30 gemini intra[22825]: zorp version 2.0.4 starting up Jul 7 11:33:30 gemini intra[22825]: (noname/nosession): Error parsing policy file; filename='/etc/zorp/instances.py' Jul 7 11:33:30 gemini intra[22825]: (noname/nosession): Error booting & parsing policy; Jul 7 11:33:30 gemini intra[22825]: (noname/nosession): Error loading initial policy, exiting; Jul 7 11:33:30 gemini intra[22825]: zorp version 2.0.4 going down. Jul 7 11:33:30 gemini intra[22827]: (Log thread): ImportError: No module named ExtensionClass Jul 7 11:33:30 gemini intra[22827]: (Log thread): thread exiting; Jul 7 11:33:30 gemini intra[22830]: (conntrack/thread): thread exiting; -- Gabor HALASZ <halasz.g@freemail.hu>
On Mon, Jul 07, 2003 at 11:56:04AM +0200, Gabor Halasz wrote:
1. Nem csinál /var/run/zorp dirt, ezért nem indul el 2. Nem dependel a python2.1-extclass-ra, anélkül meg nem találja az ExtensionCLass-t, a 2.2-extclass nem jó neki (arra viszont dependel), viszont fura parsing error-okat dobál az ellenség megtévesztésére ilyen formában: a 2.0test-et hasznald, abban jo :)
asd -- Daniel VASARHELYI
Daniel VASARHELYI wrote:
a 2.0test-et hasznald, abban jo :)
Te meg nézd meg a dátumot :-D Rossz mailcímről írtam, és várt a moderátorra egy keveset :-D -- Gabor HALASZ <halasz.g@freemail.hu>
Ideje lesz feleleveníteni ezt a threadet... A 2.0.6-1.deb megint (még mindig?) nem csinál /var/run/zorp dirt, ezért nem indul el. echo 'var/run/zorp' >> debian/dirs Python gondjai is vannak bőven, majd részletezem azt is, de azt még tapogatnom kell egy kicsit, de az biztos, hogy ismét (még mindig?) rosszak a dependencyk. (python-extclass-ra dependel a python2.3-extclass helyett, az python extclass viszont csak 2.1 és 2.2 pythonnal megy)
Hi! [Én végig csak a Debian verzióról beszélek, a ZorpOs nem az én asztalom.] A levelezőm azt hiszi, hogy Gabor HALASZ a következőeket írta:
Ideje lesz feleleveníteni ezt a threadet...
A 2.0.6-1.deb megint (még mindig?) nem csinál /var/run/zorp dirt, ezért nem indul el. echo 'var/run/zorp' >> debian/dirs
ACK. drwxr-xr-x root/root 0 2003-10-22 23:16:32 ./var/run/zorp/ Így jó lesz? Szeretnéd tesztelni mielőtt felér a masterre? (Ami vélhetően nem is a 2.0.6.3-1-2 -vel fog megtörténni, hanem a 2.0.6.4-1 -el)
Python gondjai is vannak bőven, majd részletezem azt is, de azt még
Várom a részleteket, mert a python fele áll a szívemhez legközelebb. Apropos: tervezem, hogy külön veszem a döntési réteget, ami a gyakorlatban a python file-ok egy részét jelenti. Az a célom, hogy ha más döntési réteget akar az ember mint az upstream (pl nekem a mániám egy MAC policy implementálása), akkor csak csomagot cserél. Mi a véleményetek erről az ötletről?
tapogatnom kell egy kicsit, de az biztos, hogy ismét (még mindig?) rosszak a dependencyk. (python-extclass-ra dependel a python2.3-extclass helyett, az python extclass viszont csak 2.1 és 2.2 pythonnal megy)
Ez utóbbi kijelentésed számomra tévedésnek tűnik ( Package: python-extclass [...] Version: 1.2.0zope-2.5.1-1.3 Depends: python2.3-extclass (= 1.2.0zope-2.5.1-1.3), python (>= 2.3), python (<< 2.4) ), de megnézem, hogyan lehetne pontosabban kifejezni a függőséget. Te mit javallasz, mire dependáljak? -- GNU GPL: csak tiszta forrásból
On Wed, Oct 22, 2003 at 07:26:42PM +0000, Magosányi Árpád wrote:
Apropos: tervezem, hogy külön veszem a döntési réteget, ami a gyakorlatban a python file-ok egy részét jelenti. Az a célom, hogy ha más döntési réteget akar az ember mint az upstream (pl nekem a mániám egy MAC policy implementálása), akkor csak csomagot cserél. Mi a véleményetek erről az ötletről?
Orulnek neki, ha egy kicsit bovebben kifejtened ezt az elkepzelest. -- Udvozlettel Zsiga
2003-10-27, h keltezéssel Kosa Attila ezt írta:
On Wed, Oct 22, 2003 at 07:26:42PM +0000, Magosányi Árpád wrote:
Apropos: tervezem, hogy külön veszem a döntési réteget, ami a gyakorlatban a python file-ok egy részét jelenti. Az a célom, hogy ha más döntési réteget akar az ember mint az upstream (pl nekem a mániám egy MAC policy implementálása), akkor csak csomagot cserél. Mi a véleményetek erről az ötletről?
Orulnek neki, ha egy kicsit bovebben kifejtened ezt az elkepzelest.
A döntési réteg jelenleg azt csinálja, hogy a zónákban meg tudod mondani, hogy melyik service mehet be oda, és melyik jöhet ki onnan. Az amit én szeretnék, a következőekben tér el ettől: -a zónát nem csak IP cím, hanem IP cím és port alapján is meg lehet adni -a zónához szubjektumként (amikor onnan indul ki a kapcsolat) és objektumként (amikor oda megy be a kapcsolat) lehet különböző biztonsági attribútumokat rendelni -a biztonsági attribútumok között szerepel a biztonsági szint és a kategóriák. Nevezzük most ezeket információáramlási attribútumoknak. -a döntési réteg a kapcsolat engedélyezéséről az információáramlási attribútumok alapján a http://www.lme.hu/rendezvenyek/konferencia/2000/anyagok/magosanyi_a.pdf előadásban leírtak szerint. Van is egy deszkamodell implementációm, de nagyon lassú. Ugyanis az első bajuszhoz át kellett szabni a zóna osztályt, és nagyon hamar eljutottam ugyanahhoz a problémához, amitől a raytracer programok olyan sokat számolnak. -- GNU GPL: csak tiszta forrásból
On Mon, Oct 27, 2003 at 02:14:03PM +0100, Magosányi Árpád wrote:
2003-10-27, h keltezéssel Kosa Attila ezt írta:
On Wed, Oct 22, 2003 at 07:26:42PM +0000, Magosányi Árpád wrote:
Apropos: tervezem, hogy külön veszem a döntési réteget, ami a gyakorlatban a python file-ok egy részét jelenti. Az a célom, hogy ha más döntési réteget akar az ember mint az upstream (pl nekem a mániám egy MAC policy implementálása), akkor csak csomagot cserél. Mi a véleményetek erről az ötletről?
Orulnek neki, ha egy kicsit bovebben kifejtened ezt az elkepzelest.
A döntési réteg jelenleg azt csinálja, hogy a zónákban meg tudod mondani, hogy melyik service mehet be oda, és melyik jöhet ki onnan.
Az amit én szeretnék, a következőekben tér el ettől: -a zónát nem csak IP cím, hanem IP cím és port alapján is meg lehet adni
Tudnal mondani egy gyakorlati peldat, amikor ennek jelentosege van? Mert erzesem szerint a csomagszurovel tudom korlatozni, hogy mely portokat ne erje el egy adott gep egy adott zonaval kapcsolatban...
-a zónához szubjektumként (amikor onnan indul ki a kapcsolat) és objektumként (amikor oda megy be a kapcsolat) lehet különböző biztonsági attribútumokat rendelni
Jelenleg megmondhatom, hogy az adott zonaba milyen protokollon kapcsolodhat valaki (sok egyeb korlatozas mellett), es ellenorizhetem, hogy milyen parancsok juthatnak be a zonaba. Ekkor tudnom kell azt is, hogy egy adott parancsra milyen valasz johet, es ha nem felel meg, akkor nem engedem ki. Megprobalnad elmagyarazni, hogy milyen elonyoket remelsz a "biztonsagi attributumok" bevezetesetol, es milyen proxyk eseten latod, hogy lehet ezeknek szerepuk?
-a biztonsági attribútumok között szerepel a biztonsági szint és a kategóriák. Nevezzük most ezeket információáramlási attribútumoknak. -a döntési réteg a kapcsolat engedélyezéséről az információáramlási attribútumok alapján a http://www.lme.hu/rendezvenyek/konferencia/2000/anyagok/magosanyi_a.pdf előadásban leírtak szerint.
Elolvastam (es volt szerencsem eloben is meghallgatni az eloadast). De ismet az jutott eszembe, mint amit fentebb kerdeztem: milyen elonyok szarmaznanak ebbol? Kerlek, hogy valami kezzelfoghato peldan keresztul probald meg elmagyarazni, ne a matematika "egyszeru" nyelven :) Akar maganban is folytathatjuk, ha valaki ugy iteli meg, hogy offtopic a tema. -- Udvozlettel Zsiga
Hi! 2003-10-27, h keltezéssel Kosa Attila ezt írta:
-a zónát nem csak IP cím, hanem IP cím és port alapján is meg lehet adni
Tudnal mondani egy gyakorlati peldat, amikor ennek jelentosege van? Mert erzesem szerint a csomagszurovel tudom korlatozni, hogy mely portokat ne erje el egy adott gep egy adott zonaval kapcsolatban...
A filozófia egy kicsit más: nem azt adod meg, hogy melyik gép melyik portjai egy másik gép melyik portjait érjék el, hanem azt mondod meg, hogy a hálózaton melyik objektum/szubjektum milyen biztonsági besorolással bír. Az, hogy mi mit hogyan érhet el, az ebből következik, és innentől csak technikai részletkérdés. Mondok egy példát: Tegyük fel, hogy van néhányszor tíz hostod, amelyek némelyikén meghatározott besorolású adatok vannak, de vannak olyanok is, amelyeken többféle besorolás létezik, és a processz forrásportja szerint meg lehet mondani, hogy milyen besorolású. Mondjuk ezek a hostok több umbrella zónában helyezkednek el. Vagy felírod az egész hóbelevanc descartes szorzatát, vagy találsz valami értelmes leírási módot, hogy ne megabyte-okra rúgjon a policyd mérete. Nem árt ilyenkor, ha a leírási mód tükrözi a valós helyzetet. Képzeld el azt a helyzetet, amikor egy újabb objektumot veszel fel, vagy módosítasz. Nem mindegy, hogy egy helyen vagy n helyen kell átírnod.
-a zónához szubjektumként (amikor onnan indul ki a kapcsolat) és objektumként (amikor oda megy be a kapcsolat) lehet különböző biztonsági attribútumokat rendelni
Jelenleg megmondhatom, hogy az adott zonaba milyen protokollon kapcsolodhat valaki (sok egyeb korlatozas mellett), es ellenorizhetem, hogy milyen parancsok juthatnak be a zonaba. Ekkor tudnom kell azt is, hogy egy adott parancsra milyen valasz johet, es ha nem felel meg, akkor nem engedem ki. Megprobalnad elmagyarazni, hogy milyen elonyoket remelsz a "biztonsagi attributumok" bevezetesetol, es milyen proxyk eseten latod, hogy lehet ezeknek szerepuk?
Fentebb elmagyaráztam. Mindegyik proxy esetén van szerepe. Ha tudod, hogy melyik művelet melyik kategóriába tartozik (rwcf), akkor alkalmazni tudod rá a szabályokat.
-a döntési réteg a kapcsolat engedélyezéséről az információáramlási attribútumok alapján a http://www.lme.hu/rendezvenyek/konferencia/2000/anyagok/magosanyi_a.pdf előadásban leírtak szerint.
Elolvastam (es volt szerencsem eloben is meghallgatni az eloadast). De ismet az jutott eszembe, mint amit fentebb kerdeztem: milyen elonyok szarmaznanak ebbol? Kerlek, hogy valami kezzelfoghato peldan keresztul probald meg elmagyarazni, ne a matematika "egyszeru" nyelven :)
A tűzfal egyik funkciója, hogy az információáramlást szabályozza. Másképpen fogalmazva a szervezeti információáramlási politikát kell neki kikényszeríteni. Ez egy kötelező hozzáférésvezérlési politika, ugyanis jellegéből adódóan a szervezet minden információval foglalkozó mechanizmusában (nem csak IT) ki kell kényszeríteni ahhoz, hogy értelme legyen. A jelenlegi hálózati határvédelmi megoldások mindegyike (na majdnem mindegyik, hiszen létezik a DragonFly) ezt úgy oldja meg, hogy többé-kevésbé (kevésbé) hatékony eszközöket ad a tűzfaladminisztrátor kezébe, amelyekkel valamilyen választott hozzáférésvezérlési politikát lehet kikényszeríteni. A választott hozzáférésvezérlésből pedig úgy lesz kötelező hozzáférésvezérlés, hogy reménykedünk benne, hogy a tűzfaladminisztrátor 1. figyelembe vette az információáramlási modellt 2. rendelkezik a szükséges információkkal az egyes objektumok/ szubjektumok biztonsági tulajdonságairól. 3. az általa használt eszköz megfelelő az információáramlási politika betartatására 4. nem tévedett, vagy ha tévedett, akkor van valamilyen mechanizmus aminek segítségével a tévedés detektálható és javítható Végignézhetjük a fenti pontokat. 1. Elég ritka az, hogy létezik egyáltalán megfogalmazása az információáramlási modellnek olyan pontatlan kijelentéseken felül, mint hogy "a szervezet bizalmas adatait meg kell őrizni", vagy "a szervezet erőforrásait védeni kell az illetéktelen hozzáféréstől". Ezekből a kijelentésekből persze lehet több-kevesebb nehézséggel egy használható információáramlási politikát csinálni, de ritkán szoktak erre a szintre eljutni. A tűzfaladminisztrátorok ezért általában megérzésre szokták a szabályokat beállítani, és elég nehéz dolguk van akkor, ha egy szabály logikus voltát kell elmagyarázniuk valakinek, akit nem is érdekel a biztonság. 2. Amint egy rendszer túlnövi azt a méretet, hogy egyetlen ember képes legyen minden üzemeltetési és biztonsági aspektusát átlátni (tudok olyan példát mondani, ahol ez egyetlen PC-n sikerült:), ideális esetben a feladatok valamilyen elhatárolása fog megtörténni. Ez gyakran azzal jár, hogy a védelmi politika kikényszerítése és a biztonsági attribútumok ismerete nem egy fejben összpontosul. Ez a probléma jóval akutabb annál, mint amilyennek látszik: a biztonsági attribútumokat a rendszer felhasználója és fejlesztője/integrátora közösen határozzák meg, és a legtöbb esetben implicit módon, nem is tudva arról, hogy éppen ezt teszik. A tűzfal admin ezek után próbálkozhat azzal, hogy kiszedi belőlük az információt, de nehéz dolga van. Ezért segít az, ha a biztonsági attribútumok meghatározása egy explicit tevékenység, ami nélkül a rendszer nem funkcionál. 3. Amikor az ember bicskával próbál faházat építeni, nem túl egyszerű a dolga. A tűzfalak és a csomagszűrő routerek mindegyike bizonyos nagyon alapvető problémákat képes megoldani. Az információáramlási modell kikényszerítéséhez viszont pl rejtett csatorna redukciót kell végezni. A jelenlegi hálózati protokollok mellett erre a tűzfalnak úgy is kevés esélye van, ha minden protokollelemet képes kezelni. Ennek a célnak a Zorp sem jár a közelében, a többiek pedig nem is esélyesek rá. És akkor vedd ennek a konfigurációs overhead-jét. Nézzük meg, hogy a választott hozzáférésvezérlési politikára épülő konfigurációnál hol tartunk: N=hostok száma, K=védelmi szintek átlagos száma hostonként, P=protokollok száma, Q=protokollelemek átlagos száma protokollonként. A konfigurálandó dolgok hozzávetőleges száma: (N*K)*(N*K-1)/2*(P*Q) Itt a Q nagyjából 30 körül lehet, az első két tag pedig nagyjából a hostok négyzetével arányos. 10 hostnál és 5 protokollnál valami 7500 konfigurálandó dolgot kapunk elméleti értékként, de ez a gyakorlatban is lenne kb 3000. Ezt persze tudod különféle konfigurációs trükkökkel csökkenteni. Kb addig, amíg eljutsz ahhoz a koncepcióhoz, hogy ne a kapcsolatok leírására kelljen fókuszálni, hanem az objektumok/szubjektumok leírására. Hiszen a többi ennek függvénye. 4. Mindenki téved (nagy ritkán még én is szoktam;). Főleg ha 3000 dolgot kell bekonfigurálnia egy délután alatt. Ilyenkor segít az, ha kevés lehetőséget hagyunk a tévedésre. Pl a rendszer failsafe. Úgy tűnik, hogy valamely kapcsolat nem felel meg az információáramlási politikának? Tiltsa le a programlogika. A tűzfaladminnak így aránylag jó visszajelzése van: a felhasználó sírni fog, ha a kapcsolatra szükség van. A biztonsági attribútumok pedig kevesebben vannak, mint a tűzfalszabályok DAC esetén, így azokat átnézni sem bonyolult, sőt a zónahierarchiára épülő egyszerű szabályok (ilyenek a mostani Zorp kódban lévő öröklési szabályok is) egyszerűbbé teszik a hiba kiszűrését, vagy az átnézendő attribútumok számát csökkentik drasztikusan. Még egy előny: ha a feladatelhatárolás úgy szól, az attribútumok megfelelősége nem is a tűzfaladminisztrátor dolga. Egy gonddal kevesebb. -- GNU GPL: csak tiszta forrásból
On Mon, Oct 27, 2003 at 10:39:49PM +0100, Magosányi Árpád wrote:
2003-10-27, h keltezéssel Kosa Attila ezt írta:
-a zónát nem csak IP cím, hanem IP cím és port alapján is meg lehet adni
Tudnal mondani egy gyakorlati peldat, amikor ennek jelentosege van? Mert erzesem szerint a csomagszurovel tudom korlatozni, hogy mely portokat ne erje el egy adott gep egy adott zonaval kapcsolatban...
A filozófia egy kicsit más: nem azt adod meg, hogy melyik gép melyik portjai egy másik gép melyik portjait érjék el, hanem azt mondod meg, hogy a hálózaton melyik objektum/szubjektum milyen biztonsági besorolással bír. Az, hogy mi mit hogyan érhet el, az ebből következik, és innentől csak technikai részletkérdés. Mondok egy példát:
Az az igazsag, hogy nem igazan erzem a kulonbseget. Mennyiben konfiguralod maskent a csomagszurot, illetve a Zorpot, ha magasabb biztonsagi besorolassal biro adatokhoz szeretnel hozzaferest biztositani? Meg pontosabban: mit konfiguralsz maskent rajtuk?
Tegyük fel, hogy van néhányszor tíz hostod, amelyek némelyikén meghatározott besorolású adatok vannak, de vannak olyanok is, amelyeken többféle besorolás létezik, és a processz forrásportja szerint meg lehet mondani, hogy milyen besorolású. Mondjuk ezek
Ezzel meginkabb megkavartal :) Melyik processz forrasportja szerint akarod megallapitani, hogy milyen biztonsagi besorolasba tartozik? A szerver processzeknek viszonylag jol meghatarozott portszamaik vannak, a kliensek pedig a legtobb esetben 1023 folul jonnek.
a hostok több umbrella zónában helyezkednek el. Vagy felírod
Sosem szoktam umbrellat hasznalni, mert nekem atlathatatlanna teszi a konfiguralast. Sokkal nehezebben kovethetonek tartom a "mindent egy konfigfajlba" elvet. Inkabb szet szoktam szedni bizonyos szempontok alapjan a kulonbozo proxykat. Peldaul a dmz-be a net felol tarto kapcsolatokat egy policy fajlba teszem, a belso halorol a dmz-be tartoakat pedig egy masikba (es igy tovabb).
az egész hóbelevanc descartes szorzatát, vagy találsz valami értelmes leírási módot, hogy ne megabyte-okra rúgjon a policyd mérete. Nem árt ilyenkor, ha a leírási mód tükrözi a valós helyzetet. Képzeld el azt a helyzetet, amikor egy újabb objektumot veszel fel, vagy módosítasz. Nem mindegy, hogy egy helyen vagy n helyen kell átírnod.
A legtobb esetben ket helyen kell atirnom a dolgokat, a csomagszuro konfigjaban, illetve az adott zona policy fajljaban. Gyakorlatilag nincs olyan hely, ahol 10-nel tobb lenne a kulonbozo policy fajlok szama. Persze lehet, hogy tul egyszeru helyekkel foglalkozom :)
A tűzfal egyik funkciója, hogy az információáramlást szabályozza. Másképpen fogalmazva a szervezeti információáramlási politikát kell neki kikényszeríteni. Ez egy kötelező hozzáférésvezérlési politika, ugyanis jellegéből adódóan a szervezet minden információval foglalkozó mechanizmusában (nem csak IT) ki kell kényszeríteni ahhoz, hogy értelme legyen. A jelenlegi hálózati határvédelmi megoldások mindegyike (na majdnem mindegyik, hiszen létezik a DragonFly) ezt úgy oldja meg, hogy többé-kevésbé (kevésbé) hatékony eszközöket ad a tűzfaladminisztrátor kezébe, amelyekkel valamilyen választott hozzáférésvezérlési politikát lehet kikényszeríteni. A választott hozzáférésvezérlésből pedig úgy lesz kötelező hozzáférésvezérlés, hogy reménykedünk benne, hogy a tűzfaladminisztrátor 1. figyelembe vette az információáramlási modellt 2. rendelkezik a szükséges információkkal az egyes objektumok/ szubjektumok biztonsági tulajdonságairól. 3. az általa használt eszköz megfelelő az információáramlási politika betartatására 4. nem tévedett, vagy ha tévedett, akkor van valamilyen mechanizmus aminek segítségével a tévedés detektálható és javítható
Ismet csak azt kell mondanom, hogy nem ertem. Amikor nekem kell csinalni egy tuzfalat, akkor a legelso feladat az, hogy meg kell hatarozni, milyen adatokat szeretnenek elerni a tuzfalon keresztul, illetve ezek az adatok hol helyezkednek el. Ezt felrajzolva eleg jol lathatova valik, hogy honnan, merre, es milyen iranyu kapcsolatokat kell engedelyezni. Innentol pedig az egyes programok sajatossagainak megfeleloen zajlik a konfiguralas (peldaul spop3-hoz csak a 995-os portra kell odaengedni az 1023 folul erkezo klienst). Attol, hogy borzasztoan fontos adatok vannak a pop3 szerveren, meg nem tudom maskepp konfiguralni...
1. Elég ritka az, hogy létezik egyáltalán megfogalmazása az információáramlási modellnek olyan pontatlan kijelentéseken felül, mint hogy "a szervezet bizalmas adatait meg kell őrizni", vagy "a szervezet erőforrásait védeni kell az illetéktelen hozzáféréstől". Ezekből a kijelentésekből persze lehet több-kevesebb nehézséggel egy használható információáramlási politikát csinálni, de ritkán szoktak erre a szintre eljutni. A tűzfaladminisztrátorok ezért általában megérzésre szokták a szabályokat beállítani, és elég nehéz dolguk van akkor, ha egy szabály logikus voltát kell elmagyarázniuk valakinek, akit nem is érdekel a biztonság.
Munkambol adodoan ezt mindig meg kell csinalnom, egyszeruen nem tudom kihagyni ezt a lepest.
2. Amint egy rendszer túlnövi azt a méretet, hogy egyetlen ember képes legyen minden üzemeltetési és biztonsági aspektusát átlátni (tudok olyan példát mondani, ahol ez egyetlen PC-n sikerült:), ideális esetben a feladatok valamilyen elhatárolása fog megtörténni. Ez gyakran azzal
Nem talalkoztam meg olyan esettel, ahol a megfelelo dokumentalas ne oldotta volna meg ezt a helyzetet.
És akkor vedd ennek a konfigurációs overhead-jét. Nézzük meg, hogy a választott hozzáférésvezérlési politikára épülő konfigurációnál hol tartunk: N=hostok száma, K=védelmi szintek átlagos száma hostonként,
Probald mar meg korulirni, hogy mit ertesz vedelmi szinten egy gepen, legy szives.
P=protokollok száma, Q=protokollelemek átlagos száma protokollonként. A konfigurálandó dolgok hozzávetőleges száma: (N*K)*(N*K-1)/2*(P*Q) Itt a Q nagyjából 30 körül lehet, az első két tag pedig nagyjából a hostok négyzetével arányos. 10 hostnál és 5 protokollnál valami 7500 konfigurálandó dolgot kapunk elméleti értékként, de ez a gyakorlatban is lenne kb 3000. Ezt persze tudod különféle konfigurációs trükkökkel csökkenteni. Kb addig, amíg eljutsz ahhoz a koncepcióhoz, hogy ne a kapcsolatok leírására kelljen fókuszálni, hanem az objektumok/szubjektumok leírására. Hiszen a többi ennek függvénye.
Lehet, hogy ugyanarrol beszelunk, csak en nem tudomanyosan fogalmazom meg :)
4. Mindenki téved (nagy ritkán még én is szoktam;). Főleg ha 3000 dolgot kell bekonfigurálnia egy délután alatt. Ilyenkor segít az, ha kevés lehetőséget hagyunk a tévedésre. Pl a rendszer failsafe. Úgy tűnik, hogy valamely kapcsolat nem felel meg az információáramlási politikának? Tiltsa le a programlogika. A tűzfaladminnak így aránylag jó visszajelzése van: a felhasználó sírni fog, ha a kapcsolatra szükség van. A biztonsági attribútumok pedig kevesebben vannak, mint a tűzfalszabályok DAC esetén, így azokat átnézni sem bonyolult, sőt a zónahierarchiára épülő egyszerű szabályok (ilyenek a mostani Zorp kódban lévő öröklési szabályok is) egyszerűbbé teszik a hiba kiszűrését, vagy az átnézendő attribútumok számát csökkentik drasztikusan. Még egy előny: ha a feladatelhatárolás úgy szól, az attribútumok megfelelősége nem is a tűzfaladminisztrátor dolga. Egy gonddal kevesebb.
Ezt a bekezdest teljesen ertettem, bar nekem nem egyszerubb a zonahierarchia a kulonallo zonaknal, illetve policy fajloknal :) -- Udvozlettel Zsiga
Magosányi Árpád wrote:
Így jó lesz?
Biztosan
Szeretnéd tesztelni mielőtt felér a masterre?
Nem. Alapvetően nekem mindegy, én felrakom forrásból is; de ha valaki kipróbálja és el sem inddul, akkor nem biztos, hogy keresgélni fogja az okát, ilyesmivel kár rombolni a renomét.
Várom a részleteket, mert a python fele áll a szívemhez legközelebb.
Majd nekiesek délután, az biztos, hogy sidre felrakva fura hibaüzeneteket produkált (nem config hibának náztem első körben) és egy kicsit redundánsnak tűntek a telepített python csomagok. -- Gabor HALASZ <halasz.g@freemail.hu>
2003-10-27, h keltezéssel Gabor Halasz ezt írta:
Majd nekiesek délután, az biztos, hogy sidre felrakva fura hibaüzeneteket produkált (nem config hibának náztem első körben) és egy kicsit redundánsnak tűntek a telepített python csomagok.
Várom a részleteket. -- GNU GPL: csak tiszta forrásból
participants (5)
-
Daniel VASARHELYI
-
Gabor Halasz
-
Gabor HALASZ
-
Kosa Attila
-
Magosányi Árpád