kéretlen magyarázat: OpenVPN, fork(), exec(), ioctl()

Ehhez a szálhoz szeretnék egy külön posztot fűzni, mert Gabu és Pontscho szerintem nem magyarázták meg elég érthetően a dolgot -- természetesen nem állítom, hogy értek a dologhoz annyira, mint ők, de a részletesebb magyarázat azért hasznos lett volna; így teszek egy kísérletet. Javításokat köszönettel fogadok. (Ha Gabut ingerküszöbét eléri, akkor remélem majd a blogján...)

A kérdés: miért baj az, hogy az OpenVPN hálózati konfigurációra ELF binárisokat hívogat, viszonylag hordozható szintaxissal, ahelyett, hogy platformfüggő ioctl()-eket, vagyis kernelhívások körüli vékony libc wrapper-eket hívna?

A válaszhoz nézzük meg felületesen, hogy mi történik egyik és másik esetben. Az ioctl() esetében a libc minimális pofozgatást végez a paramétereinken (legrosszabb esetben), aztán a kernel megteszi (vagy elutasítja), amit kérünk. Ezek az ioctl()-ek nagyrészt "fókuszált", kis hatáskörű primitívek.

A fork()/execve() kombóval hívott bináris egy kicsit hosszabb utat jár be (holott a végcélunk ugyanaz). Először is, mindkét függvény irdatlan tömegű és kiterjedésű kernelkódot tornáztat meg. Berángatja a filesystem-et is (exec()!), berángat egy párhuzamosan futó, velünk bizonyos erőforrásokon osztozó gyerekprocesszt (fork() -- lásd fd-k, versenyhelyzetek), és ami a legrosszabb, berángat egy jókora adag, tőlünk független userspace kódot (ifconfig, ip, route, és így tovább). Lényegében ami UNIX rendszer-erőforrás van, azt megrángatjuk. Vagyis óriási vargabetűt teszünk ugyanazon végcél érdekében, amelynek már csak a teljesítményvonatkozása sem elhanyagolható.

Itt két elv (-csoport) áll egymással szemben. Az egyik a forráskód hordozhatósága, a másik pedig a: { pontos működés hordozhatósága, hatékonyság, biztonság }. Általában is érvényes, bármiféle programra, hogy a célunkat a lehető leginkább célirányosan, legrövidebb úton kell elérnünk. Ezt egy csomó humán tényező is indokolja, itt azonban egy hálózati rétegben operáló, biztonsági programról van szó.

A program kártételi képessége, illetve a programon keresztül megszerezhető jogosulatlan előny kifejezetten nagy, így a hibák kihasználására irányuló, feltételezhető indíték is nagy. Ilyen környezetben a hordozhatóságot és programozói kényelmet nem nagyon lehet figyelembe venni.

Törekedni kell a támadási felület minimalizálására, a célunkhoz vezető utak lerövidítésére, a lehető legkevesebb idegen kódra hagyatkozásra. Az nem jó hozzáállás, hogy először kinyitjuk magunkat (fork(), exec()), aztán megpróbálunk néhány esetre felkészülni, amit ismerünk vagy feltételezünk -- biztosan lesz nálunk okosabb támadó, vagy a sok környezeti feltételezésünkből valami valahol nem fog teljesülni. A jó hozzáállás az, ha programozói higiéniára törekszünk, vagyis ha választhatunk két megoldás közül, akkor mindig a kevesebb bizonytalanságot, kevesebb ismeretlent hordozót választjuk.

Na, vége a közhelyeknek :)

( saxus | 2011. 01. 12., sze – 02:23 )

Azért durva, hogy ezt egyeseknek magyarázni kell itt...

----------------
Lvl86 Troll

Ennél már csak az a durvább szerintem, amikor a magyarázat itt-ott nem helytálló...

Megmozgatja a kernelt, és akkor mi van? Beforkolt egy ifconfigot (most a biztonsági oldalát ne nézzük, most csak az erőforrás pazarlás oldalát nézzük)? Amindenit!

Először is ahányszor lefut egy ilyen kódrészlet, beforkolt minden esetben 2-5-10 programot, naés? Másodszor ami halom egyéb minden is elindul még ilyenkor, amellett egy ifconfig fork az már nem oszt, nem szoroz.

Megérteném, hogy egy forkon aggódsz, ha úgy egyébként mondjuk egy átlagos linux disztribben minden más rendben lenne, optimalizált lenne, nem lenne egy darab felesleges fork se, a bashról se mondaná senki, hogy erőforrás zabáló, stb. stb. De nem igaz, ilyen szempontból egy kupleráj, legalábbis a debian az biztosan kupleráj, most még 10 plusz fork nem oszt nem szoroz.

Másrészt meg a másik topicban arról van szó, hogy mi van, ha megtúrták az ifconfigot, és akkor jajj, a programod beforkolja. Ha az ifconfigot már meg tudták túrni, akkor már nem az lesz a legnagyobb bajod, hogy még egy program beforkolja, hanem az, hogy hanyattlökték az egész gépet tokkal-vonóval.

Másik oldalról nézve meg megy folyton a sírás, hogy nincsenek stabil apik a linuxban. Akkor most egy nem stabil apira legyen felkészítve a program?

Muszáj írni valamit ide, különben legközelebb nem fikáznak le:))

Azért ez nem teljesen jó hozzáállás. Tudom, hogy vannak olyan nézetek, hogy olcsó a memória meg olcsó a cpu meg bla bla és kit érdekel, de ez nem jó hozzáállás. Pont emiatt a hozzáállás miatt vannak olyan bloatware programok, amik kb feldobnak egy üzenetablakot a pontos idővel minden délben, és 50mb memóriát foglalnak. Sajnos sokan gondolkodnak így, ahelyett hogy optimalizálnának néha.

Nem tudom, hogy pontosan mikor forkol az OpenVPN, de ha az(ok) a kódrészlet(ek) futás közben rendszeresen lefut(nak), akkor a forkolt processzek száma jelentős lehet, és nagy forgalmú szerver esetén ez már nem mindegy. Amíg 2 felhasználó használja, addig senkit nem érdekel, de ha netalán több száz usernek forkol 2-5-10 programot, az már tetemes erőforrásigényt jelenthet.

Szerintem.
--
ahan nem

akkor jön jól a forkolás, mikor 300 user rángatja ugyanazon szervert, majd egy "óvatlan szakadás" után egyszerre próbál mindenki visszamászni.
Topic indításhoz és ide is egy kicsit: Az ioctl kellően stabil ahhoz, hogy lehessen használni ilyen helyen, másrészt, hogy 50 rendszerre csinálnak külön-külön paraméterezést, vagy 5 kerneltípusra csinálnak használható ioctl hívásokat, szerintem szintén nem mind1. Attól hogy exec-el orrba szájba, a kód nem lesz hordozhatóbb, sőt, ha ne adj isten bármi eltér a megszokottól, a szívás van csak.

Szerinted mi fog történni, ha 300 kliens megpróbál újracsatlakozni egyszerre?
megmondom: semmi különös, újra fog csatlakozni. Ezt én tapasztalatból mondom, te is megteheted ugyanezt?

Az általam ismert linuxokon nem volt 50 féle ifconfig, csak egy. Tehát az sem valószínű, hogy 50 féle paraméterezés kell, jó eséllyel unix variánsonként kell egy. Viszont az ifconfig nem változik kernelverzió cserekor.

"ha ne adj isten bármi eltér a megszokottól, a szívás van csak.": ez önmagában igaz kijelentés, csak azt a mögöttes tartalmat vélem kiolvasni a sorok között, hogy szerinted az ioctl-ek nem fognak változni, az ifconfig meg igen. Szerintem meg pont fordítva.

De akinek ez a véleménye, mint neked, az miért kampányol az ioctl mellett?
Arra sokkal inkább számítani lehet, hogy a kernel mellé felraknak egy vele kompatibilis ifconfigot, mint arra, hogy a kernel ioctl nem változott... Ha meg nincs a kernel mellett ifconfig, akkor az openvpn okafogyott...

Kösz, hogy bizonyítottad az állításomat.

Az ifconfig nélkül is van élet, egyébként meg micsoda meglepetés...:

"In Linux distributions based on 2.2.x Linux kernels, ifconfig, and the route command operated together to connect a computer to a network, and to define routes between networks. Distributions based on later kernels have deprecated ifconfig and route, replacing them with iproute2. iproute2 includes support for all functions of ifconfig(8) and route(8), as well as traffic-control (such as bandwidth shaping). ifconfig for Linux is part of the (no-longer maintained) net-tools package."
(Wikipedia)

Azt sem akarok. Ugyanis van rá más módszer, van rá értelmes, gyors, takarékos megoldás - csak ugye a scriptkiddie kódfosókat ez nem érdekli...
Arra akartam egyébként utalni, hogy az ifconfig-ot úgy mindenestől ki lehet hajítani a Linuxból, nem fog fájni, max. kell írni egy wrappert, hogy nagyjából hasonlóan működjön az ip parancs, mint az ifconfig. Aztán lehet forkolni wrappert, ami elindítja az ip parancsot, ami megcsinálja azt a pár ioctl-t, amiért az egész történet elindult.

jesszus. tehát a meglévő, leprogramozott, tesztelt, működő ifconfig helyett írjanak egy wrapper scriptet, ami ifconfigként működik, plusz munka, az elején nyilván bugos lesz, mint atom, shellt kell forkolni hozzá, ami nagyobb erőforrásigényű, mint egy ifconfig bináris, stb.

Mondd, te ezt komolyan gondoltad vagy csak velem akarsz kötözködni? mert ekkora marhaságot ezen a fórumon ritkán olvasok. Miért van az, hogy a nagyon szakértőkből valahogy mindig hiányzik a józanság meg az életszerűségre való törekedés?

Arról meg (az itteni hozzászólások tükrében) nincs meggyőződve senki, hogy valóban van-e értelmes, gyors, takarékos megoldás. nagyon úgy tűnik, hogy ki mibe futott bele eddig, aszerint gondolja, hogy van-e vagy nincs. Vagyis nincs.

Nem. Az ifconfig, mivel a funkcionalitását is tudó, de nála sokkal okosabb eszköz (ip) van, így nyugodt szívvel kihajítható. Kivéve, ha az openvpn-t is használni óhajtja valaki, merthogy abba szépen belé vagyon drótozva ennek az ócskaságnak a rángatása. Arra céloztam egyébként, hogy az ifconfig kihajítása mellett csinálnak egy wrappert az ip köré, ami úgy fog viselkedni, ahogy az ifconfig-tól várják, hogy azok, akik ezt a régi cuccot használják, azok is élhessenek tovább.

Keresztkérdés: Van egy php-s cuccod, amiben egy könyvtárban lévő fájlokat kell valamilyen szűréssel listázni. Hogyan csinálod? Meghívod platformfüggően az ls-t, a dir-t, avagy a php beépített cuccait veszed elő, és azzal operálsz?

te nem érzed, hogy egy ip + wrapper script az minden szempontból ótvarosabb megoldás, mint meghagyni az ifconfigot? ha már nem tudod kivakarni az alkalmazásodból az ifconfig forkolását, akkor maradjon az ifconfig, ne kezdjen neki a programozó wrappert barbárkodni...

a php-s cuccaimat kihajítottam.

keresztkérdés: ha van egy alsóközepes autód, pl. egy skoda 1.2 htp-d, azt kidobod, csak mert pár méterrel odébb a vw csoport másik kereskedésében porsche-t árul? És veszel egy jóféle porschét, majd leszaggatod róla a márkajelzéseket és ráragasztod a skoda emblémát? mert ez a wrapperes erőlködés kb. ugyanennyire ökörség, mint amit az én példámra mondana minden józan életű ember.

Per pillanat _nincs_ a karbantartás nélküli, bugyuta ifconfogra szükség, mert lehet helyettesíteni okosabb cuccal. Ennyi. Vannak esetek, amikor sima címet sem bír adott interfészre felrángatni az ember ifconfig-ot használva, csak az ip parancsot bűvölve. A dolog onnan indult, hogy "mindenütt van". Ezt, minthogy van nála jobb és okosabb eszköz, már nem szabad feltételezni. Ahol nincs, csak ip parancs, ott mit csinálsz az openvpn-nel? Vagy belehákolod, hogy az ip-parancsot hívogassa, vagy az ip köré gányolsz egy wrappert, ami megeszi az ifconfig paraméterezését. Vagy a harmadik lehetőség, hogy belehányod az openvépéenbe az ifconfig-ot is (azt,a minek a paraméterezése bele van drótozva a szoftverbe, és örömködsz vala néki.

nem hiszem, hogy pl. a debianosok ne karbantartanák a net-tools csomagot, amennyire kell. De ha nincs túl sok változás, minek buherálnák.

Ez a kényszeres helyettesítés engem zavar. Ha valami megvan, jól működik, a feladatát ellátja, minek helyettesítenéd egy másikkal? értelmetlen, felesleges melóra kényszerít.

Ha nem tudsz egy ip címet felrakni egy interfészre, az nem hiszem, hogy az ifconfig hibája lenne. Valami mást néztél be ott. A dolog, mármint ez a mellékszála a beszélgetésnek, nem onnan indult, hogy mindenütt van, hanem onnan, hogy erőltetted ezt a wrapper izét, aminek kb. semmi értelme. A topic onnan indult, hogy ifconfig fork vagy ioctl, de ezt tegyük félre ebben a mellékszálban és koncentráljunk arra, amit erőltetsz: wrapperelt ip vagy eredeti ifconfig. Ebben az egyszerű kérdésben szóba nem kerül az ifconfignak látszó wrapperelt ip, ha ifconfigot akarsz használni a programból, tedd fel az ifconfigot és ne kavarj wrapperrel. Ha meg nem jó neked az ifcongfig (és itt visszatérünk a mellékszálból az eredeti kérdésre), akkor meg faragd meg magadnak a programot ioctl-re vagy ip forkra. De wrapper? aaaargh

Még mindig azon lovagolsz, hogy ami helyett van okosabb, jobb, azt nem szabad használni? Mond csak, milyen oprendszer is van a desktopodon? xp? w7? mond csak, milyen autóval is közlekedsz? ferrari? exelero? mclaren f1? vagy legalább egy nyüves espace f1-et összegüriztél? vagy miről beszélsz?

El kellene végre fogadni az okos mérnökuraknak meg architekteknek, hogy ami bevált, azt békén kell hagyni, nem kell lecserélni l'art pour l'art. Ha biztonsági kifogásaid vannak, akkor azt a problémát oldd meg, ne kend el.

Ne lovagoljunk azon, hogy mit csinálnék az openvpn-nel, mert nem az a valódi probléma, hogy milyen az openvpn. A valódi probléma a szemléletben van.

Onnan indult, hogy ifconfig, ha még 2-3-5 féle is, de van. Én meg azt mondom, hogy nem feltétlen szükséges, hogy legyen, merthogy lehet élni (szerencsére) nélküle is. Egyébként meg nem, nem én néztem be, ha jól rémlik, a vlan-os interfész és a secondary cím témát nem komálta az ifconfig... Jó, tudom, kevés helyen van eth12.3456 interfész, amire föl kell rángatni két ip-címet :-P
Az openvpn-nek szüksége van az ifconfig-ra, mert azt hívja (mint egy script...), ahol nincs (mert kidobták, hiszen az ip mellet fölösleges), ott az openvpn nem működik. Ezt vagy egy ócska ifconfig felrakásával (Linuxon karban kell tartani, hiszen a kernelbe turkászik, és az egy rendes Linuxban olyan, mint a tavaszi időjárás, t.i. változékony...) vagy wrapperes hákolással lehet megoldani.

A szemléletben van a probléma, valóban. Egy biztonsági szoftver egy külső, ismeretlen binárist hív a működéséhez,a miben totálisan megbízik...

Mi az, hogy "ismeretlen bináris"..? Mivel "ismertebb" maga a /usr/sbin/openvpn vagy pl a /bin/sh mint az /sbin/ifconfig? Mi van ha a kernel dobja ki a ioctl API-t, mert a netlink mellett semmi szükség rá? Ha meg nem dobja ki a kernel az ioctl API-t, akkor miért dobnánk ki az ifconfigot aminek a megtartása kvázi semmibe nem kerül? Mondvacsinált érvek..

Ha ennyire nem megy értelmezni az ismeretlen szót a kontextusban, ne foglalkozz szoftverekkel.

Nem az openvpn csomag része, (és nem is lenne szükséges feltétlen a működéséhez) -> ismeretlen.

És mielőtt beleköt valaki, hogy deáht a Linux kernel is ismeretlen, az gondolkodjon el azon is, hogy a kettő közül melyik a nélkülözhetőbb.

----------------
Lvl86 Troll

Bocs, nem akarok beleszólni...
Legalábbis nem kötözködni...
Az openvpn-nél amikor ifconfig-ot használ (nem néztem a forrását), akkor lehetőséged van megadni egy up illetve down script-et is...
Szóval ha nincs ifconfigod, akkor saját magad is meghegesztheted az interfész felhúzását/lelövését... Akár ip-vel is...

--
Debian Linux rulez... :D

"Ez a kényszeres helyettesítés engem zavar. Ha valami megvan, jól működik, a feladatát ellátja, minek helyettesítenéd egy másikkal? értelmetlen, felesleges melóra kényszerít."

Rajtad kívül senki nem akarja helyettesíteni. Pont, hogy ki akarja vágni a francba, csak te erőlteted bele, hogy csakazértishelyettesítenikell...

Ha az OpenVPN és a hasonló szarok nem ifconfig-gal gányolnának, hanem normálisan megírnák, dobni lehetne mindenféle wrapper nélkül az ifconfigot.

Wrapper meg egy alternatíva (értsd: lehetőség, nem kötelező, hogy mit csináljon ott az ember, ahol nincs (és nem is lesz ifconfig tetszőleges okok miatt), de mégis muszáj működésre bírni az ilyen taknyokat. Teszemazt protolod Windowsra, ahol nincs ifconfig. (Tudom, van Windowsos portja, nem ez a lényeg).

Persze, trollkodni egyszerűbb.

----------------
Lvl86 Troll

"Rajtad kívül senki nem akarja helyettesíteni": akkor olvasgasd, amit zeller ír, kényszeresen le akarja cserélni az ifconfigot ip-re. Ezen a tényen való vitatkozást nem látom indokoltnak.

"Ha az OpenVPN és a hasonló szarok nem ifconfig-gal gányolnának, hanem normálisan megírnák, dobni lehetne mindenféle wrapper nélkül az ifconfigot. ": ez a kijelentés így ebben a formában teljesen igaz (hogy ezen megoldás helyett mi a fenének erőlteti zeller a wrappert, az rejtély előttem). De ha nem csak betű szerint értelmezzük, hanem a szokásos beszélt nyelv szerint is, akkor tartalmazza azt az implicit állítást, hogy az ioctl-es megoldás jobb, még akár azt is tartalmazhatja, hogy lényegesen jobb, mint ifconfigot forkolni. Kellene már erre indoklás, ami túlmutat azon, hogy higgyük el a topicban nyilatkozóknak.

"Wrapper meg egy alternatíva": a wrapper ebben a kérdéskörben egy ostobaság. Tökteljesen felesleges erőltetni, ettől nem lesz jobb. Ha szerinted a forkolás nem jó, csak az ioctl a jó, akkor miért kellene energiát feccölni egy wrapperbe, ami konzerválná a szerinted rossz állapotot ahelyett, hogy ugyanezt az energiát belefeccölve magát az openvpn-t javítaná ki és faragná át ioctl-esre?

Ha szerinted a forkolás nem jó, csak az ioctl a jó, akkor miért kellene energiát feccölni egy wrapperbe, ami konzerválná a szerinted rossz állapotot ahelyett, hogy ugyanezt az energiát belefeccölve magát az openvpn-t javítaná ki és faragná át ioctl-esre?

Mert az openvpn komuniti nem veszi a faradsagot arra, h egysegesitse a mostani agyontaknyolt fos helyett a kliensuk mukodeset. Igy tehat aki hasznalni akarja vagy leimplementalja nekik, vagy takol egy wrappert ami ugy mukodik mint az ifconfig kvazi konzervalva a mostani rohejes szitut.

---
pontscho / fresh!mindworkz

"50 rendszerre csinálnak külön-külön paraméterezést, vagy 5 kerneltípusra csinálnak használható ioctl hívásokat"

Ez épp fordítva van. Scriptel kell kb 5 féle paraméterezés 50 rendszerre, API-ból pedig van 70 féle az 50 rendszerre és ezt tapasztalatból tudom. De lényeg igazából az, hogy a paraméterezés átállítása egy új platformra kb 5 perc (és meg tudja csinálni egy amatőr disztribútor is), az API-ra portolás meg 1 nap és programozó kell hozzá.

( dap | 2011. 01. 12., sze – 03:34 )

Én nem ítélném el ennyire a segédprogramok hívását. Kétségtelenül hátrányos lehet a teljesítményre és a biztonságra is ahogy írod, de ezekre annyi más dolog is veszélyes, nem hiszem, hogy ezt annyira ki kéne emelni. Elvben rossz, a gyakorlatban működik. Ha megnézed, így működik a dhclient (alapinstall), a vtun, az openvpn is. Ha a különböző API-kra fejlesztéshez szükséges idő negyedét rászánták a biztonságos script-hívásra, akkor egy jó kompromisszumot kötöttek.

De igazából annyit is írhattam volna, hogy az dobja az első követ, aki már fejlesztett multiplatformos hálózati konfigurációt manipuláló kódot alacsony szintű API-ra, amiből csak Linuxon kapásból kettő van (ioctl, netlink). Próbára teszi az elveket, keményen. Asszem' én a 3. platformra portolásnál vesztettem el a hitem és helyettesítettem kb 500 sort egy 20 soros külső scriptel..

Dobhatom? :)

Kb. fel nap volt szarra tesztelessel egy common api ala hozni egy-egy uj platformot, beleertve a windows-t is. Najo, ez utobbi egy egesz napot vett igenybe mert nagyon utana kellett olvasni az MSDN-en a dolgoknak. Eleg rossz erv egy-egy 20-30 soros tiszta kodot lecserelni egy ilyen katyvaszra, ad 1, tok jo, h van pazarolhato eroforras, ad 2, az ifconfig sem platform fuggetlen, mar ha egyaltalan letezik az adott platformon. Ezert van az, h ahelyett, h lekodoltak volna 10 sorban az adott if-re a cimbeallitast, lett helyette egy 30 soros execve() paros szinten szarra makrozva mert rettenetesen platformfuggetlen.

Persze nem kizart, h tudatos dontes kerdese, hiszen valahogy el kell adni az openvpn uzleti verziojat is a tomegeknek.

---
pontscho / fresh!mindworkz

Ha tudsz forrást mutatni, ami valóban működik minden platformon amin az OpenVPN és API-val 20-30 sorban/platform megcsinálja azt, amit az OpenVPN az ifconfig/route hívogatással, akkor egye fene, kijelentem, hogy ezt elb*szták. :)

Az ifconfig se platformfüggetlen, de mennyi idő átparaméterezni egy új platformra, 5 perc..?

Szivesen mutatnek, de jelenleg az uzleti titok kategoriaba esik az alkalmazas teljes forrasa.

Az ifconfig se platformfüggetlen, de mennyi idő átparaméterezni egy új platformra, 5 perc..?

Igaz, miert dolgozzunk jol, miert adjunk ki minoseget a kezunkbol ha taknyolni is lehet. :) Erosen platformtol fugg. Van ahol ez a parancs nem is letezik.

---
pontscho / fresh!mindworkz

Egyetertek...

Es az az erv meg nem is kerult kibontasra, hogy mig ioctl eseteben a bugokat megfoghatja a compiler es a visszateresi ertek kezelese, addig az ifconfig kimenet buzeralasat vegzo kod idozitett bombakent viselkedik.

Mondjuk az ioctl eppen kisse allatorvosi lo, mivel egy fuggvenyinterfesz moge nagyon sok es szerteagazo funkcionalitast spekel. Nyilvan ez sem tesz jot a robosztussagnak, de ha analogiat akarnank talalni ifconfig buzeralasra, akkor kb ugy kellene elkepzelni, mintha az egy:

char* ifconfig(char *);

fuggveny lenne. Azert belathatjuk, hogy ennel meg mindig nagysagrendekkel robosztusabbnak tunik az ioctl.

Apróság, de ifconfig kimenetre nem épít (leszámítva a visszatérési értéket), csak a paraméterezésre. Ha az alapvető paraméterezés megváltozik, az nagyon sok más (local) scriptnek is betenne a rendszeren, ezért megkockáztatom azt a kijelentést, hogy a paraméterezés ritkábban változik, mint maga az API.

"robosztusabbnak tunik az ioctl" -- ez így igaz. (Nem az elvről vitázok, a gyakorlatról.)

( hrgy84 | 2011. 01. 12., sze – 08:31 )

OMG. Erre igy nagy hirtelen ez a reakcio. Szoval forkol az openvpn? Behiv segedprogramokat? Hu, basszus. Es akkor konkretan mi van? Ha a kernel fs, processz, etc. kodja serult, akkor mar baromi nagy bajok vannak, es a lofaszt nem erdekli, hogy esetleg pont a halozati reteg az meg(!!) nem serult. Vagy megis, csak meg nem tudunk rola.

Eroforrasilag meg megintcsak rohogni tamad kedvem ezt olvasva. Emberek, amirol itt beszelunk, az elsosorban jo esellyel ugyis a diskcache-ben van, nulla, ismetlem, nulla eroforraspazarlas fog tortenni, mert a Linux rendszer bootolaskor ugyanezeket a cuccokat meg fogja mozgatni, legalabbis az ifconfigot tuti. Arrol nem is beszelve, hogy nem tobbszazmegas ELF-ekrol beszelunk, hogy emiatt aggodni kellene. Ennyi erovel dobaljuk ki az initscripteket, es implementaljuk oket C-ben, termeszetesen ioctl hivasokkal, mert az mennyire full secure. Ja, es ne felejtsuk el oriztetni az orzoket, meg azokat is, akik oket orzik.

Hab a tortan, hogy mellesleg naggyon minimalis, az alap halozati utility-ktol eltero program van a piacon, amik ioctl-lel cseszegetnek a halozatot. Hogy miert? Nos, talan mert az ifconfig parameterezese es kimenete sokkal-sokkal egysegesebb, mint az ioctl valaha is lesz.

Ha meg megfertoztek ezeket a programokat valami kartekony virussal, akkor meg mar ugyis mindegy, mert az mar csak a vegallomas, jo esellyel az openvpn es a bash/tcsh/ksh/zsh binarisokat is megfertoztek.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

biztos van, amikor ez a legolcsobb, de akkor is -1

En pl. hasznalom a clamav-ot, amit alapvetoen 3-felekeppen tehetek meg:

- a libclamav-ot hozzalinkelem a cucchoz
- a clamd-t halozaton/unix socket-en keresztul hasznalom
- exec*(), system(), stb-vel meghivom a felparameterezett clamscan-t

Az elso kettot hasznalom, de tekintve, hogy egy nagy teljesitmenyu szurore gondoltam, az utolso szoba sem johet, ami ordas egy hekk, es security szempontbol is aggalyos.

Amugy btw. igaz az, hogy boot-kor is meghivod az ifconfig-ot, de azert van kulonbseg egy kb. read-only script kozott, amit te allitasz be es akozott, hogy egy binaris program ki tudja, hogy mi modon birizgal es hasznal...

De hogy egy kicsit ellentmondjak magamnak, irtam egy szegeny ember HA-utility-t, ahol egy halom demon inditasa, lelovese mellett a halozatot is fel le, stb. kell mozgatni. Guess what, hogy oldottam meg? system(SCRIPT_UP); ill. system(SCRIPT_DOWN); ahol a SCRIPT_* az 2 #define ... :-)

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Az utóbbi bekezdéshez annyit, hogy magyarán más f@szával vered a csalánt. :)

A clam-os példád ide nem jó, ez 3 platformfüggetlen API, nyilván én is az első kettőt használnám. Ha lenne hordozható API a hálózati beállítások menedzselésére, az OpenVPN is azt használta volna, csakhogy ott más a helyzet.

Az utóbbi bekezdéshez annyit, hogy magyarán más f@szával vered a csalánt. :)

Mar miert? A cucc egy altalanos utility, ami honnan is tudna, hogy neked mi kell, ha helyzet van, mert pl. te leszel az aktiv node? Amikor pedig meghiv egy shell scriptet, az kb. pont olyan, mint amikor lefut az rc.local...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Egen, sejtettem, h lesz valakinek egy hasonloan elmes hozzaszolasa.

Hogy miert? Nos, talan mert az ifconfig parameterezese es kimenete sokkal-sokkal egysegesebb, mint az ioctl valaha is lesz

Nem az, sot a unix leszarmazottakat leszamitva nincs ilyen tool az adott rendszeren. Ezert van az, h az openvpn fele szarra execvezi magat, a masikfele meg leimplementalta ezen parameterek beallitasat. Tehat marad az, h az ifconfig kezeleset platformfuggoen lekodoljuk, plusz azon a platformon ahol ilyen tool nincs emulaljuk.

Gratulalni tudok a szemleletmodhoz.

---
pontscho / fresh!mindworkz

A unixnak az a szemlélete, hogy kis, egyszerű utilityket kapcsol egymáshoz és abból rakja össze a feladat megoldását. Tehát az, hogy az openvpn forkol egy ifconfigot, megfelel a unixos szemléletnek.

A windowsnak meg az, hogy böszme nagy bloatware programokat csinálnak, amikben benne van minden elektromos csellentyűcske. Úgyhogy az általad emlegetett windowsos megoldás is jó, ha windowson vagy.

De elfogadom, legyen igazad, csak akkor jöjjenek azok az érvek, amik ezt bizonyítják, mert a topicnyitóban felsorolt érvek erre nem jók.

Az az egesz kis, egyszerű utilityket kapcsol egymáshoz és abból rakja össze a feladat megoldását dolgot scriptelt ill. cmd line toolokra szokas vonatkoztatni, nem ilyen bloatware fostalicskakhoz, mint az openvpn. A leginkabb idegesito ebben az egeszben az, h ennek a taknyolasnak a kifejlesztese es tesztelese annyiba kerul, mint a rendesen leimplementalasa. Igaz, taknyolo pisteket tobbet talalni, mint szakembert. Szegyen.

---
pontscho / fresh!mindworkz

De, nagyon is komolyan gondolom. En, a linuxbuzi, aki meg talan eleteben nem latott BSD-t, amint eloszor felraktam a NetBSD-t, ketto perc mulva mar tudtam rajta halozatot konfigolni. Hasonlo a helyzet az OS X-szel is, ugyancsak tokismereetlen platformkent.

Solaris, nos, igen. De az osszevissza 1, azaz egy darab platform, ezzel szemben az ifconfig kapasbol ot platformra erheto el.

Es akkor visszakerdeznek: az ioctl() ugyanolyan Solarison, mint Linuxon? Egysegesebb mint az ifconfig?
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A kérdés rossz: Az ioctl() mióta azonos a különböző verziójú Solarisokon? És meddig lesz az? És Linuxon? Egy linuxbuzi számára a segédprogramok a stabilak, mert a kernel-API marhára változékony - egy normális fejlesztő számára meg az API-k a stabilak, és minden egyéb változhat.

Nézz már bele mondjuk a debianos net-tools csomag changelogjába, évekre visszamenőleg alig van lényegi módosítás. Faragták a japán fordítását, meg gcc cseréhez patkoltak rajta, meg ilyen komoly dolgok.

Ehhez képest van még solaris? vagy opensolaris? vagy minek hívják a héten?
A solarisnak már a léte is sokkal jobban fluktuál, mint a linux kernelben a net-toolshoz szükséges kernel-api.

Egyre inkább azt gondolom rólad, hogy ez a nem stabil linux kernel api csak vénasszonyos siránkozás. Meg azt is javaslom megszívlelni, hogy a kutya sem piszkol oda, ahol eszik.

Az hogy volt/van/talán lesz Slowaris,a z egy dolog, én a kernel api stabilitásáról, állandóságáról beszéltem, ami a Linuxnak nem erőssége. Vagy igen? Akkor meg miért nem erre a stabil kernel-apira építenek, miért a drágább, biztonsági szempontból sz@r@bb, plusz függőséget generáló megoldásra építenek? Azért-e, mert lusták, vagy azért-e, mert az api olyan, mint a tavaszi időjárás?

Ha megnézted volna a changelogot, te is látnád, hogy a kernel api ezen a területen semmivel sem rosszabb, mint a solarisé, tehát az a hiszti, hogy a linux kernel api nem jó, a solarisé meg jó, nincs alátámasztva. Ha csak a változtatások mennyiségét nézem, akkor ugyanannyira jó mind a kettő. Ha minden körülményt figyelembe veszek (oracle felvásárlás, stb.), akkor a linux api stabilitása jobb, mint a solarisé, mert linux api lesz két év múlva is.

Ezt az ifconfig dolgot is hajtod, mint az imamalmot, csak értelmes érvek nem kerültek még elő arra nézve, hogy biztonsági szempontból rosszabb. Egyre inkább az a gyanúm, hogy neked azért rossz a linux kernel, mert egyszer belefutottál valamibe és azota en-bloc rossz az egész. Erre viszont javasoltam a kutya hova piszkol szólást.

Ha nem tudsz új indoklással előállni, a régiek ismétlésével ne fáradj.

Nem jó vagy nem jó, hanem hosszú távon fix és stabil kontra igény/ötletek szerint tekerünk rajta egyet-kettőt. Az, hogy lesz x vagy y kernel, meg hozzá megfelelő ioctl, az irreleváns, a kérdés az, hogy a tegnapi ioctl-re építő kód használható lesz-e holnapután is?

Biztonsági szempontból mi a jobb? Az a kód, amit TE írtál, aminek a hibajavítása a te kezedben van, vagy az, amit valaki odatett, hogy nesze, használd ezt? Az openvpn szempontjából az az ifconfig, amit meghív, az egy ZÁRT bináris valami, NEM tudják, csak feltételezhetik, hogy az a kód fog végrehajtásra kerülni, ami. Ráadásul erőforrás-használat szempontjából is hibás megoldást választottak.

A linux, meg az ópenszósz eszközök terén sok hülyeségbe, slendriánságba bele lehet futni - másütt is, csak ott talán nem látszik annyira - és igen, 1994 óta azért volt lehetőségem ilyesmit látni...

Sehol nem mondtam, hogy rossz a kernel, azt mondtam, hogy a kernel API nem stabil, más rendszerekhez képest gyakran módosul.

Ha te be akarod nekem bizonyítani, hogy még sosem köpködted meg a linux kernelt, akkor olyan hangfekvésben fogok sikítani, hogy a denevérek leesnek a barlang faláról. Hint: "NORMÁLIS unix esetén sem változik az ioctl() egy kernelcsere esetén. Ja, hogy itten Linuxról is szó van, ahol a kernel verzióját is meg kell nézni a megfelelő alacsony szintű rutinok kiválasztásához...?": ezt ki mondta? Ha itt nem a kernelt köpködted volna, hanem az apit, akkor azt kellett volna írnod: normális unix api esetén... és ja hogy itten linux apiról is szó van....

Biztonsági szempontból mi a jobb? az a kód, amit én írok vagy az, ami 7-8 éve üzemel ilyen-olyan disztribekben és millió maintainer látta már, átnyálazta, használják, nincs bugreport?

De térjünk vissza a veled folytatott beszélgetés elejére. Oké, utálod a forkolós ifconfigot. Most 5 percig úgy teszek, mint aki elfogadja ezt a véleményt. Akkor minek merül fel benned az ioctl-es megoldás implementálása helyett egy wrapper script?

Azt gondolom, hagyni kellene ezt a fenébe, mert már régen nem arról szól a vita, amiről elindult, és elismerem, ez az én hibám.

Nem az a kód, ami x éve üzemel, hanem az, ami az aktuálisan /sbin/ifconfig bináris forkolásakor lefut. Nem tudhatod, mint openvpn, hogy az a futtatható valami az-e, amire számítottál.

Nem a forkolós ifconfigot utálom, hanem a gányolást. Márpedig egy komplett binárist forkolni csak azért az egy-két-néhány ioctl-ért, az szerintem (meg ha olvastad a hozzászólásokat, láthattad) és mások szerint is gányolás. Ha egy disztribúció összeállítója úgy dönt, hogy az alarendszerből kihajítja az ifconfig-ot, és helyette az ip-t rakja be mindenhova, akkor mit tesz az openvpn? Tudom, dependál majd a csomag az inet-utils csomagra... Broáf...

A wrapper script ott merült föl, hogy az ifconfig, meg a route kihajítható a búsba, lehet élni nélkülük is, nem tételezhető fel, hogy van. Ezért vagy az ip parancs köré rittyent az ember valami gányt, hogy a másik gányolmány működjön, vagy nekilát azt a 4.5k sort áttúrni, és normálisan megcsinálni ioctl-lel a fork helyett. Nekem nem kell wrapper script, meg ifconfig, köszi szépen, az ip parancs tökéletesen jó - sőt, ahogy korábban is írtam, van, ahol csak azt lehet használni, az ifconfig korlátai miatt. Ha meg azt kell egy helyütt használni, miért ne használjam mindenütt? Ja, mert van egy fatoekue openvépéen, ami dependál az ifconfig-ra...

Alapvetoen nem a mult az erdekes, hanem a garanciak. Solaris eseten van garancia arra, hogy a kernel api nem surun fog valtozni, linux eseten nincs. Senkit nem erdekel az, hogy a multban nem valtozott, amikor Torvalds ugy dont, hogy mostantol ket parametert felcserel, mert az milyen fun mar.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( Nyosigomboc v | 2011. 01. 12., sze – 11:21 )

Bar nem egy OpenVPN-hez hasonloan biztonsagkritikus eszkoz volt, de olvastam valahol egy tortenetet egy fickorol. Az illeto kapott egy feladatot: egy Unixon futo Java (!) programot kellett portolnia Win NT-re (nem most volt). Csodalkozott, hogy ebben most mi a nehez, azt hitte szerencsetlen, hogy csak atmasolja, es ennyi, a Java elvileg hordozhato.
A gyakorlatban viszont a kodja tele volt olyanokkal, hogy az "mv"-hez hozzafuzott 2 filenevet (+space-ekkel), es utana elinditotta az osszerakott parancsot. :)
A Java filekezelo metodusaival nyilvan egyszerubb lett volna, es meg hordozhato is marad.. de hat az emberi lelemenyesseg..

--
Take my advice; I don't use it anyway.

Nem tudom mit láttál, de az architect tervez és döntést hoz, amit majd egy jómunkásember implementál (két külön munkakör). Az pedig, hogy a design vagy egyéb patterneket nem bírják használni, az az "architectet" minősíti nem a patternt.
De ez már egy másik téma, itt eléggé offtopic.
--
ahan nem

Arra akartam célozni, de látom, nem ment át, hogy a design patternek meg az ilyenolyan legjobb gyakorlatok meg egyebek kritika nélküli követése az én tapasztalatom szerint több bajt okoz, mint amennyit használ.

A programozó dolga, hogy leprogramozza, amit az architekt megtervezett. Ha hülyeséget terveztek, hülyeség lesz leprogramozva. Ez eddig tiszta sor. De attól, hogy van egy halom eszközöd, amit mint architekt, ismersz, még nem kötelező mindig mindegyiket használni.

Ez így van, mindig a feladathoz kell tervezni, nincs ultimate megoldás/pattern, ebben egyetértek. Viszont azt még mindig tartom, hogy ha a széleskörben elfogadott patterneket (nem mindet, csak ami a megoldáshoz kell) használja valaki, akkor nagyon nem lőhet mellé. Ha mégis egy kalap szar a végeredmény, akkor ott az architectel/programozóval van a baj.
--
ahan nem

Azt hiszem vagy te nem tudod mi az a pattern, vagy én.

http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29

Szabadfordításban az első pár mondat:

"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations."

A szoftvertervezésben a tervezési minta olyan általánosan használható megoldás, ami egy gyakran előforduló szoftvertervezési problémát old meg. A tervezési minta nem egy befejezett konstrukció, ami közvetlen kóddá alakítható. Ez egy leírás, vagy sablon arra, hogyan oldjunk meg egy problémát úgy, hogy azt több különböző helyzetben is használhassuk.

A fordítás olyan amilyen, de a lényeg érthető angolul is: ennek SEMMI köze a pénzhez. Az elfogadást meg úgy értettem, hogy a szakmában jártas emberek jónak, és használatra érdemesnek tartják a mintát, nem úgy, hogy levédik, mint valami patentet aztán az használhatja aki akarja.

Szerintem itt fejezzük be ezt a szálat, mert ennek már semmi értelme.
--
ahan nem

Itt most kivitelezéséről volt szó, nem üzemeltetésről. Best practice a kenyérsütéshez is van, üzemeltetés-támogatás patternekről pedig még sosem hallottam (ez mondjuk lehet, hogy a tájékozatlanságomon múlik, mert az IT ezen része sose tartozott az érdeklődési körömbe). Ha esetleg tudsz ilyet mondani annak örülnék (vagy google kifejezést; IT operation pattern nem hozott eredményt).
--
ahan nem

( Zahy v | 2011. 01. 12., sze – 23:00 )

Basszuskulcs. Nem értem. Van egy szoftver, amiben valamely hálózati paraméter beállítását kell megtenni. Ezt lehet platformfüggő ioctl rendszerhívással, és platformfüggő ifconfig parancs hívásával is megoldani. Ez eddig szerintem mindenkinek világos.

Az ioctl hívásos használathoz kell N db. rendszerhívás. Az ifconfig parancsos használathoz feltehető módon kell minimum ugyanaz az N db rendszerhívás (hisz nyilván az ifconfig is ez(eke)t hívogatja a legvégén), plusz minimum 3 másik (fork / exec / wait). Azaz az ifconfig drágább.

Az ioctl hívást megerőszakolni lehet X-féle módon. Az ifconfigot pedig (nyilván) ugyanazon X, valamint még ezen kívül Y-féle módon *is*. (PATH-hekkeléssel, LD_PRELOAD-dal, istentudja milyen módon.) Azaz az ifconfig veszélyesebb.

Azaz: lehet drága és veszélyes módon, valamint olcsóbb és kevésbé veszélyes módon is megcsinálni - ennek ellenére itt még mindig pozitív egész azok száma, akik szerint ez így jó, nem kell vele foglalkozni, elhanyagolható. Nem, nem elhanyagolható. Úgy gondolom, (főleg egy biztonsággal közeli kapcsolatba hozható programnál) a "jó csapaton ne változtassunk" elvet itt nem kéne alkalmazni. Nem csak azért mert nem jó, hanem azért is, mert még ha jónak is minősítjük, lehetne jobbá tenni.

valójában a reláció nem került bizonyításra, miszerint az ioctl jobb és olcsóbb.

a folyton jobbá tevésről meg az a tapasztalat, hogy a programozók szűk látóköre terén esetleg tényleg jobbá tesz valamit, csak egy idő után a programból termék lesz (vagy valami ennek megfelelő) és mindjárt szélesedni kellene a látókörnek.

A debian install cdket is "jobbá" tették ugye... Mindig eszembe jut egyik kedven íróm életrajzi regénye, amiben annyit mondott (gyárvezér volt), hogy hiába tervezel csuda dolgokat, ha nem tudom legyártatni.

> valójában a reláció nem került bizonyításra, miszerint az ioctl jobb és olcsóbb.

N < N + 3

ha N rendszerhívások (pozitív) darabszáma, akkor fenti egyenlőtlenség neked miért nem bizonyítja hogy olcsóbb?

X < X + Y
ha X és Y nemnegatív egész számú sérülékenység. Akkor miért nem jobb, ha kevesebb db-számú sérülékenység lehet?

Visszatérve az OpenVPN-ről, szerintem itt többen megelégednének azzal, ha a nyílt forráskódú OVPN-ben dobnák ki a system("ifconfig") részt ioctl-re is. Mondjuk:
#ifdef TERMÉK
system("ifconfig")
#else
ioctl(...)
#endif

formában. No mindegy, nekem most már késő van ehhez.

"X < X + Y ha X és Y nemnegatív egész számú sérülékenység." ez nem igaz. Hint: Y=0 mint nemnegatív egész...

A gond az indoklásoddal az, hogy két paramétert vettél ki a többi közül.

"Visszatérve az OpenVPN-ről, szerintem itt többen megelégednének azzal": én pl. elhiszem nektek, hogy jobb az ioctl. De érdekelne az indoklása is, mert itt eddig csak olyan mondatok hangzottak el, amelyeket szintén csak elhinni lehet.

Bár alapvetően egyetértek a gondolatmeneteddel, aminek szerintem az utolsó mondata a lényeg, mégis egy-két egyszerű kérdést teszek fel: (És ne a személyednek szóló kérdésként értékeld, please...)

- Miért gondolod, hogy jobbá lehetne tenni?
Hiszen amiről itt megy a vita, az az hogy egy interfészt HOGYAN állítunk be a rendszerben...
Végeredményként így is, úgy is be fogja állítani...
Tehát mitől lesz jobb, ha így, vagy ha úgy csináljuk?
Értem én, hogy szebb, biztonságosabb, stb. de ettől nem lesz jobb...

- Miért nincs valaki, aki megírja ezt a 60 valahány sort ioctl-ben, és teszi közzé?
Ennyire "nagyszájú" itt mindenki?
Vagy akkor mégsem olyan nagy a "probléma"?
Tudom lehet mást is használni...

--
Debian Linux rulez... :D

"Értem én, hogy szebb, biztonságosabb, stb. de ettől nem lesz jobb..."

Végül is egy vödörnyi vizet arréb lehet vinni két méterre úgy is, hogy hozunk egy teherautót és a szomszédban kerülünk még egy kört előtte. Biztos nem jobb kézzel egyből két méterrel odébb rakni.

----------------
Lvl86 Troll

Értem amit írsz, de még mindig más oldalról nézzük azt, hogy mit nevezünk "jobb"-nak.
Én azt értem alatta, hogy ettől a VPN működése(használhatósága) nem lesz jobb...
Így is, úgy is ugyanaz a hatás... Van egy MŰKÖDŐ VPN csatornánk.

Te pedig a szoftver minőségére célzol...

Szerintem ha megbízható, működtethető (nem eszi meg az összes erőforrást) a rendszer, akkor jó.
Persze biztos lehet szoftver minőségben jobbat készíteni, de megéri? Van rá felhasználható emberi erőforrás, aki megírja?

Ha ezt nézem, akkor szerintem egy ioctl átírástól nem válik a szoftver használati értéke jobbá...

--
Debian Linux rulez... :D

Én azt értem alatta, hogy ettől a VPN működése(használhatósága) nem lesz jobb...
Így is, úgy is ugyanaz a hatás... Van egy MŰKÖDŐ VPN csatornánk.

Szentseges atya ur isten. Ez a ket mondat teljesen es tokeletesen leirja miert olyan amilyen egy-egy jol "megtervezett" es kivitelezett linux dist.

Van rá felhasználható emberi erőforrás, aki megírja?

Kezdjuk ott, h az openvpn ket reszbol all, egy gpl kliensbol es egy kereskedelmi hatterbol ami szoftvert is fejleszt ehhez a klienshez es a klienst. Ergo eroforras meg lenne, az igenyszint hianyzik hozza.

---
pontscho / fresh!mindworkz

De most komolyan... Mindenkinek ismernie kell a fekete dobozon belüli életet???
Te is tudod, hogyan működik a telefonod, a GSM, a GPRS? Vagy csak használod, és elégedett vagy azzal, amit kapsz... Mert használni akarod...
Vagy még át is írod, nehogy lehallgassanak a BIG BROTHER-ék? :D

Ha valami használható, akkor használni fogják. Ha megy a VPN, akkor mindegy, hogyan hoztuk létre...
Hogy nem biztonságos, az már más kérdés...

--
Debian Linux rulez... :D

Te is tudod, hogyan működik a telefonod, a GSM, a GPRS? Vagy csak használod, és elégedett vagy azzal, amit kapsz... Mert használni akarod...
Vagy még át is írod, nehogy lehallgassanak a BIG BROTHER-ék? :D

Tulajdonkeppen tudom. A GSM forgalom nem, de a mobilnetes forgalom bizony ra van terelve egy vpn-re. Bar a vpn, voip es a FaceTime csodajanak koszonhetoen az audio/video hivas is megoldhato azon at.

Ha valami használható, akkor használni fogják. Ha megy a VPN, akkor mindegy, hogyan hoztuk létre...

Nem egeszen. Ahogy az sem mindegy, h az adott vpn kliens milyen forman epul be a rendszerbe.

---
pontscho / fresh!mindworkz

Értem én, hogy szebb, biztonságosabb, stb. de ettől nem lesz jobb...

Adott egy szoftver ami eleve arra terveztek, h adott rendszer biztonsagi fokat novelje, erre minden olyan intezkedes ami arra iranyul, h ezt elosegitse az felesleges? Merem remelni, h nem ez az altalanos FLOSS direktiva a fejlesztesben. :)

---
pontscho / fresh!mindworkz

Nem szeretnék vitázni, de szerintem az OpenVPN-t nem arra tervezték, hogy egy adott rendszer biztonsági fokát növelje...
Biztonságtechnikailag mindegy, hogy ioctl-t vagy ifconfig-ot, vagy esetleg egy másik KÜLSŐ alkalmazást/rendszerkomponenst/api-t hív meg a program...
Bármelyikben is van a hiba, a törési lehetőség, ugyanúgy veszélyessé teszi az őt használó szoftvereket.
A belsejében zajló folyamatok biztonságtechnikáját meg nem elemeztük ebben a topicban...

Hogy melyik "szép megoldás", abban lehet vitázni... Ebbe mondjuk én nem akarok beleszólni...
Hogy melyik "erőforrás igényesebb", "gyorsabb", abban is lehet vitázni... Ebbe sem akarok beleszólni...

Mellesleg, amit állítasz, az igaz: Egy ADOTT szoftver amit eleve arra terveztek, hogy a rendszer biztonsági fokát növelje, arra minden olyan intézkedést meg kell tenni, ami ezt elősegíti...
De ez nem az OpenVPN... Az egy hálózati program, közel sem egy netfilter/iptables...

--
Debian Linux rulez... :D

Akár titkosítás nélkül is mehet... Ahogy az IPSec is...

Adott esetben még a biztonsági fokot is csökkentheti egy BÁRMILYEN vpn csatorna... Mint ahogy egy switch-be bedugott újabb gép a hálózatban...
Ha a rendszer/hálózat akár csak egyetlen pontját is más irányítja mint te, akkor már veszélyben LEHETSZ !!!
Ezért még mindig az a véleményem, hogy NEM A RENDSZER BIZTONSÁGI FOKÁNAK NÖVELÉSÉRE tervezték a vpn-eket...

A te felfogásod alapján akkor egy PGP-vel titkosított levél is a RENDSZER BIZTONSÁGI FOKÁT növeli!!!!

Ha valami "biztonságos", attól még nem növel egy rendszer biztonságán...

Kétségtelen, van benne titkosítás, authentikáció, és egyéb nyalánkságok, de ettől még nem egy biztonsági mentés, vagy egy tűzfal...

Tegyük fel, van egy szervered, nem az interneten, nem is hálózatban. Mondjuk, legyen ez a "legbiztonságosabb" szint, hiszen a kis kínai 10 000 Km távolságból nagyon nehezen fogja feltörni... Mondhatni Mission Impossible.
Tegyük fel a netre ezt a szervert, de ne nyiss meg semmit... Ha létezik valamilyen TCP/IP vagy bármilyen exploit, ami megnyitja a gépet, akkor már egy szinttel lejjebb süllyedtél a biztonsági listán...
Nyiss meg mondjuk egy SSH-t, SMTP-t, vagy POP3-at... Újabb esély a feltörésre...
Nyissd meg a VPN csatornát... Megint egy szint...

Szóval hol van a biztonság növelő rendszer???

--
Debian Linux rulez... :D

Akár titkosítás nélkül is mehet... Ahogy az IPSec is...

Aminek hozzavetolegesen nulla ertelme van. Ha mar vpn-be szervezek gepeket, akkor evidens, h a kommunikaciot is biztositom vele mondjuk lehallgatas ellen.

A te felfogásod alapján akkor egy PGP-vel titkosított levél is a RENDSZER BIZTONSÁGI FOKÁT növeli!!!!

Ez szintiszta marhasag, ez csak a kommunikacio biztonsagat erositi.

Tegyük fel a netre ezt a szervert, de ne nyiss meg semmit... Ha létezik valamilyen TCP/IP vagy bármilyen exploit, ami megnyitja a gépet, akkor már egy szinttel lejjebb süllyedtél a biztonsági listán...

Nem mondod. :)

Ha valami "biztonságos", attól még nem növel egy rendszer biztonságán...
Szóval hol van a biztonság növelő rendszer???

Akkor lehet en ertem felre, leven ha mar vpn-be vannak szervezve a gepek akkor pl. egy szerveren nem kell a vakvilagba minden service-t engedelyezni, hanem eleg csak azon a halozaton igy tenni.

---
pontscho / fresh!mindworkz

Ha mar vpn-be szervezek gepeket, akkor evidens, h a kommunikaciot is biztositom vele mondjuk lehallgatas ellen.
És még biztosítod authentikácóról, adatintegritásról, stb...

Te, a helyi hálódon is van titkosítás?

Ellenpélda: POP3. Authentikáció van alatta, de titkosítás nem...

off
Mellesleg nem lehalgatás ellen kell biztosítani, hanem az adatokhoz való hozzáférést ellen... Tőlem bárki lehallgathatja a vonalat, ha nem jut hozzá az adatokhoz, mert azok be vannak kódolva...
/off

Ez szintiszta marhasag, ez csak a kommunikacio biztonsagat erositi.
Akárcsak a titkosított VPN is... A rendszer nem lesz biztonságosabb tőle... max bizonyos kommunikációs csatornák egyesek számára "nem lesznek olvashatók/értelmezhetők", természetesen értelmes emberi időn belül, átlagos erőforrások mellett. De ettől még maga a rendszer nem lesz sem biztonságosabb/védettebb, sem megbízhatóbb...
Ezek a fogalmak mást és mást jelentenek.

Akkor lehet en ertem felre, leven ha mar vpn-be vannak szervezve a gepek akkor pl. egy szerveren nem kell a vakvilagba minden service-t engedelyezni, hanem eleg csak azon a halozaton igy tenni.
Ez jó megközelítés, és még értelme is van.
De attól, hogy van egy VPN-ed, attól még az nem véd meg attól, hogy a VPN-en KERESZTÜL egy külső "biztonságosnak ítélt" gépen keresztül ne támadják meg a belső rendszered, vagy akár egy másik külső gépet...
Tehát nem biztosít védelmet...

A VPN csatornát titkosítja, ha arra állítod be... Ennyi, pont.

--
Debian Linux rulez... :D

Te, a helyi hálódon is van titkosítás?

A szolgaltatas tipusatol es az eleres modjatol fuggoen van.

És még biztosítod authentikácóról, adatintegritásról, stb...

vs.

Ez szintiszta marhasag, ez csak a kommunikacio biztonsagat erositi
Akárcsak a titkosított VPN is... A rendszer nem lesz biztonságosabb tőle...

Kicsit ellentmondas szagu.

max bizonyos kommunikációs csatornák egyesek számára "nem lesznek olvashatók/értelmezhetők", természetesen értelmes emberi időn belül, átlagos erőforrások mellett. De ettől még maga a rendszer nem lesz sem biztonságosabb/védettebb, sem megbízhatóbb.

Abbol a szempontbol igen, h ha az adott szolgaltatas csak azon keresztul erheto el, akkor elobb abba kell behatolni vagy a szerver valamilyen gyengeseget kihasznalva, vagy valamelyik kliens elozetes megkornyekezesevel. De a klienseket is meg lehet vedeni eleg keves plusz raforditassal. Volt olyan sajat rendszerunk amit a vegen olyan modszerrel tamadtak, h felhivtak a fonokom, h "van olyan feher gepunk szeretnenk csatlakozni, megbeszeltuk az xyz-vel", mert informatikai oldalrol akkor es ott nem tudtak vele mit kezdeni a tuzfalak, a vpn-ek, megfelelo szofterek es a jol kialakitott es betanitott policy-nak koszonhetoen. Ebbol ha egy komponens hianyzott volna, akkor az egesz koncepcio borult volna.

De attól, hogy van egy VPN-ed, attól még az nem véd meg attól, hogy a VPN-en KERESZTÜL egy külső "biztonságosnak ítélt" gépen keresztül ne támadják meg a belső rendszered, vagy akár egy másik külső gépet...

Szo sem volt arrol eddig a pillanatig, h egy vpn-re kotott geprol inditott tamadas sikeres lehet-e. Evidens, h az. De megsem lehet a vakvilagbol csak ugy ukmukfukk behatolni az adott gepre mondjuk egy foscsi szarcsi pop3d-nek koszonhetoen.

---
pontscho / fresh!mindworkz

A szolgaltatas tipusatol es az eleres modjatol fuggoen van.
Tehát akkor még lehet adatszivárgás, amit egy egyszerű sniffer is elkaphat... Pl. Gizike e-mail-ben elküldi a jelszavát a bankkártyájához Béla nevű barátjának... :D

- Ha ez az e-mail végig Gizikétől a szerverig, a szervertől Béláig egy VPN alatt menne, akkor a VPN biztosítaná az adatok hálózaton való titkosítását, integritását.
De már a szerveren és a klienseken plain text-ként lenne, és az authentikációt sem adná meg magának a levélnek.

Tehát a rendszer egésze, egysége nem lesz biztonságosabb... csak a csatorna...

Különben egyet értek, amit mondasz...
Nálam sem lehet csak úgy egy vpn kulccsal bejönni... Sőt... akár lopd el tőlünk... Akkor sem fog a rendszer Veled szóba állni... :D

Tehát amiről te beszélsz, az az hogy biztonságos kommunikációt biztosít két pont között...

--
Debian Linux rulez... :D

pedig alaposabban belegondolva abba, amit mondott, igaza van: a vpn nem az általános biztonságot növeli, hanem azt csinálja, hogy egy külső kapcsolatok nélküli gép esetén felmerül a külső kapcsolat igénye, akkor a lehetséges kapcsolati megoldások közül egy biztonságosabb verzió.

Nem az általános biztonságot növeli, azt minden egyes szoftverréteg, alkalmazás csökkenti, hanem a lehetséges kompromisszumok közül egy jobbfajta, amit a használati igény és a biztonság között kötsz. Mondjuk ahhoz képest, hogy kódolatlan kapcsolatot is csinálhatnál, ahhoz képest a vpn tényleg biztonságos. De a vpnes gép általános biztonsága rosszabb, mint ugyanazon gép vpn nélkül.

Oké, most játszunk úgy, hogy nincs végtelen erőforrásod.

Az ifconfig-hoz elég mondjuk 300 kódsor, míg az API-hoz kell mondjuk 3000 (Pontscho szerint nem). Külső scriptet egyébként is hív az OpenVPN (up/route-up/stb), az Y típusú hekkelés ezeken ugyanúgy megejthető, sőt, azok még a juzertől is kapnak inputot! A rövidebb kódot pedig könyebb karbantartani, auditálni, hackelni, portolni. Separation of concerns ésatöbbi.

Az inetd is egy biztonsággal kapcsolatba hozható eszköz (mi nem?), erre a hülyék micsinálnak, na mit?! - Há' forkolnak meg futtatnak orrba-szájba! Direkt erre írtak programot! Gondolom az NSA dörzsöli is a tenyerét!
- Na, szóval érted. Nem példa nélküli az, hogy valami -amin nagy a felelősség- forkol és futtat. Ergo az eljárás kiállta az idő próbáját, meg lehet oldani biztonságosan is.

A teljesítményről annyit, hogy server módban, ahol sok kliens várható, egyszer van ifconfig futtatás: a daemon indulásakor.

Azaz: mindent lehetne jobbá tenni, egy bonyolult szoftver sincs kész, de az erőforrások sajnos mindig végesek. Nem állítom, hogy natív API-val megcsinálni őrültség, de egy bevált (karbantartható, működő, hovatovább: biztonságos) megoldást lecserélni az, miközben egy rakat olyan terület van ahol nem működik, hiányzik, nem fenntartható valami és biztos, hogy az OpenVPN is tele van ilyennel, mint minden nagy project.

"Az elvek olyanok, mint a f*s: tartod ameddíg bírod." :)

"A rövidebb kódot pedig könyebb karbantartani, auditálni, hackelni, portolni."

kérdés, hogy rövidnek tekinthető-e az, hogy egy ifconfig kódot is hozzá kell számolni még ahhoz, ami fut...

"Az ifconfig-hoz elég mondjuk 300 kódsor, míg az API-hoz kell mondjuk 3000 (Pontscho szerint nem)."

Az ifconfig kimenetét nem kell parseolni véletlen? :)

----------------
Lvl86 Troll

Ott nagyon súlyos problémák vannak, ahol az ifconfig ismeretlen.
Egyébként sem értem ezt az egész hisztit, az ifconfigot rootként szokták futtatni. Ahhoz, hogy fusson, előbb root euidet kell szerezned, utána forkolhatod. Ha már root vagy, akkor már nem az ifconfigos bugokkal van baj, ha baj van.

Továbbra is úgy tűnik, a paranoiátok nem valós helyzetek elképzelésébe sodort.

Az openvpn szempontjából egy külső, tőle független, számára ismeretlen kódbázisból épített, a működés szempontjából viszont igencsak fontos komponens, aminek a biztonságos, és elvárásoknak megfelelő működését az openvpn NEM tudja sem garantálni, sem ellenőrizni, "csak" meg kell benne bíznia, hogy azt, és úgy teszi, amit és ahogy az openvpn fejlesztője elvárt tőle.

Amennyiben az openvpn számára az ifconfig az egyetlen, ismétlem, az EGYETLEN ilyen komponens, úgy a véleményed igaz.
De ha ezt ki mered jelenteni, akkorát röhögök, hogy beszakad a monitor.
A kernel, a libc, a ... stb stb stb. kilométeres lista jöhetne ide, még az is lehet, nem tudom, hogy az ssl library is idekeveredhetne, ami a kedvenc témád.

Szóval van ez az ifconfig, ami kicsi, egyszerű, hibátlanul működik a zembereknek évek óta (megnéztem a debian bugtrackert az előbb, nem voltak benne egetverő hibák), ezt kellene kidobni. Valójában miért?

Megnéztem az ifconfig wikipedia oldalát is, volt egy link a debian devel listára (ha jól emlékszem), azzal a 2009. márciusi levéllel kezdődik a thread, amiben a karbantartója kijelenti, hogy lecseréli az ifconfigot ip-re. Az érvelésed pontosan ugyanazokat az érveket sorolja, mint amit az a fickó ott írt, a probléma az, hogy ő sem tudott semmilyen értelmes indokot felhozni arra, hogy mi a búbánatos francért akarnak millió debian usert külön erőfeszítésre kényszeríteni, hogy felejtsék el az ifconfigot az ip kedvéért. Ennyi volt az összvélemény: az ip többet tud.

Szerintem azokat, akiknek egy ilyen döntés meghozatalában annyi az összvéleményük, hogy többet tud, azokat kezeltetni kellene és nem csomagokat kellene karbantartaniuk.

Szívesen látnám a válaszod az autós példa-kérdésre, hogy miért is nem jársz exeleroval.

Az ifconfig az egyik olyan külső komponens, amit az openvpn használ, és megbízik benne. De fölösleges, hiszen ugyanazt, amit ezzel a külső, számára ismeretlen komponenssel csináltat meg, azt saját maga, a kernelt birizgálva is megtudná csinálni, ismert, saját kódot használva - nem utolsó sorban takarékosabb módszerrel...

Az ip valóban többet tud, és mint írtam, van olyan eset, amikor az ifconfig nem alkalmas a feladat elvégzésére. A Debian-os társulat: "A kevesebbet tudó kernel az jobb kernel, és nem érdekel, hogy a felhasználók emiatt sz0pn1 fognak..." Ennyit arról, hogy nem akarják szivatni a felhasználóikat...

Ezt a másik threadben már felhoztad, aztán amikor vitattam, nem válaszoltál. Egy op.rendszerben rohadt sok komponens bízik meg egy másikban, mert másképp nem is működhetne. Ennek az elméletnek az egy nagy dilemmája, hogy akkor maga a kernel mitől megbízható?

Saxus szerint a kernel azért megbízható, mert nélkülözhetetlen. Igazán meggyőző.