Informatika
- Téma indítója xeqev
- Indítva
-
Ha nem vagy kibékülve az alapértelmezettnek beállított sötét sablonnal, akkor a korábbi ígéretnek megfelelően bármikor átválthatsz a korábbi világos színekkel dolgozó kinézetre.
Ehhez görgess a lap aljára és a baloldalon keresd a HTKA Dark feliratú gombot. Kattints rá, majd a megnyíló ablakban válaszd a HTKA Light lehetőséget. Választásod a böngésződ elmenti cookie-ba, így amikor legközelebb érkezel ezt a műveletsort nem kell megismételned. -
Az elmúlt időszak tapasztalatai alapján házirendet kapott a topic.
Ezen témában - a fórumon rendhagyó módon - az oldal üzemeltetője saját álláspontja, meggyőződése alapján nem enged bizonyos véleményeket, mivel meglátása szerint az káros a járványhelyzet enyhítését célzó törekvésekre.
Kérünk, hogy a vírus veszélyességét kétségbe vonó, oltásellenes véleményed más platformon fejtsd ki. Nálunk ennek nincs helye. Az ilyen hozzászólásokért 1 alkalommal figyelmeztetés jár, majd folytatása esetén a témáról letiltás. Arra is kérünk, hogy a fórum más témáiba ne vigyétek át, mert azért viszont már a fórum egészéről letiltás járhat hosszabb-rövidebb időre.
-
Az elmúlt időszak tapasztalatai alapján frissített házirendet kapott a topic.
--- VÁLTOZÁS A MODERÁLÁSBAN ---
A források, hírek preferáltak. Azoknak, akik veszik a fáradságot és összegyűjtik ezeket a főként harcokkal, a háború jelenlegi állásával és haditechnika szempontjából érdekes híreket, (mindegy milyen oldali) forrásokkal alátámasztják és bonuszként legalább a címet egy google fordítóba berakják, azoknak ismételten köszönjük az áldozatos munkáját és további kitartást kívánunk nekik!
Ami nem a topik témájába vág vagy akár csak erősebb hangnemben is kerül megfogalmazásra, az valamilyen formában szankcionálva lesz
Minden olyan hozzászólásért ami nem hír, vagy szorosan a konfliktushoz kapcsolódó vélemény / elemzés azért instant 3 nap topic letiltás jár. Aki pedig ezzel trükközne és folytatná másik topicban annak 2 hónap fórum ban a jussa.
Innen: http://htka.hu/kozosseg/discussion/47979/biztpol-oroszorszag-es-a-szovjetunio-utodallamai/p102
Na igen, eléggé durva (egyébként én is olvastam valamikor, csak már nem emlékeztem rá). Elméletben elképzelhető és tényleg nagyon nehéz lenne észrevenni/kivédeni, amennyiben bérgyártóval gyártatsz. De! A cikkben taglalt eljárás, ha jól értem, leginkább a dedikált hardveres véletlenszámgenerátoroknál (és talán az AES-NI és hasonlók hardveres gyorsításáért felelős részeknél) működhetne igazán, tehát, amennyiben tisztán szoftveres eljárásokat használsz (ez ugyan lassabb lesz és a véletlenszámok generálása esetén talán nem is annyira "véletlen", mint egy nem mókolt hardveres, de ez az ára az akár megalapozott paranoiának), akkor nem akkora veszély.
Ez igaz. De ha speciális igényeik is vannak, akkor még mindig jobban járnak egy Unix/Linux variánssal, ahol tetszőlegesen bele is nyúlhatnak a kernelbe.
Szintén igaz lehet, bár én nem a "hátsó kapu", inkább a "biztonsági hiba" kifejezést használnám arra, amivel esetleg "<b>tele</b> van". És Windowsban legalább ennyi van, plusz a szándékos hátsó ajtók, csak ugye, a zárt forrás miatt jóval kevesebben láthatnak rá.
És ezzel mégis mi a fenét akarsz mondani? Hogy minden Unix-szerű, valóban nyílt forrású oprendszer csakis azért létezik, hogy a biztonság hamis illúzióját keltve jól átverje az embereket?
Igen bazdmeg, előfordulnak minden kódban hibák és néha átcsúszhat pár a validáción is, ha van olyan, akár még szándékos rosszindulatú kód is. Na és? Aztán észreveszik, javítják. 100%-ig hibátlan és biztonságos szoftver nem létezik.
Szuper, futtatja a Windowst, az x86 utasításkészlet emulációjával, és? Mit akarsz ezzel mondani?
Ismét csak, és? A nyílt forrás nem azt jelenti, hogy emiatt teljesen hibamentes, vagy te azt hitted? XD A Windowsban (és a többi májkrémszaft termékben) persze egy hiba sincs (backdoorról nem is beszélve), nem volt és nem is lesz, ugye? És, hogy biztonságosabb-e az open source által nyújtot transzparencia? Naná!
Forrás, vagy valami a szándékos szabotálásra?
Persze, senki nem validálja....Linus meg egy seggfej, ugye? Meg mindenki más, akinek tetszik a nyílt forráskód és veled ellentétben nem cuppan rá önzetlenül a Ballmer-félék hosszúcicijére, ahányszor csak alkalma adódik rá. Hát tudom én! XD
Na igen, eléggé durva (egyébként én is olvastam valamikor, csak már nem emlékeztem rá). Elméletben elképzelhető és tényleg nagyon nehéz lenne észrevenni/kivédeni, amennyiben bérgyártóval gyártatsz. De! A cikkben taglalt eljárás, ha jól értem, leginkább a dedikált hardveres véletlenszámgenerátoroknál (és talán az AES-NI és hasonlók hardveres gyorsításáért felelős részeknél) működhetne igazán, tehát, amennyiben tisztán szoftveres eljárásokat használsz (ez ugyan lassabb lesz és a véletlenszámok generálása esetén talán nem is annyira "véletlen", mint egy nem mókolt hardveres, de ez az ára az akár megalapozott paranoiának), akkor nem akkora veszély.
Ez igaz. De ha speciális igényeik is vannak, akkor még mindig jobban járnak egy Unix/Linux variánssal, ahol tetszőlegesen bele is nyúlhatnak a kernelbe.
Szintén igaz lehet, bár én nem a "hátsó kapu", inkább a "biztonsági hiba" kifejezést használnám arra, amivel esetleg "<b>tele</b> van". És Windowsban legalább ennyi van, plusz a szándékos hátsó ajtók, csak ugye, a zárt forrás miatt jóval kevesebben láthatnak rá.
És ezzel mégis mi a fenét akarsz mondani? Hogy minden Unix-szerű, valóban nyílt forrású oprendszer csakis azért létezik, hogy a biztonság hamis illúzióját keltve jól átverje az embereket?
Igen bazdmeg, előfordulnak minden kódban hibák és néha átcsúszhat pár a validáción is, ha van olyan, akár még szándékos rosszindulatú kód is. Na és? Aztán észreveszik, javítják. 100%-ig hibátlan és biztonságos szoftver nem létezik.Szuper, futtatja a Windowst, az x86 utasításkészlet emulációjával, és? Mit akarsz ezzel mondani?
Ismét csak, és? A nyílt forrás nem azt jelenti, hogy emiatt teljesen hibamentes, vagy te azt hitted? XD A Windowsban (és a többi májkrémszaft termékben) persze egy hiba sincs (backdoorról nem is beszélve), nem volt és nem is lesz, ugye?
És, hogy biztonságosabb-e az open source által nyújtot transzparencia? Naná! Forrás, vagy valami a szándékos szabotálásra?
Persze, senki nem validálja....Linus meg egy seggfej, ugye? Meg mindenki más, akinek tetszik a nyílt forráskód és veled ellentétben nem cuppan rá önzetlenül a Ballmer-félék hosszúcicijére, ahányszor csak alkalma adódik rá. Hát tudom én! XD
Én úgy értettem (párszor meghallgattam), hogy azt mondta, "do", vagyis hogy beletette és bólogatott hozzá. Nekem viccelésnek tűnik, amin nevettek is.
Szerintem meg igen. Egyrészt, mert nyílt, ezért a "több szem többet lát" érvényesül, másrészt, mert feltételezhetően a fejlesztők túlnyomó többségének nem érdeke, hogy szándékosan backdoort, vagy más rosszindulatú kódot tegyen bele. Míg egy cégnél, mint a Microsoft, elég csak a vezetőknek kiadni a parancsot és már megy is bele a kívánt kód.
Ja, úgy 20 millió sor körül lehet most. Hát, rá kéne állítani jópár embert, az biztos. De ha annyira biztosra akarnak menni...
Mondjuk a CAD-nél én a komolyabbakra, mint pl. a CATIA gondoltam, amikkel hajókat, tengókat, meg repülőket terveznek.
De ingyenes, nyílt forrásúak között ott van a BRL-CAD is, bár az ugye eléggé kötődik az amerikai hadsereghez. Ja, aztán a változtatásaikat szépen ki kellene adniuk, legalábbis ha be akarják tartani a felhasználási feltételeket.
Jelenleg nincs bizonyíték arra, hogy backdoor-ok lennének a Windows-ban, talán vannak, talán nincsenek. (Szerintem vannak.) De az oroszoknak ez a bizonytalanság elfogadhatatlan (kellene, hogy legyen), csakhogy ugyanez a bizonytalanság fennáll a Linux esetében is, az sem elfogadható, nincs rá ok, hogy más elbírálás alá essen, csak azért, mert nyílt forráskódú rendszer.
Ezt a kijelentésedet nem hiszem, hogy alá tudod támasztani valamivel.
Éppenséggel Linus valóban az, elég csak elolvasni néhány megnyilvánulását a fejlesztői levelezőlistákon. A nyílt forráskóddal meg nincs baj, csak néhány túlbuzgó rajongójával akik olyan állításokkal állnak elő amiket nem tudnak objektív tényekkel megtámogatni.
A kernelfejlesztők túlnyomó része amerikai cégek alkalmazásában áll, és feltételezhetően ők is azt teszik amit a feletteseik utasítanak nekik.
Ja, de hogy állítod össze azt a csapatot amely 100%-os bizonyossággal megtalálja az összes sebezhetőséget/backdoor-t? Mert ha csak 90%-os valószínűséggel találnak meg egy biztonsági hibát, az a rendszerbe vethető bizalom szempontjából éppen olyan, mintha 0%-os valószínűséggel találnák meg.
A statisztika amit linkeltem a Linux kernel 2.6-os ágában azonosított sebezhetőségekről (biztonsági hibákról) szól. Nincs ennek köze más szoftverhez, sem üzemeltetési dolgokhoz. Bocs, de a hozzászólásaid alapján az önbizalmad amellyel az állításaidat előadod a Dunning–Kruger hatásból ered: http://hu.wikipedia.org/wiki/Dunning%E2%80%93Kruger_hat%C3%A1s.
Amúgy én boldogan folytatom a diskurzust, de szerintem eljutottunk oda, hogy inkább másik helyen kellene... (Ahogy arra Joker is utalt.)</blockquote>
Komolyan, nezzel utanna, hogy mi a kulonbseg a Linux Kernel es egy Linux Server kozott.
Először is: szoftver fejlesztő vagyok, talán több rálátásom van ezeknek a működésére, mint pl. egy gépésznek vagy "áltaános managernek". Ezért is nem hegesztéses témánál osztom az észt. Akinek nem inge ne vegye ezt magára.
</blockquote>
</blockquote>
Lehet bele drivereket írni a kernel módosítása nélkül. Lehet bővíteni, ugynis olyan architektúrát terveztek neki a kezdetektől, hogy a mag módosítása nélkül lehessen bővíteni... Ez nevezik angolul Software Engineering-nek, ami az OSS projektekre ritkán jellemző.
http://hup.hu/cikkek/20101215/az_fbi_fejlesztoket_fizetett_azert_hogy_azok_hatso_kapukat_epitsenek_az_openbsd_crypto_keretrendszerebe
Ami azt illeti, az openbsd azt állította, hogy minden commitot megreviewztak. Mégis átcsúszott. Nagyon súlyos következményeyei voltak (mindössze 1 byte entrópia a random poolban: nem véletlenek a véletlenszámok)
Ugyenez a debiannál: http://hup.hu/cikkek/20080513/biztonsagi_hiba_az_openssl-ben_egy_debian-os_patch_miatt
Ugyanez az openssl-nél: http://hup.hu/cikkek/20140408/heartbleed_bug_sulyos_openssl_sebezhetoseget_javitottak
Igen bazdmeg, előfordulnak minden kódban hibák és néha átcsúszhat pár a validáción is, ha van olyan, akár még szándékos rosszindulatú kód is. Na és? Aztán észreveszik, javítják. 100%-ig hibátlan és biztonságos szoftver nem létezik.
</blockquote>
Azt akarom mondani, hogy a vallási fanatikusok érveinek ellenére az opensource semmi pluszt nem ad.
Ezernyi példát lehet erre felhozni. Egy példa az említett openbsd-s backdoorra (lásd fent), mivel az openbsd volt sokáig a legnagyobb arcú mennyire biztonságosak vagyunk paprikajancsi banda. Emellett a windowsban több aktív és passzív védelmi rendszer van mint a linuxban, ami még a legjobban áll ilyen téren az open source operációs rendzserek közt (némileg le van maradva, többek közt PaXteam munkásságának szabotálása miatt).
A forráskód egyébiránt a biztonsági elemzéshez egyáltalán nem szükséges. Számos eszköz áll a szakértő kezek rendelkezésére, például a méltán híres IDA Pro.
És, hogy biztonságosabb-e az open source által nyújtot transzparencia? Naná!
</blockquote>
Májkrémszaft... Rendben, ennek ellenére megpróbálkozom észérvekkel.
Nem a hibátlanság a kérdés. Egyfelől az nehezet (tipikusan sehogy sem) bizonyítható, egyáltalán a helyes működés specifikációja feltétel. Az általános minőség. Amellett, hogy egy kereskedelni vendor számára a profit maximalizálsá fontos, támogatást is ad, és a vevők visszatérését is várja jó esetben (az IBM pl nem ilyen, aki használta már szoftvereik tudja, hogy fájdalom a termékeik többségének használata.)
Az opensource transzparencia semmit sem jelent. Mellesleg a Microsoft rengeteg fontos termékt open sourcccá, de legalábbis nyilvánosan olvashatóvá tett. Az, hogy az opensourcehoz bárki hozzájárulhat, kockázatokat rejt. Az, hogy nem feltétlen felügyelt folyamatok mentén történik a változások befogadása, szintén további kockázatokat rejt.
url az openbsd-s bugra fentebb.
</blockquote>
http://pax.grsecurity.net/
A kernelbe olvasztásától elzárkóznak a fejlesztők. A (magyar) készítő tavaly életműdíjat kapott az ITsec terén végzett munkásságáért. A windowsban előbb implementálták az általa leírt módszereket hivatalosan, mint a linuxba befogadták volna a rendzseresen küldött patcheit.
Az Ulrich Drepper nevű idióta is híres a hibák letagadásáról, amik többször biztonsági vonatkozásúak is. Szlogenje: stop reopening the bug. Annyi probléma van csupán, hogy a glibc karbantartója.
Az opensource hozzállásról amúgy tanúskodik az is, hogy a bugzilla F/OSS hibakezelőben van olyan kimenetel, hogy WONTFIX. Ez a hozzállásról sokat elmond. Persze önkéntesektől nem vrható el az, hogy a móka és kacagás részen túl (alkotó munka) mondjuk unalmas és pepecs dolgokat is csináljanak (unit tesztek, regressziós tesztek, integrációs tesztek, funkcionális specifikáció, funkcionális tesztek, dokumentáció írás, satöbbi, de ezek másutt megtörténnek. Nem lelkes, nem boldog, de megfizetett emberek által.)
... és tényleg nagyon nehéz lenne észrevenni/kivédeni, amennyiben bérgyártóval gyártatsz. ... ha jól értem, leginkább a dedikált hardveres véletlenszámgenerátoroknál (és talán az AES-NI és hasonlók hardveres gyorsításáért felelős részeknél) működhetne igazán, tehát, amennyiben tisztán szoftveres eljárásokat használsz ... akkor nem akkora veszély.
</blockquote>
- egyáltalán nem felderíthető utólag nem desktruktív módszerekkel
- az egész kriptográfia a jóminőségű véletlenszámokon múlik
- szoftveres véletlenszám? úgy hiszem nem vagy járatos a kriptográfiában. A lényeg: a szoftver determinisztikus. PRNG lehet sw-es, de az komoly kriptora alkalmatlan.
Ez igaz. De ha speciális igényeik is vannak, akkor még mindig jobban járnak egy Unix/Linux variánssal, ahol tetszőlegesen bele is nyúlhatnak a kernelbe.
</blockquote>
Lehet bele drivereket írni a kernel módosítása nélkül. Lehet bővíteni, ugynis olyan architektúrát terveztek neki a kezdetektől, hogy a mag módosítása nélkül lehessen bővíteni... Ez nevezik angolul Software Engineering-nek, ami az OSS projektekre ritkán jellemző.
A szándékos hátsó ajtó a windowsban semmivel sem valószínűbb, mint a linuxban. Mindkettőbe álcázva csempészik bele fedett ügynökök az ilyeneket. Szok fogalmatlan amatőr hobbista "segít".
http://hup.hu/cikkek/20101215/az_fbi_fejlesztoket_fizetett_azert_hogy_azok_hatso_kapukat_epitsenek_az_openbsd_crypto_keretrendszerebe
Ami azt illeti, az openbsd azt állította, hogy minden commitot megreviewztak. Mégis átcsúszott. Nagyon súlyos következményeyei voltak (mindössze 1 byte entrópia a random poolban: nem véletlenek a véletlenszámok)
Ugyenez a debiannál: http://hup.hu/cikkek/20080513/biztonsagi_hiba_az_openssl-ben_egy_debian-os_patch_miatt
Ugyanez az openssl-nél: http://hup.hu/cikkek/20140408/heartbleed_bug_sulyos_openssl_sebezhetoseget_javitottak
És ezzel mégis mi a fenét akarsz mondani? Hogy minden Unix-szerű, valóban nyílt forrású oprendszer csakis azért létezik, hogy a biztonság hamis illúzióját keltve jól átverje az embereket?
Igen bazdmeg, előfordulnak minden kódban hibák és néha átcsúszhat pár a validáción is, ha van olyan, akár még szándékos rosszindulatú kód is. Na és? Aztán észreveszik, javítják. 100%-ig hibátlan és biztonságos szoftver nem létezik.</blockquote>
Azt akarom mondani, hogy a vallási fanatikusok érveinek ellenére az opensource semmi pluszt nem ad.
Ezernyi példát lehet erre felhozni. Egy példa az említett openbsd-s backdoorra (lásd fent), mivel az openbsd volt sokáig a legnagyobb arcú mennyire biztonságosak vagyunk paprikajancsi banda. Emellett a windowsban több aktív és passzív védelmi rendszer van mint a linuxban, ami még a legjobban áll ilyen téren az open source operációs rendzserek közt (némileg le van maradva, többek közt PaXteam munkásságának szabotálása miatt).
A forráskód egyébiránt a biztonsági elemzéshez egyáltalán nem szükséges. Számos eszköz áll a szakértő kezek rendelkezésére, például a méltán híres IDA Pro.
Azt, hogy az x86 emulációt miért tették bele, ha csak linuxot akarnának futtatni rajta? Egyébiránt az elbrus eléggé zsákutcának tűnik. A VLIW jövője kétséges, nem vagyok meggyőzve a megközelítés optimális mivoltáról (hogy miért: az IA64 bukásánál közrejátszó technikai tényezők áttanulmányozását javaslom).
Ismét csak, és? A nyílt forrás nem azt jelenti, hogy emiatt teljesen hibamentes, vagy te azt hitted? XD A Windowsban (és a többi májkrémszaft termékben) persze egy hiba sincs (backdoorról nem is beszélve), nem volt és nem is lesz, ugye?
És, hogy biztonságosabb-e az open source által nyújtot transzparencia? Naná! </blockquote>
Májkrémszaft... Rendben, ennek ellenére megpróbálkozom észérvekkel.
Nem a hibátlanság a kérdés. Egyfelől az nehezet (tipikusan sehogy sem) bizonyítható, egyáltalán a helyes működés specifikációja feltétel. Az általános minőség. Amellett, hogy egy kereskedelni vendor számára a profit maximalizálsá fontos, támogatást is ad, és a vevők visszatérését is várja jó esetben (az IBM pl nem ilyen, aki használta már szoftvereik tudja, hogy fájdalom a termékeik többségének használata.)
Az opensource transzparencia semmit sem jelent. Mellesleg a Microsoft rengeteg fontos termékt open sourcccá, de legalábbis nyilvánosan olvashatóvá tett. Az, hogy az opensourcehoz bárki hozzájárulhat, kockázatokat rejt. Az, hogy nem feltétlen felügyelt folyamatok mentén történik a változások befogadása, szintén további kockázatokat rejt.
url az openbsd-s bugra fentebb.
Forrás, vagy valami a szándékos szabotálásra?
</blockquote>
http://pax.grsecurity.net/
A kernelbe olvasztásától elzárkóznak a fejlesztők. A (magyar) készítő tavaly életműdíjat kapott az ITsec terén végzett munkásságáért. A windowsban előbb implementálták az általa leírt módszereket hivatalosan, mint a linuxba befogadták volna a rendzseresen küldött patcheit.
Az Ulrich Drepper nevű idióta is híres a hibák letagadásáról, amik többször biztonsági vonatkozásúak is. Szlogenje: stop reopening the bug. Annyi probléma van csupán, hogy a glibc karbantartója.
Az opensource hozzállásról amúgy tanúskodik az is, hogy a bugzilla F/OSS hibakezelőben van olyan kimenetel, hogy WONTFIX. Ez a hozzállásról sokat elmond. Persze önkéntesektől nem vrható el az, hogy a móka és kacagás részen túl (alkotó munka) mondjuk unalmas és pepecs dolgokat is csináljanak (unit tesztek, regressziós tesztek, integrációs tesztek, funkcionális specifikáció, funkcionális tesztek, dokumentáció írás, satöbbi, de ezek másutt megtörténnek. Nem lelkes, nem boldog, de megfizetett emberek által.)
Persze, senki nem validálja....Linus meg egy seggfej, ugye? Meg mindenki más, akinek tetszik a nyílt forráskód és veled ellentétben nem cuppan rá önzetlenül a Ballmer-félék hosszúcicijére, ahányszor csak alkalma adódik rá. Hát tudom én! XD</blockquote>
</blockquote>
- Linus egy seggfej
- a QA annyi, hogy lefordul-e a kód. Néha annyi sem: https://lkml.org/lkml/2013/9/2/402
A lényeg: ez a jéghegy csúcsa. Az opensource szart sem ér biztonsági szempontból. Nem jobb. Nem állítom, hogy szükségszerűen rosszabb. Ráadásul a nagy vevők megkapják a kódot elemzésre. A fordítót is, mindent, ellenőrizhetik, hogy a binárisok azok-e amik a kapott kódból fordulnak. A kódot statikus elemzővel mindenüztt nézik, de egy nagy kereskedelmi cégnél nagyobb valószínűséggel.
A kernel az egyetlen olyan komponens amely szükségszerűen
része minden Linux alapú szervernek. És a kernel kódbázisában szereplő hibák ezáltal eljutnak az egyes disztribúciókig. Bár az igaz hogy magasabb rétegekben futó komponensek vagy egyes opcionális kernelmodulok adott esetben megnehezíthetik/ellehetetleníthetik <b>bizonyos</b> sebezhetőségek kihasználását, még így is akad bőven.
Ja, aztán a változtatásaikat szépen ki kellene adniuk, legalábbis ha be akarják tartani a felhasználási feltételeket.
Ha belső (kormányzati, stb.) használatra szánják, éspedig arra akarják az ARM-os procijukat is leginkább, akkor ez nem hinném, hogy túlzottan érdekelné őket...
Teljesen egyértelmű bizonyíték nincs, de ott volt az NSAKEY-ügy, meg most a Win 8-cal és a TPM 2.0-val megy a cirkusz... Szóval az erős gyanú azért fennáll. Igen, a Linux esetében is elképzelhető, hogy akad benne szándékos backdoor. De szerintem kisebb az esélye.
Igazad van, nem fogalmaztam elég pontosan. Akkor mégegyszer, bizonyos nagyságrendnél, vagyis az akár többmillió soros kódok esetén, nem lehet azt feltételezni, hogy teljesen hibamentesek lehetnek.
Alátámasztás? Nézz szét az űrhajózásban, vagy a katonai rendszereknél, amik pedig a lehető legjobban "hibaellenőrzöttek".
Egy példa, szénné tesztelt OS és programok esetén:
http://www.defenseindustrydaily.com/f22-squadron-shot-down-by-the-international-date-line-03087/
Vagy egy másik:
http://en.wikipedia.org/wiki/Cluster_%28spacecraft%29#Launch_failure
De akad még jópár ilyen és ezek csak a valóban súlyos és publicitást is kapott hibák.
Egy részük pedig nem és ha ők észrevesznek valamit, akkor azt szóvá teszik. Ezzel szemben egy cégnél ugye van szerződés, meg titoktartási kötelezettség és ezért bármit is "lásson" az alkalmazott, ha nem akar egy komoly pert (amit garantáltan el is veszítene) kapni a nyakába, akkor szépen befogja a pofáját. Ha meg az NSA is benne van, akkor még hazaárulással is vádolhatnák a kiszivárogtatásért, ezért aztán biztosan be is fogja fogni. Snowden sorsán kevesen akarnának osztozni.
Ha teljesen saját oprendszert írna az a bizonyos csapat, annál sem lehetne 100%-os hibamentesség, mint ahogy írtam is fentebb, ebből következően 100%-os biztonsági hibamentesség sem.
Csak a szándékos backdoort lehetne igen nagy eséllyel kizárni úgy. Akkor meg, ha szerinted csakis a 0%-os hibalehetőség az elfogadható, akkor mi a megoldás?
1. Minden szériából pár darabot szúrópróbaszerűen szétkaphatnak nyugodtan, vizsgálat céljából. Persze ennek csak akkor van értelme, ha tudják, mit keressenek és hol...
2. Tudom.
3. Nem túlzottan, az igaz. De akkor sem értek egyet azzal, hogy a nem "dedikált hardveres" véletlenszámgenerátor nem alkalmas "komoly kriptora". Tudom, kissé már elcsépelt példa, de:
http://news.techworld.com/security/3228701/fbi-hackers-fail-to-crack-truecrypt/
És feltételezem, az NSA sem szórakozott volna ezzel, ha annyira könnyű lenne törni az olyan titkosítást, amihez szoftveres PRNG-vel generált véletlenszámokat használtak:
http://en.wikipedia.org/wiki/Dual_EC_DRBG
A BSD-s, FBI-os téma tényleg kemény! De legalább kiderült. A másik kettő meg, nos, előfordulnak ilyenek. Bár, mind a kettő kb. 2 évig "élt", az azért nem kevés...
Szerintem nagyobb eséllyel derül ki (a nyilvánosság számára is) egy nyílt forrású cuccnál akár a backdoor, akár a hiba (ez utóbbi széles körű ismertté válása persze nem feltétlenül jó, ha még nincs rá javítás), mint egy zártnál.
Nem tudom... Talán szélesebb körben is forgalomba akarták, akarják hozni, konkurenciát akartak állítani (legalább) az orosz piacon az AMD és Intel prociknak, ehhez pedig kell az x86 (és Windows) támogatás. Mert azért úgy minimum 80% a Windowsok részesedése desktopon globálisan is és ezt nem hagyhatták figyelmen kívül.
Egyébként ARM-ra is akarnak x86 emulátort:
http://www.xbitlabs.com/news/cpu/display/20121002212516_Startup_Develops_x86_Emulator_for_ARM_Microprocessors.html
Egyetértek. Én is azt írtam itt korábban, hogy a VLIW, mint olyan, nem szerencsés választás és persze az Itaniummal példálóztam, merthogy adja magát a párhuzam.
Itt ugye állami szintről beszélünk, mármint az oroszoknál és ez esetben. Nekik nem kell minden szart implementálniuk a saját, secure rendszerükhöz, olyasmiket, amivel "bárki hozzájárult".
Fognak egy végletekig lecsupaszított kernelt, aztán tetszőlegesre szabják, meg hozzáteszik, ami nekik kell. Van egy csomó programozó arrafelé, akik jók is, legfeljebb csinálnak egy céget,
aminek a feladata a saját rendszerük karbantartása és fejlesztése lesz, házon belül. Egyfajta hardverre kell optimalizálniuk, a saját ARM-jukra, emiatt rengeteg dolog egyszerűbb is lesz.
Ja, megtaláltam, hát szép... http://bug-chasers.blogspot.hu/2011/03/just-use-supported-kernel-stop.html
A PaX esetén viszont, az hogy nem teszik bele a kernelbe, egy dolog, viszont a grsecurity pakkot a vanilla kernelre bárki felrakhatja, aki akarja.
Nem néztem ugyan utána, de nem hinném, hogy a kritikus biztonsági hibák wontfixet kapnának...
Hát azért most, ha nagyon akarnék, tudnék jópár olyan példát hozni, ahol ismert a hiba, csak a kedves gyártó leszarja és valószínűleg az életben nem lesz rá javítás, vagyis patch. Következő kiadásban (amit persze meg kell venni pénzért) majd javítják...
Az USA védelmi minisztériuma szerint elég jó pedig.
http://www.spi.dod.mil/lipose.htm
Közelednek az álláspontok.
Nem rosszabb. Akkor meg miért ne használhatnának open source (alapú) rendszert a "paranoiás" ruszkik? Azzal sem lesz nekik rosszabb, mintha Windowst használnának.Az annak az arroganciának és személyeskedésednek szólt csupán, amivel indítottál. Amúgy jól látod, nem vagyok szoftverfejlesztő.
De nem is állítottam ilyet soha.Amint azt írtam egy informatikai rendszer biztonsága az én véleményem szerint egy bináris változó: biztonság vagy van, vagy nincs. Ennek ellenére is lennének biztonsági előnyei egy saját rendszer létrehozásának, még akkor is, ha elfogadjuk az állításodat, miszerint nem lehet bizonyos komplexitási szint felett hibátlan rendszert létrehozni. (Bár ez az állítás nem hinném, hogy formális módszerekkel bizonyítható.)
Hogy miért? Onnantól kezdve, hogy egy rendszer hibákat, potenciális behatolási pontokat tartalmaz, már csak a befektethető erőforrások mennyiségén múlik, hogy ezeket sikerül-e kihasználni. Csakhogy amíg a Linux esetében ezt pontosan 0 (nulla) dollár befektetéssel végre tudja hajtani az, aki ismeri a feltehetően jelen lévő backdoor-okat, addig egy új, saját fejlesztésű rendszer esetében ez már tényleges befektetést igényel. A bevethető erőforrások (pénz, ember) pedig véges mennyiségben állnak rendelkezésre, még az amerikai kormányzat számára is.
A másik dolog pedig, hogy egy új rendszer esetében lehetőség lenne végre szakítani azzal a 40 éves architektúrával, amelyre a Linux épül. Ennek biztonsági vonzata is lenne, ugyanis valószínűleg NAGYSÁGRENDEKKEL csökkenteni lehetne a fajlagos hibaarányt a 2014-es év technológiai fejlettségének megfelelő tervezési paradigmák alkalmazásának segítségével.
Ezt ugye nem gondolod komolyan, hogy a biztonság bináris változó? Ha mégis, akkor elárulom, nem az.
A biztonságnak szintjei vannak, de tökéletes biztonság nem létezik, nem létezhet. Szerintem igazából nem is kell magyaráznom, hogy miért nem.Az meg, hogy hibátlan rendszert létre lehetne-e hozni? Gyakorlatban nem! Ember, az F-22-n a létező legtutibb OS futott, az INTEGRITY DO-187B http://www.ghs.com/products/safety_critical/integrity-do-178b.html
http://www.ghs.com/news/20110316_10th_INT-178B_anniv.html
És mégis becsúszott legalább egy hiba.
És ez pontosan így van minden rendszernél. Mert tartalmaznak hibákat, amik aztán ki is használhatóak, ha felfedezik azokat. Ha nem, a brute force még mindig ott van. Sok esetben persze ez "hasznos" idő alatt nem végrehajtható, legalábbis az ismert eszközökkel és módszerekkel. Na de lehetnek új matematikai megközelítések, avagy hardverek is erre. pl.: http://www.extremetech.com/computing/173898-the-nsa-is-building-a-quantum-computer-to-crack-encryption
És akkor máris +b.szhatod a tutinak <b>hitt</b> biztonságodat.
Igen, ez így van. Viszont, egy teljesen saját rendszer megírása a nulláról elég sok időbe és pénzbe kerül, na meg az aztán nem nagyon lesz kompatibilis semmilyen jelenlegi programmal, API-val, framework-el... Tehát minden alkalmazást, amire szükségük van, a grafikus API-tól kezdve az összes programig, nekik kell megcsinálniuk a rendszerükre, ha natívan akarják futtatni, ez pedig mégtöbb idő és pénz. Igaz, ez is növelné a biztonságot.
Így is lehet nézni, na meg úgy is, hogy a "40 éves" rendszer legalább kiforrott már, ezzel szemben egy új meg nem. Szóval szerintem a nem szándékos hibákat nagyságrendekkel azért nem lehetne csökkenteni.
Az informatikában, ott bináris változó, más területeken nem feltétlenül. Mégis milyen metrika alapján tennél különbséget két NEM biztonságos informatikai rendszer között, milyen alapon jelentenéd ki, hogy az egyik biztonságosabb, mint a másik?Ezt ugye nem gondolod komolyan, hogy a biztonság bináris változó? Ha mégis, akkor elárulom, nem az.
Közelítsünk rá a dologra a másik irányból: van az a komplexitási szint, amely alatt még nem csak álom a hibamentesség, ebben egyetértesz? (Gondolhatunk akár egy egyszerű „Hello world” programra, bár az nem végez hasznos feladatot.) Ha ezt elfogadod, akkor viszont adódik a kérdés: hol húzod meg azt a határt, amely felett már lehetetlen hibamentes rendszert összerakni. 100 kódsor még belefér, de 101 már nem?
Nem könnyű ezt a problémát matematikailag megfogni, már csak azért sem, mert egy rendszer komplexitását nem éppen egyszerű számszerűleg kifejezni. De az azért belátható, hogy ahogy nő a rendszer komplexitása, úgy nő a hiba (vagy hibák) előfordulásának esélye, és lényegében ezzel párhuzamosan csökken a „hibamentesség” esélye, de ez soha nem éri el a nullát. (Nem tudom, mennyire jól fogalmaztam ezt meg, de azért remélem átjött a mondanivaló.)
Persze, én ezt tudom, írtam is még korábban (a másik helyen) hogy egy saját operációs rendszer megalkotása iszonyatosan drága lenne a járulékos költségekkel együtt.
A Linux az elképzelhető legegyszerűbb, monolitikus architektúrára épül. Ez a modell már a Linux megalkotásakor is elavultnak számított, előnye nincs, (biztonsági) hátránya annál inkább.
Nem tudom, mondanak-e neked valamit a Midori, illetve a Singularity szavak:
http://en.wikipedia.org/wiki/Singularity_%28operating_system%29
http://en.wikipedia.org/wiki/Midori_%28operating_system%29
Két kísérleti operációs rendszerről van szó, mind a kettő a Microsoft fejlesztése, ez egyiknek a forráskódja is hozzáférhető. Mindkét projekt célja egy olyan operációs rendszer megalkotása, amelyben a natív kód aránya a lehető legkisebb, és a rendszer (beleértve a kernelt és a drivereket is) legnagyobb része menedzselt kódból áll. Nem tudom mennyi programozási tapasztalatod van, szóval megpróbálom kicsit közelebb hozni, hogy ez mit is jelent. A menedzselt kód esetében a programozók nem tudnak elkövetni olyan memóriakezelési (és más típusú) hibákat, amelyeket natív kód esetében igen. Ezen hibák elkövetésére a használt programozási nyelv (és az azt támogató infrastruktúra) egyszerűen nem ad lehetőséget, ugyanúgy, mint a Java és C# esetében.
Hát például ilyen tervezési alapelvek felhasználásával lehetne csökkenteni a fajlagos hibaarányt, és szerintem nem túlzás azt feltételezni, hogy nagyságrendekkel.
Szerencsére nem nekem kell különbséget tennem.
De az EAL pl. egy jó közelítés:http://en.wikipedia.org/wiki/Evaluation_Assurance_Level
Igen és nem. Abban egyetértek, hogy egy "Hello world"-szintű, méretű kódnál a hiba gyakorlatilag kizárható, vagyis teljesen elhanyagolható az esélye, hogy hibát tartalmazzon, ráadásul, ahány emberrel több nézi meg ezt a kódot, annál inkább csökken az amúgy is csak leginkább elméletben létező esély a hibára. De ez az esély, legyen bármennyire is kicsi, soha nem lehet nulla. És ahogy nőnek a sorok számai, úgy növekszik az esély. Hogy ez az esély pontosan mikor, kb. hány soros nagyságrendnél éri el azt a szintet, amikortól már komolyan számolni kell a lehetőséggel, azt nem tudom (szerintem erre nem is lehetne egzakt értéket megadni) és amúgy is sok mindentől függ (kik, hányan, hányszor nézték át a kódot, meg ilyesmik). Tehát én fordítva látom, szerintem a hiba esélye nem lehet nulla, hanem az elhanyagolhatóan kicsitől indulva folyamatosan növekszik.
De ezt mások is így látják, méghozzá a a legkritikusabb területen:
http://www.cotsjournalonline.com/articles/view/100490
http://en.wikipedia.org/wiki/DO-178B
http://dissertations.ub.rug.nl/FILES/faculties/science/2008/e.kesseler/c4.pdf
Ebből is láthatod, hogy ők is csak valószínűséggel dolgoznak, mert azt nem lehet kijelenteni, hogy biztosan nem lesz olyan szintű (szoftver)hiba, ami katasztrofális következményeket okozhat. A DO-187B minősítés esetén pl. repült óránként kisebb, mint 10 a mínusz 9. az esélye ennek.
Én is szimpibbnek találom a mikrokerneles megközelítést (pláne, ha még real time is, mint mondjuk a QNX, amit nagyon sajnálok, hogy bekebelezett a BlackBerry, pedig milyen jó lett volna, ha szépen átmegy open source-ba) de hát ez van...
Jah, mondanak. Anno réges-régen az 1-es verziójú Singularity-t le is szedtem, hogy kipróbáljam. Azóta sem került rá sor...
Gyakorlatilag semmi tapasztalatom nincs programozásban. De ha megnézed, a Singularity-t is assembly-ben, meg C-ben írták jórészt és sem abból, sem a Midoriból nem lett eddig semmi. Szóval szép és jó ez a menedzselt nyelvben megírt oprendszer teória, csak eddig még nem nagyon sikerült senkinek. Mert ugye egy menedzselt nyelven megírt akármihez (jelenleg?) kell egy (natív kódú) futtatókörnyezet is. Emiatt meg lassabb (és "korlátozottabb") a natív(abb) nyelveken írt kódnál. De a Microsoft próbálkozik tovább, hát meglátjuk...
http://www.i-programmer.info/news/98-languages/6786-microsofts-new-language-m.html
Most látom, hogy van ilyen is:
http://en.wikipedia.org/wiki/Phantom_OS
Ez orosz.
Aranyos.
Remélem, sikerül elterjednie. De a kernel ennél sem menedzselt kódban íródott, ha jól látom.
Sziasztok! Elég magas szintű topik ehhez a kérdéshez, de remélem nem gond.
A következő felhasználói szintű, vagy az alatti problémám lenne:
A Firefoxban szeretném menteni a felhasznált jelszavakat. Annak rendje és módja szerint az Eszközök->Beállítások->Biztonság->Webhelyjelszavak mentése kvartetten végigcaplatva meg is jelölöm, hogy én bizony menteni szeretném őket. Csakhogy! Bárhová jelentkezek is be (de egy próbát még csinálok a HTKA-val ahogy ezt elküldtem), a Mentett jelszavak gombot inzultálva csak egy maláj géphez mérhető fehérségű felület jön be a megszokott opciókkal (Jelszókezelőként bemutatkozva).
De mentett adat nincs, illetve nem jelenik meg. A régi szép időkben nem nem így volt.
Tipp?
Köszönöm a segítséget.
A következő felhasználói szintű, vagy az alatti problémám lenne:
A Firefoxban szeretném menteni a felhasznált jelszavakat. Annak rendje és módja szerint az Eszközök->Beállítások->Biztonság->Webhelyjelszavak mentése kvartetten végigcaplatva meg is jelölöm, hogy én bizony menteni szeretném őket. Csakhogy! Bárhová jelentkezek is be (de egy próbát még csinálok a HTKA-val ahogy ezt elküldtem), a Mentett jelszavak gombot inzultálva csak egy maláj géphez mérhető fehérségű felület jön be a megszokott opciókkal (Jelszókezelőként bemutatkozva).
De mentett adat nincs, illetve nem jelenik meg. A régi szép időkben nem nem így volt.
Tipp?
Köszönöm a segítséget.