Кіс Кук (Kees Cook), былы галоўны сістэмны адміністратар kernel.org і лідэр Ubuntu Security Team, які цяпер працуе ў кампаніі Google над забеспячэннем абароны Android і ChromeOS, выказаў асцярогу бягучым працэсам выпраўлення памылак у стабільных галінках ядра. Штотыдзень у стабільныя галінкі ўключаецца каля ста выпраўленняў, а пасля зачынення акна прыёму змен у наступны рэліз набліжаецца да тысячы (суправаджаючыя ўтрымліваюць выпраўленні да зачынення акна, а пасля фармавання «-rc1» публікуюць назапашанае зараз), што занадта шмат і патрабуе вялікіх працавыдаткаў для суправаджэння прадуктаў на базе ядра Linux.
Па меркаванні Кіса працэсу працы з памылкамі ў ядры не надаецца належная ўвага і ядру бракуе прынамсі 100 дадатковых распрацоўнікаў для скаардынаванай працы ў гэтай вобласці. Асноўныя распрацоўнікі ядра рэгулярна выпраўляюць памылкі, але няма ніякіх гарантый, што гэтыя выпраўленні будуць перанесеныя ў варыянты ядра, выкарыстоўваныя іншымі вытворцамі. У карыстачоў розных прадуктаў на базе ядра Linux таксама няма магчымасці пракантраляваць тое, якія памылкі выпраўленыя і якое ядро выкарыстоўваецца ў іх прыладах. У канчатковым рахунку за бяспеку сваіх прадуктаў адказваюць вытворцы, але ва ўмовах вельмі вялікай інтэнсіўнасці публікацыі выпраўленняў у стабільных галінках ядра яны апынуліся пастаўленыя перад выбарам - пераносіць усе выпраўленні, выбарачна партаваць найважнейшае ці ігнараваць усе выпраўленні.
Аптымальным рашэннем быў бы перанос толькі найважнейшых выпраўленняў і ўразлівасцяў, але ў вылучэнні такіх памылак з агульнага струменя і складаецца асноўная праблема. Найбольшая колькасць усплываючых праблем з'яўляецца следствам выкарыстання мовы Сі, які патрабуе вялікай акуратнасці пры працы з памяццю і паказальнікамі. Пагаршае сітуацыю тое, што шматлікія патэнцыйныя выпраўленні ўразлівасцяў не забяспечваюцца ідэнтыфікатарамі CVE або атрымліваюць падобны ідэнтыфікатар праз нейкі час пасля публікацыі выпраўлення. У падобных умовах вытворцам вельмі цяжка падзяліць другарадныя выпраўленні ад важных праблем, якія ўплываюць на бяспеку. Па статыстыцы больш 40% уразлівасцяў ухіляюцца да прысваення CVE і ў сярэднім затрымка паміж выпускам выпраўлення і прысваеннем CVE складае тры месяца (г.зн. спачатку выпраўленне ўспрымаецца як звычайная памылка, але толькі праз некалькі месяцаў становіцца ясна, што мела месца ўхіленне узявальнасці).
У выніку, не маючы асобнай галінкі з выпраўленнямі ўразлівасцяў і не атрымліваючы звестак аб сувязі з бяспекай той ці най праблемы, вытворцам прадуктаў на базе ядра Linux застаецца бесперапынна пераносіць усе выпраўленняў са свежых стабільных галінак. Але дадзеная праца патрабуе вялікіх працавыдаткаў і сутыкаецца ў кампаніях з супрацівам з-за асцярогі ў з'яўленні рэгрэсіўных змен, здольных парушыць звычайную працу прадукта.
Нагадаем, што на думку Лінуса Торвальдса, усе памылкі важныя і ўразлівасці не варта аддзяляць ад іншых відаў памылак і выдзяляць у асобную больш прыярытэтную катэгорыю. Тлумачыцца такое меркаванне тым, што для звычайнага распрацоўніка, не які спецыялізуецца на пытаннях бяспекі, не відавочная сувязь выпраўлення з патэнцыйнай уразлівасцю (для шматлікіх выпраўленняў толькі правядзенне асобнага аўдыту дазваляе зразумець, што яны дакранаюцца бяспекі). Па меркаванні Лінуса, пытаннямі вылучэння з агульнага струменя выпраўленняў патэнцыйных уразлівасцяў павінны займацца адмыслоўцы па бяспецы з каманд, якія адказваюць за падтрымку пакетаў з ядром у дыстрыбутывах Linux.
Кіс Кук лічыць, што адзіным рашэннем для падтрымання бяспекі ядра пры разумных доўгатэрміновых выдатках з'яўляецца пераклад кампаніямі інжынераў, якія займаюцца партаваннем выпраўленняў у лакальныя зборкі ядра, да сумеснай скаардынаванай працы над суправаджэннем выпраўленняў і ўразлівасцяў у асноўным ядры (upstream). У бягучым выглядзе, шматлікія вытворцы выкарыстоўваюць у сваіх прадуктах не найноўшыя версія ядра і бэкпартуюць выпраўленні ўласнымі сіламі, г.зн. атрымліваецца, што інжынеры ў розных кампаніях дублююць працу адзін аднаго, вырашаючы адну і тую ж праблему.
Напрыклад, калі 10 кампаній, у кожнай з якіх адзін інжынер займаецца бэкпараванне адных і тых жа выпраўленняў, пераарыентуюць дадзеных інжынераў на выпраўленне памылак у upstream, то яны замест партавання аднаго выпраўлення маглі б выправіць 10 розных памылак для агульнай карысці або падлучыцца да рэцэнзавання прапанаваных змен. і не дапусціць уключэння кода з памылкамі ў ядро. Рэсурсы таксама можна было б накіраваць на стварэнне новых інструментаў для тэсціравання і аналізу кода, якія дазволілі б на ранняй стадыі аўтаматычна выяўляць тыпавыя класы памылак, якія ўсплываюць зноў і зноў.
Кіс Кук таксама прапануе больш актыўна выкарыстоўваць аўтаматызаванае і fuzzing-тэставанне непасрэдна ў працэсе распрацоўкі ядра, прымяняць сістэмы бесперапыннай інтэграцыі і адмовіцца ад архаічнага кіравання распрацоўкай праз email. Цяпер эфектыўнаму тэсціраванню перашкаджае тое, што асноўныя працэсы тэсціравання аддзелены ад распрацоўкі і адбываюцца ўжо пасля фарміравання рэлізаў. Кіс таксама рэкамендаваў для зніжэння колькасці памылак прымяняць пры распрацоўцы мовы, якія забяспечваюць больш высокі ўзровень бяспекі, такія як Rust.
Крыніца: opennet.ru