![\"Kis](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>Optim\u00e1lnym rie\u0161en\u00edm by bolo prenesenie iba t\u00fdch najd\u00f4le\u017eitej\u0161\u00edch opr\u00e1v a zranite\u013enost\u00ed, ale problematika spo\u010d\u00edva v identifikovan\u00ed tak\u00fdchto ch\u00fdb z celkov\u00e9ho toku. Najv\u00e4\u010d\u0161\u00ed po\u010det vznikaj\u00facich probl\u00e9mov je d\u00f4sledkom pou\u017e\u00edvania jazyka C, ktor\u00fd si vy\u017eaduje vysok\u00fa presnos\u0165 pri pr\u00e1ci s pam\u00e4\u0165ou a ukazovate\u013emi. Situ\u00e1ciu zhor\u0161uje to, \u017ee mnoh\u00e9 potenci\u00e1lne opravy zranite\u013enost\u00ed nie s\u00fa vybaven\u00e9 identifik\u00e1tormi CVE alebo dostan\u00fa tak\u00fdto identifik\u00e1tor a\u017e po ur\u010ditom \u010dase od publikovania opravy. V tak\u00fdch podmienkach je pre v\u00fdrobcov ve\u013emi \u0165a\u017ek\u00e9 oddeli\u0165 ved\u013eaj\u0161ie opravy od d\u00f4le\u017eit\u00fdch probl\u00e9mov, ktor\u00e9 maj\u00fa dopad na bezpe\u010dnos\u0165. \u0160tatistiky ukazuj\u00fa, \u017ee viac ako 40 % zranite\u013enost\u00ed je odstr\u00e1nen\u00fdch e\u0161te pred pridelen\u00edm CVE a priemern\u00e9 oneskorenie medzi vydan\u00edm opravy a pridelen\u00edm CVE je tri mesiace (t.j. na za\u010diatku je oprava ch\u00e1pan\u00e1 ako be\u017en\u00e1 chyba, ale a\u017e o nieko\u013eko mesiacov sa uk\u00e1\u017ee, \u017ee i\u0161lo o odstr\u00e1nenie zranite\u013enosti).<\/p>\nNakoniec, bez samostatnej vetvy na opravy zranite\u013enost\u00ed a bez z\u00edskavania inform\u00e1ci\u00ed o s\u00favislosti s bezpe\u010dnos\u0165ou danej probl\u00e9my, v\u00fdrobcom produktov zalo\u017een\u00fdch na jadre Linux zost\u00e1va nepretr\u017eite pren\u00e1\u0161a\u0165 v\u0161etky opravy z nov\u00fdch stabiln\u00fdch vetiev. Ale t\u00e1to pr\u00e1ca si vy\u017eaduje ve\u013ea pracovn\u00e9ho \u010dasu a v spolo\u010dnostiach sa stret\u00e1va s odporom z obavy z mo\u017en\u00e9ho v\u00fdskytu regres\u00edvnych zmien, ktor\u00e9 by mohli naru\u0161i\u0165 norm\u00e1lnu funkcionalitu produktu.<\/p>\n
Pripom\u00edname, \u017ee pod\u013ea n\u00e1zoru Linusa Torvalda s\u00fa v\u0161etky chyby d\u00f4le\u017eit\u00e9 a zranite\u013enosti by sa nemali oddeli\u0165 od in\u00fdch druhov ch\u00fdb a vy\u010dleni\u0165 do samostatnej, prioritnej kateg\u00f3rie. Toto stanovisko je od\u00f4vodnen\u00e9 t\u00fdm, \u017ee pre be\u017en\u00e9ho v\u00fdvoj\u00e1ra, ktor\u00fd sa \u0161pecializuje na ot\u00e1zky bezpe\u010dnosti, nie je zrejm\u00e1 s\u00favislos\u0165 opravy s potenci\u00e1lnou zranite\u013enos\u0165ou (pre mnoh\u00e9 opravy len vykonanie samostatn\u00e9ho auditu umo\u017e\u0148uje pochopi\u0165, \u017ee sa t\u00fdkaj\u00fa bezpe\u010dnosti). Pod\u013ea Linusa by ot\u00e1zkami vy\u010dle\u0148ovania potenci\u00e1lnych zranite\u013enost\u00ed z celkov\u00e9ho toku opr\u00e1v mali by\u0165 poveren\u00ed odborn\u00edci na bezpe\u010dnos\u0165 z t\u00edmov zodpovedn\u00fdch za podporu bal\u00edkov s jadrom v distrib\u00faci\u00e1ch Linux.<\/p>\n
Kees Cook pova\u017euje za jedin\u00e9 rie\u0161enie na zabezpe\u010denie jadra pri rozumn\u00fdch dlhodob\u00fdch n\u00e1kladoch previes\u0165 in\u017einierov, ktor\u00ed sa zaoberaj\u00fa portovan\u00edm opr\u00e1v do lok\u00e1lnych zostaven\u00ed jadra, na spolo\u010dn\u00fa koordinovan\u00fa pr\u00e1cu na \u00fadr\u017ebe opr\u00e1v a zranite\u013enost\u00ed v hlavnom jadre (upstream). V s\u00fa\u010dasnej podobe mnoho v\u00fdrobcov pou\u017e\u00edva vo svojich produktoch nie najnov\u0161ie verzie jadra a sp\u00e4tne portuj\u00fa opravy vlastn\u00fdmi silami, \u010do znamen\u00e1, \u017ee in\u017einieri v r\u00f4znych spolo\u010dnostiach duplicuj\u00fa pr\u00e1cu navz\u00e1jom, rie\u0161iac t\u00fa ist\u00fa probl\u00e9m.<\/p>\n
Napr\u00edklad, ak 10 spolo\u010dnost\u00ed, z ktor\u00fdch ka\u017ed\u00e1 m\u00e1 jedn\u00e9ho in\u017einiera zaoberaj\u00faceho sa sp\u00e4tne portovan\u00edm t\u00fdch ist\u00fdch opr\u00e1v, presmeruje t\u00fdchto in\u017einierov na opravu ch\u00fdb v upstream, mohli by namiesto portovania jednej opravy opravi\u0165 10 r\u00f4znych ch\u00fdb pre spolo\u010dn\u00e9 dobro alebo sa zapoji\u0165 do recenzovania navrhovan\u00fdch zmien a zabr\u00e1ni\u0165 zahrnutiu chybn\u00e9ho k\u00f3du do jadra. Zdroje by sa tie\u017e mohli nasmerova\u0165 na vytv\u00e1ranie nov\u00fdch n\u00e1strojov na testovanie a anal\u00fdzu k\u00f3du, ktor\u00e9 by umo\u017enili automaticky identifikova\u0165 typick\u00e9 triedy ch\u00fdb, ktor\u00e9 sa znova a znova objavuj\u00fa u\u017e v po\u010diato\u010dn\u00fdch f\u00e1zach.<\/p>\n
Kees Cook tie\u017e navrhuje akt\u00edvnej\u0161ie vyu\u017e\u00edva\u0165 automatizovan\u00e9 a fuzzing testovanie priamo po\u010das procesu v\u00fdvoja jadra, aplikova\u0165 syst\u00e9my kontinu\u00e1lnej integr\u00e1cie a vzda\u0165 sa archaick\u00e9ho riadenia v\u00fdvoja cez email. V s\u00fa\u010dasnosti efekt\u00edvnemu testovaniu br\u00e1ni to, \u017ee hlavn\u00e9 procesy testovania s\u00fa oddelen\u00e9 od v\u00fdvoja a prebiehaj\u00fa a\u017e po vytvoren\u00ed vydan\u00ed. Kees tie\u017e odporu\u010dil na zn\u00ed\u017eenie po\u010dtu ch\u00fdb pou\u017e\u00edva\u0165 pri v\u00fdvoji jazyky, ktor\u00e9 poskytuj\u00fa viac vysok\u00e1 \u00farove\u0148 bezpe\u010dnosti<\/a>, ako je Rust.<\/p>\n