Názory k článku
Oprava dlouholetého bezpečnostního problému v jádře 2.6.27
-
A proč si proboha nepřečtete tu původní zprávu:
A web browser has two windows or tabs open, both loading a new page (maybe triggered through Javascript). One connection is to your bank, the other some random Internet site. The latter contains some random object which must be handled by a plug-in. The plug-in could be an external program processing some scripting language. The external program will be started through a fork() and exec sequence, inheriting all the file descriptors open and not marked with close-on-exec from the web browser process.
(poslední věta je ta důležitá) -
Ách jo. Já tu zprávu celou četl už v sobotu. Pravda, mohl bych tam Ullrichovi napsat, že Flash je blbej příklad, ale on by mě smetl tím, že když nepoužívám 64-bit Firefox a nspluginwrapper, jsem idiot a žiju v jiné době. Vy ale doufám chápete, že ještě dnes dost lidí běhá Flash plugin tak, jak Adobe zamýšlí, a zprávičku upravíte, abyste nemátl lidi. Nebo jsem i podle vás idiot, co žije v jiné době? -
Podle mě byste měl akorát psát příspěvky tímhle stylem už od začátku a vyhnuli bychom se této debatě.
Nicméně ta zprávička je taková typická popularizační rootovina. Správně by to mělo být zmíněno, že opravuje problém, kdy child proces vytvořený forkem již nebude mít přístup k tolika deskriptorům, které byly vytvořeny parent procesem. (A pak už je jedno jestli se jedná o flash nebo nejedná...)
Například (kopírováno z ABCLinuxu):
"Do Linuxu 2.6.27 se dostane sada nových vlastností pro práci se souborovými deskriptory. Jde o řešení bezpečnostního problému, kdy za jistých okolností mohou otevřené deskriptory být použity v podprocesu, ačkoliv to není umožněno záměrně. Mnoho funkcí tak bude mít dodatečný příznak close-on-exec. Více v blogu." -
Tu narážku na psaní příspěvků tímhle stylem od začátku jsem nějak nepochopil. Snažíte se naznačit, že jsem arogantní a že by se se mnou nikdo nebavil, anebo že jsem relevantní informace dodal až teď?
(Každopádně se ale omlouvám za to, že jsem si omylem myslel, že vy jste ten, kdo zprávičku napsal a může ji upravit.) -
BLEK. (neregistrovaný)Hmm, jen nevím, kdo bude všechny knihovny a pluginy, co Mozilla používá, měnit, aby ten nový flag použily.
Možná by bylo bývalo lepší udělat per-thread flag, který říká, že všechny file-descriptory vytvořené threadem mají nastaven close-on-exec. Pak by ho Mozilla mohla nastavit a knihovny a pluginy by vytvářely soubory s close-on-exec automaticky aniž by o tom věděly. -
BLEK. (neregistrovaný)Plugin, vzhledem k tomu, že běží v procesu Mozilly a musí se snášet s ostatními pluginy, nesmí modifikovat první tři file-deskriptory. Pak by celá Mozilla nemohla nic psát na terminál. Navíc pak hrozí, že se různé pluginy o ty deskriptory 0, 1 a 2 poperou.
Co se týče možnosti, že plugin vytvoří filedeskriptor s náhodným číslem, pak udělá fork(), exec() a execnutému procesu chce tento nový file deskriptor předat --- ano, to by tato změna zablokovala, otázka je, proč by plugin nějakému procesu takhle chtěl předávat file deskriptory s náhodným číslem a který program vlastně je schopen akceptovat jiné deskriptory než 0, 1, 2. -
Milan Jurik (neregistrovaný)Proc by to mel byt nejaky nahodny filedescriptor? Neni problem si ho pripadne nejak predat.
Celkove, mnohem rozumnejsi mi prijde, ze si aplikace sama pred execem uklidi senzitivni kanaly na zaklade vlastnich znalosti a ne, ze se nejakym zpusobem globalne vnuti takove chovani. -
milank (neregistrovaný)Zrovna tak by mohl "forknutý" proces na začátku zavřít všechny nepotřebný deskriptory, ještě než zavolá exec() nějakého nebezpečného procesu. Je to jednodušší, než rešit ten race-condition, co popisuje UD, a je to IMHO i jednodušší, než přepsat všechny open() & spol. v celý Mozille.
ČLÁNKY DO MAILU