A Fedora megoldása az UEFI Secure Boot mizériára

Az elmúlt hónapokban internet szerte nagy viták alakultak ki az UEFI Secure Boot körül. A Secure Boot egy, az UEFI 2.3.1 specifikáció 27. fejezetében leírt érvényesítési/ellenőrzési folyamat, amely erősen a PKI-re épít. Célja, hogy megvédje a számítógépet az olyan támadásoktól, amelyek még azelőtt bekövetkeznének, hogy az operációs rendszer elindult volna.
Hamarosan megjelenik a Windows 8 és az eddigi ismeretek szerint a Microsoft megköveteli majd az OEM-ektől, hogy a Windows 8 logóval ellátott hardvereken be legyen kapcsolva a Secure Boot funkció. Ha az be van kapcsolva, az UEFI csak ellenőrzött, digitálisan aláírt OS loadert indít el, szemben a mostani BIOS-okkal, amelyek bármilyen OS loader-t - akár malware-t is - elindítanak.

Jelenlegi helyzet a BIOS-szal

UEFI Secure boot

A Red Hat alkalmazásában álló Matthew Garrett több alkalommal is írt már az UEFI Secure Boot-ról és arról, hogy annak alkalmazása milyen megoldandó problémákat okoz pl. a Linux disztribútorok számára:

A Microsoft is kifejtette saját álláspontját a témában korábban:

Garrett szerint az év vége felé a megvásárolható új gépek nagy része Windows 8 certified lesz, és ha azokon a Windows 8 előtelepítve lesz, akkor be lesz rajtuk kapcsolva a Secure Boot. Elvileg ezek a gépek gyári állapotukban, bekapcsolt "Secure Boot" ellenőrzés mellett csak a Microsoft által aláírt OS loader-t indítanák el, így más operációs rendszer - Linux, *BSD stb. - futtatása felhasználói beavatkozás, előzetes konfiguráció nélkül lehetetlen lenne rajtuk.

UEFI Secure Boot #3

Ugyan a Microsoft szerint a "Secure Boot" opció minden x86 gépen kikapcsolható lesz, Garrett-ék szerint nem minden Fedora felhasználó fogja élből tudni, hogy az mi és hogy hol lehet kikapcsolni.

Éppen ezért a Fedora arra jutott, hogy nem elég a felhasználókra bízni a "Secure Boot"-tal kapcsolatos döntést. Megvizsgálva a lehetőségeket, arra jutottak, hogy nem jó megoldás az, ha készítenek egy Fedora kulcsot és ráveszik a hardvergyártókat arra, hogy azt is építsék be a hardvereikbe. Az sem tűnt életképes megoldásnak, hogy létrehoznak egy globális Linux kulcsot és azt építtetik be a gyártókkal. Ezek az opciók bonyolultak és/vagy költségesek lettek volna.

Ehelyett a Fedora arra jutott, hogy létrehoz egy saját, egyszerű, ritkán változó, első lépésben elinduló bootloader-t - a neve "shim" - és azt aláíratják a Microsoft-tal. Ez a loader nem csinál majd mást, mint elindítja a GRUB2-t, amelyet át kell dolgozni annak érdekében, hogy a biztonságos boot folyamat fenntartható legyen (runtime modulbetöltés lehetőségének letiltása). A Fedora 18 a jelenlegi tervek szerint már ily módon támogat(hat)ná a Secure Boot-ot.

Természetesen nem csak a boot loader problémát kell megoldania a Fedora fejlesztőknek, ha a Secure Boot-ot támogatni kívánják. Hátra van még pl. a kernelmodulok aláírásának kérdése, kiváltképp az, hogy a Linux kernelfán kívül karbantartott driverekkel mi lesz.

Garrett itt írja le a Fedora Secure Boot támogatási elképzelését, ami - mint az olvasható - nincs kőbe vésve és könnyen változhat még a jövőben.

Hozzászólások

Nem igazán értem, miért kell egy új betöltő programot írni és azt aláíratatni a microsoft-tal. A grub-al nem lehet ezt megcsinálni?

Az a gond, hogy minden alkalommal amikor kijön egy új verzió akkor alá kellene íratni. Nem az a lényeg, hogy az MS írja alá, hanem hogy egy rendes tanúsítvánnyal legyen aláírva, amit a gyártók a "BIOS" firmware-jébe fel is töltenek. Egy ilyen aláírás pedig, bizony pénzbe kerül. Te magad is le tudod fordítani odahaza a forráskód alapján a Grub-ot, aláírni már nem tudod, így használni sem, hiszen a betöltési folyamat elhasal az ellenőrzésnél. Ez egy lépés lenne az OpenSource halála felé. Ez a gond, szerintem.

A Microsoft most örül, hogy van mire fognia az opensource cs*szegetését...

Vajon nem lenne-e egyszerűbb egy biztonsági okokból sikertelen boot esetén kiírni a felhasználónak a képernyőre egy üzenetet, hogy "ha szándékosan akarsz aláíratlan programot indítani, akkor az xy gomb lenyomása után a z menüben a zs opciót leszel szíves átbillenteni a értékből b értékbe?" Csak kérdezem... Mert szerintem az opensource világban minden programot, kernelmodult, és ezeknek minden verzióját úgysem lesz senkinek türelme aláirkálni. Viszont ha bármelyik szinten van egy nem aláírt szoftver, akkor meg már úgyis mindegy...

Hasonlo jutott eszembe nekem is, tul azon, hogy az alairast az ms valoszinuleg penzert fogja megtenni, illetve ha vki egy sajat loadert akar fejleszteni gonoszkodasbol, akkor ezt fogja hasznalni.
Masreszrol, nagysagrendileg mennyo boot loader cseres gep van? Megeri foglalkozni veluk, hogy a legelterjedtebb oprendszer csak ugy, es csak akkor hajlando bootolni?

De mi lesz az egész lényegével, a biztonsággal, ha az MS aláírja a loadert, ami akármilyen hackelt grubot betölt?

Nem pont az lenne a cél, hogy amit aláírnak, annál felelősséget vállalnak arra, hogy az nem tölt be semmilyen rosszindulatú kódot?

http://xkcd.com/364/

A Microsoftnak sikerült egy világméretű problémát megoldania, ami már-már összeroppantotta az informatikát, hisz mindenki tudja, hogy több milliárd gépet támadnak manapság a BIOS-on keresztül. Épp ideje megmenteni a világot.

Valamelyest kapcsolódik:

Try to buy systems that don't rely on UEFI. In the next few years,
prepare to buy systems and find out they require UEFI, and then demand
a refund. Prepare for it to get even worse than that.

If you buy a UEFI-capable system today, you are giving power to the
people who will (in the future) make UEFI-only systems which are
incapable of running OpenBSD.

UEFI arrived with all sorts of promises of making machines better, but
is being turned into something completely nefarious.

-- Theo de Raadt

--
trey @ gépház

Én azon gondolkodom, hogy nem állna-e meg a Microsoft ellen egy antitröszt kereset.

1. A Microsoft felhasználva piaci, marketing és egyéb túlsúlyát nem kényszeríti-e rá a gyártókat arra, hogy "Windows 8 Ready" gépeket, eszközöket gyártsanak a versenyben maradásuk érdekében?

2. Ugyan a definíció szerint az UEFI SETUP-jában kikapcsolható a Secure BOOT, de vajon kötelező-e beépíteni a kikapcsolhatóságot, vagy esetleg a "költséghatékonyság érdekében" kihagyható lesz belőle? Mert ez esetben a Microsoft tenni fog róla, hogy olcsóbb legyen az ilyen gép, vagy alkatrész.

3. Mi garantálja, hogy nem fog-e a jövőben a Microsoft nyomására eltűnni az UEFI-ből a kikapcsolhatóság?

4. Csak az x86 alapú rendszereknél emlegetik, hogy kikapcsolható a védelem, márpedig az ARM egyre nagyobb piaci szereplő lesz. Tudom egyelőre a Microsoft itt még nem mondható túl fajsúlyos szereplőnek, de jobb félni tőle, mint megijedni.

5. Ki dönti el, hogy mi lesz aláírt és mi nem? Vajon bízhat a piac többi szereplője a pártatlan elbírálásban?

6. A Windows 8 el fog-e indulni kikapcsolt védelemnél esetleg más bootmanagerből? (Úgy tudom, hogy nem.)

7. Ha a felhasználó kénytelen kikapcsolni ezt a funkciót, akkor ezzel nem sugallja-e azt ez a megfogalmazás, hogy ettől a pillanattól nem biztonságos a számítógépe, hovatovább operációs rendszere?

Na elsőre ezek merültek fel bennem.

Wikipédiáztam kicsit, ennek alapján:
1: de, szerintem nagyon is. Sőt: "OS loaders are a class of UEFI applications. As such, they are stored as files on a file system that can be accessed by the firmware. Supported file systems include FAT32, FAT16 and FAT12." Ezekért tudomásom szerint az ms pénzt kér...
2/4: x86-on kötelező, arm-en tilos (!) (viszont kérdéses, hogy az arm-es windowsnak kell-e uefi)
5: a fent linkelt cikk szerint pl a verisign
6: nem fog, de ez szerintem elég nehezen megvalósítható. BIOS-szal nyilván elindul. Secure boot-os UEFI-vel szintén. De mi a helyzet a korai UEFI-s gépekkel, ahol ez még nem volt szempont?
7: Ha egy felhasználó belép a setup-ba babrálni, akkor már valószínűleg ért valamennyire hozzá. Ez az átlaguser nem tudja kikapcsolni, hogy linugzot rakjon rá szerintem nem akkora probléma. Sokkal nagyobb probléma, hogy valószínűleg lehetetlen lesz a dualboot.

"hogy valószínűleg lehetetlen lesz a dualboot"

Ez benem is felmerult. Nehany kerdes mellett.

1. Ha a fent emlitett trusted Fedora bootloader ra hiv , Windows 8 trustot kovetelo bootloaderere akkor az meni fog -e ? Es a Windows 9 -el ?
2. Egy nem trusted bootloader be tud -e bootloni egy Windows 8 -at ? Es a Windows 9 -et ?
3. Egy trusted bootloader, kerheti -e az UEFI -t egy masik bootloader betoltesere ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A fent hivatkozott cikkből:
"Microsoft will be offering signing services through their sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access edit: The $99 goes to Verisign, not Microsoft - further edit: once paid you can sign as many binaries as you want), but it's cheaper than any realistic alternative would have been."

Szerintem pedig érdemes példát venni a Fedora team-ről. Ahelyett, hogy a Microsoftot cseszegetnék, inkább megoldást kerestek egy valós problémára. Valószínűleg belátták, hogy egyrészt egy per (még ha a kimenetele számukra kedvező is), sok időt és pénzt emészt fel, annyit meg nem ér az egész. Másrészt a secure bootot nem tartják feleslegesnek, ez látszik abból, hogy alapvetően olyan megoldást kerestek, amivel nem kell kikapcsolni a secure bootot.

Páran már kifejtették, hogy szerintük a secure boot felesleges, mert ma a támadók nem használják ki, hogy a bios bármilyen boot loadert hajlandó betölteni. Csakhogy a Microsoftnak nem 1-2, hanem 10 éves távlatokban kell terveznie, és ezalatt változhat a helyzet. A támadók mindig a legegyszerűbb utat keresik, ha pedig a jövőben megnehezítik a dolgukat a jelenlegi támadási eljárásokkal, újakat fognak keresni, és ha a boot folyamat sebezhető, akkor azt is számításba fogják venni. Utólag pedig ilyen technológiákat sokkal nehezebb lefejleszteni, mint előre, amikor még a megelőzésen van a hangsúly.

Sajnos az a helyzet, hogy technológiailag mindenképpen kiszolgáltatott marad a közösség. A cikkben is szerepel, hogy nem lesz elég az aláírt bootmanager betöltő, annak is aláírtnak kell lennie, meg a kernelnek, meg a moduloknak, meg mindennek. (Lásd: "Természetesen nem csak a boot loader problémát kell megoldania a Fedora fejlesztőknek, ha a Secure Boot-ot támogatni kívánják. Hátra van még pl. a kernelmodulok aláírásának kérdése, kiváltképp az, hogy a Linux kernelfán kívül karbantartott driverekkel mi lesz. ")
Lehet, hogy egy SLED, Red Hat Linux, Oracle vagy akár még egy Ubuntu esetében nem lesz gond, mert meg tudják venni az aláírást, de mi lesz mondjuk egy Debian-nal, Slackware-rel, vagy egy Linux from Scratch-el?
Hogyan tud egy kezdő operációs rendszert tanulmányozni és írni? Vagy ez csak néhány kiválasztott privilégiuma lesz majd? Vajon ki választja majd ki a kiválasztottakat? Vajon Linus hogyan készítette volna el a Linuxot, ha a 386-osa csak aláírt rendszert tudott volna futtatni?
Mi lesz akkor, ha valaki akar egy önálló modult írni? Hogyan fordítasz magadnak Kernelt? Hogyan patch-eled meg? A GCC hogyan írja alá a modulokat?

Szóval szerintem nem elegendő pusztán technikai jellegű tűzoltásba kezdeni, mindenképpen figyelni és figyelmeztetni kellene és szükség esetén lépni. De nem csak a Microsoft esetében. Nagyon félek attól, hogy itt súlyos háttéralkuk vannak a kereskedelmi Linux disztribútorok, a Google, a Microsoft a nagy harware gyártók között annak érdekében, hogy megakadályozzák új piaci szereplők létrejöttét.

Mulatságos látni ahogy egy egy szál belelovalódik egy egy véletlen ötletbe. Egyelőre ott tartunk, hogy a BIOS kiírja hogy: nem jó az OS-ed tanúsítványa, ha folytatod nyomj entert. Nincs senki megakadályozva saját program futtatásában. A vállalati rendszereket szállítóknak meg lesz saját tanúsítványuk, már ha amiatt aggódnánk hogy az ms így versenyelőnyre tesz szert.

Természetesen a linux elterjedésének nem tesz jót ha a windows biztonságosabb lesz mint saját elődje, a linux meg egy helyben toporog, de ez mindenképpen a Ms érdeme, és ha a sulis vagy kisboltos szerveren windows szerver lesz debian helyett mert biztonságosabb, az _jobb_ lesz, mint a jelenlegi helyzet. Szerintem ez csak egy jól meglátott piaci rés, és valóban, ha egy vállalat teljesen egyedül birtokolja egy biztonsági lánc egyik elemét, az versenyelőny, ám még mindig jobb, mintha nem lenne ott semmi. ( mármint windows fronton jobb, a desktop linux oldalt ez jellegénél fogva nem érinti, ott ez úgyis kivitelezhetetlen )

Hát ez szerintem sem a Linux, sem a Windows rendszereken nem a legkihasználtabb biztonsági lyuk. Ez szerintem tipikusan olyan dolog, hogy a bűnözők röhögve ki fogják játszani, a többieknek meg csak nyűg. Az a rendszergazda meg aki akár Debian, akár Win szerverre ilyet beenged, annak úgy kell. Az UEFI meg nem fogja felajánlani az folytatás lehetőségét, hanem bekapcsolt secure boot mellett egyszerűen nem tölti be az aláíratlan binárist.
Amit meg piaci résként értelmezel az olyan, mintha a csúcshiperszuper XY a legnagyobb mosószergyártó előállítana egy mosóport, ami mondjuk jól mos, de csak olyan mosógépeken működik, melyek ezen bizonyos cég által szabadalmaztatott fémötvözetből készülnek. Ennek a fémötvözetnek viszont az lenne tulajdonsága, hogy azonnal korrodálódna, ha másik mosóport használnak vele. A mosógépgyártóknak, akik az ő technológiáját használnák megengedné, hogy úgy reklámozzák a gépet, hogy ez egy csúcshiperszuper XY erejével mosó mosógép. Ezek után a reklámokban azt látnák az emberek, hogy a csúcshiperszuper XY tudja csak kimosni a ruhákat, az összes többi pedig még a színeket is kilúgozza a ruhákból mert egyedül ez a mosópor tartalmaz neoprimitív molekulákat.
Ezek után a mosógépgyártók nem akarnának lemaradni a versenyben (ugyebár a legnagyobb mosószergyártó terméke) és elárasztanák a piacot az ilyen mosógépekkel. A beetetett emberek ezeket a gépeket keresnék. A koppanás akkor jön, amikor kiderül, hogy ez a mosópor bár jó, de rettenetesen drága és a vele mosott ruhák enyhe allergiás reakciókat váltanak ki sok embernél. Ráadásul egyeseknek az illata sem tetszene és csak a mosóporgyártó által szabadalmaztatott technológiával készült adalékanyaggal lehetne azt megváltoztatni, különben tönkremennek a fűtőszálak a mosógépben.

Érzek egy enyhe félreértést néhány hozzászólásban. Az előnye az lenne értelmezésem szerint a TC-nek, hogy a legelső boot folyamattól kezdve lenne végig védve a működési folyamat azzal, hogy az előző lépésben ellenőrizve lenne a bináris a következő lépéshez, és így tovább. Tehát minden bináris ellenőrizve lenne a betöltődése és futtatása előtt, nem pedig kizárólag egy boot vírus ellen készült, annál több.

Szerintem ez nagyon jó dolog lehetne, ha nem basszák el és nem kerülnek ki privát kulcsok, meg nem próbálják kisajátítani vele a piacot.

Ami még homályos, hogy egy működő rendszer esetében ez mennyire jelenthetne biztonságosabb rendszert? Mert a betöltési folyamat ok, ott egyértelmű. De ha böngészőn keresztül egy sebezhetőséget kihasználva elindítanak egy idegen kódot a már futó rendszeren, esetleg az még privilégium szint ugrást is végre tud hajtani, akkor attól kezdve már gond van. Tehát értelmezésem szerint a TC arra jó, hogy biztos lehetsz benne, hogy reboot után tiszta rendszer indul el - többre nem. Jól értem?

Hmmm... Én most csak az UEFI Secure Boot-ra reflektálok. Amennyire én tudom ez csak a boot folyamatért és a kernelszintű dolgokért felel, a userspace dolgokért nem.
A Trusted Computing? Igen mindenképpen van létjogosultsága, ahogyan minden biztonságot jelentő dolognak, de ez nem szabad, hogy elvezessen oda, hogy lehetetlenné tesszük mások szereplését akár technológiai akár piaci szempontból. Egyébként itt is meg kellene határozni szinteket, mert lehet, hogy ami megbízhatóvá tesz egy céges rendszert az használhatatlanul megkötötté tenne egy személyes használatú gépet, ugyanakkor elégtelen lenne egy katonai rendszerben.

Egyébként inkább morális kérdéseket próbálok feszegetni.

,,Az UEFI meg nem fogja felajánlani az folytatás lehetőségét, hanem bekapcsolt secure boot mellett egyszerűen nem tölti be az aláíratlan binárist."

Szerintem fogadhatunk. Az alaplapgyártók és BIOS írók nem hülyék. Állítom, hogy a desktop linuxot desktop linux léténél fogva nem fogja érinteni, mindenki másnak - desktop windows, szerver és magasabb szintű rendszerek - meg jobb lesz.

Szerintem én az a feléhasználó leszek, aki inkább kikapcsolja ezt a marhaságot, minthogy 20-szorosan láncolt botloadert használjak, de azt nem értem, hogy ez miben lesz jobb, majd betölti a malvaret, a feltört, és alárt kúlccsal rendelkező os. Szerintem ez a világ legritkább támadási módja. Még életemben nem hallottam (ill hallotamm, de még látni nem láttam) ilyen jellegű támadást bármi ellen. Azon felül, ha ez nem lesz kikapcsolható, akkor az ugyancsak korlátoz a személyes szabadságomban, hisz kizárt pl hogy linuxot, vagy bsd-t.... használhassak.... Szóval ez ugyancsak támadható dolog.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

De ez nem csak a boot lenne, hanem a komplett pc-ben minden titkosítva menne. Ez tényleg nem szólna másról, mint a monopólium megőrzésről. Ha ez bejön én elkezdem felvásásrolni a régi gépeket, és aból építek inkább pc-t, a még normális vasakból. Maximum elektronmikroszkóppal kel majd hardvert törni. Remélem ez az idő soha nem következik be.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Jó én is részben iróniának szántam, de szerintem nem lenne lehetetlen. Megveszel 50-100 hardvert. abból felépíthető a belső kapcsolást, (szoktak így kémkedni, hogy elektronmikroszkóppal megnézik a felépítést), abból pl kiszedhető, hogy hol található beépített memória, már csak egy olvasó áramkör kell..... A kulcsokat ellopni, pedig még egyszerűbb. Biztosan van egy két alulfizetett ember.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Lehet én értelmezek valamit rosszul, de nekem az jön le, hogy a legelső binárisnak kell aláírva lennie. Az meg attól kezdve azt csinál amit akar.

Tehát ha a nagy Linux diszribútorok leimplmenetálnák a saját aláíró rendszerüket minden kernel, kernel modul és egyéb binárishoz (akár a szállított userspace bin-ekhez is) és létrehoznák rá az infrastruktúrát, akkor igazából jó is lehetne a dolog.

Mivel akkor elég lenne azt a nyamvadt grub-ot aláíratni több platformon, és szállíthatná azt a többi disztribútor is. Az meg tartalmazná a disztribútor kulcsát, ezzel ellenőrizne egy elő töltött binárist, amely ezzel a kulccsal tovább ellenőrizhetné a betöltés előtt a kernel bin-t meg a többit.

A disztribútor (pl. RedHat Fedora supporter-ként) meg aláírná más disztribútorok kulcsát. Ezt sem kellene minden új verziónál eljátszani, ezért kivitelezhetőnek tűnik.

Nincs benne a cikkben, de nekem valami olyasmi is rémlik, hogy gpl (vagy gplv3) licencű programoknál nem csak a forrás, de az aláíráshoz használt privát kulcs átadása is kötelező, ami eleve hülyeség mert akkor minek aláírni. Mindenesetre ez eléggé kivitelezhetetlen, ha egy 3. személy a saját privát kulcsával ír alá, amit érthető okokból nem ad ki.

Fu bazze , ez nem semmi :)
http://en.wikipedia.org/wiki/Tivoization -gyanus eset ?

Akkor irni kell, egy other boot loadert nem GPLv3+ alatt, ami betolt egy bonyolultabb boot loadert pl. a grub2 -t:)

Amig ki lehet kapcsolni a secure bootot ,addig nem Tivoization.
Amig senki nem ad tovabb alairt grub2 -vel elattot rendszert amin nem lehet kikapcsolni secure bootot addig senki sem szegi meg.

Az egesz egy vicc.

99$ dollarert barki alairhat boot loadert, aztan az a boot loader betolti a virust es a windozert es az egesznek semmi ertelme.
Aki meg alairatta majd annyit mond: "sorry".
Vajon mennyiert irat ala egy hajlektalan egy boot loadert ?

Majd mindig BIOSt/UEFI kellene frissitenem, hogy tudhasson a gep a viszavont alairasokrol?

Mi, lenne ha a user egyszeruen beallithatna milyen alairasokban bizok meg ? Bios menuben explicit import keres a halon jelen levo DHCP option alapjan, vagy betoltes USB mass-sotrage-rol, vagy begepeles, vagy hagyomanyos/USB soros eszkozrol ...

Ha valoban, secure bootot akarnek, csak az altalam hitelesitett binarist fogadhatna el a gep, semmi MS vagy CIA vagy jotment 99$ -os csoves kodjat.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

na, ez megint szar megoldas egy nem letezo problemara. ameddig uj firefoxot kell kiadni, ha kajmanisztanban valaki meghekkel egy CA-t, addig baromira ne jojjon nekem senki tanusitvannyal vedett boottal.

Nem qurvára mindegy, hogy a boot folyamat melyik szakaszában töltöm be a vírust??????? Ez nem jó másra csak az 1.0-s userek ellehetetlenítésérére, hogy azon túl amit kapnak ne tudjanak mást használni...

-------------------------------------------------------------------------------------------
Mit használok? Na, na, na? Hát blackPanther OS v11.1-et * www.blackpanther.hu

Tfh adott egy termeked, teszem azt egy appliance. Felteszem garantalni akarod a box serthetetlenseget, mert a szolgaltatast veszik toled es a boxra csak ugy jar garancia, ha Gizike nem nyul bele. Ezekre mar most is van megoldas, bar ezek kicsit hack jelleguek, es pont az ilyen hack jellegu megoldasok helyett lenne egy egyseges megoldas == TC.
Vegfelhasznalo szempontbol lehet fujogni, de mint gyarto es mint szolgaltato szukdeg van ra, hogy garantalni tudd azt, amit elvarnak toled, ugy ha belepiszkalnak, akkor tudd azt mondani, hogy nem a termekben van a hiba, hanem abban, amit mas elganyolt benne.
___
info | Tresorium

aztan majd a shimmel toltik a rootkiteket a haxorok? kemeny 100 usd-t azert ossze tudnanak guberalni

--
NetBSD - Simplicity is prerequisite for reliability