Linux 內(nèi)核 “社區(qū)” 對(duì)待安全的優(yōu)先級(jí)并不高,雖然經(jīng)歷了 2000 年代的多次大規(guī)模漏洞利用事件但并沒(méi)有讓 Linus Torvalds 本人改變 "A bug is bug" 的哲學(xué),由于 Linux 內(nèi)核的安全問(wèn)題逐漸影響到了 Android 和 IoT 設(shè)備,一次 華盛頓郵報(bào)的曝光促使了 KSPP(Linux 內(nèi)核自防護(hù)項(xiàng)目)的成立,KSPP 是由 Linux 基金會(huì)旗下的 CII(基礎(chǔ)架構(gòu)聯(lián)盟)管理,其吸納了來(lái)自諸多大廠商(Google, RedHat, Intel, ARM 等)的工程師進(jìn)行聯(lián)合工作,可惜的是兩年的時(shí)間過(guò)去了,KSPP 大多時(shí)候只是在重復(fù)的抄襲 PaX/Grsecurity 的各種特性以獲得各自雇主那里的 KPI 和 credit,各種混亂的代碼合并到了 Linux 主線(xiàn)影響了 PaX/Grsecurity 的正常開(kāi)發(fā),這也是PaX/Grsecurity 關(guān)閉公開(kāi)訪(fǎng)問(wèn) test patch 的主要原因之一。
最近由 Qualys 曝光的 Stack clash 是一個(gè)古老的漏洞利用平面的工程化,這威脅到了幾乎所有類(lèi) UNIX 系統(tǒng)(包括 GNU/Linux)的安全,當(dāng) Linux 內(nèi)核 x86 的 maintainer 之一 Andy Lutomirski 問(wèn)及PaX/Grsecurity 是如何修復(fù)時(shí) Linus 直接回復(fù)了 Grsecurity 是垃圾,有趣的是當(dāng) PaX/Grsecurity 的作者之一 Spender曝光了一些內(nèi)核最近的 silent fix以后Linus 居然 “邀請(qǐng)”P(pán)aX team/Spender 直接貢獻(xiàn)代碼到 Linux 內(nèi)核代碼,這是不大可能發(fā)生的,因?yàn)榻裉焖^的內(nèi)核 “社區(qū)” 主要是由一幫大廠商的雇員組成,沒(méi)有人有義務(wù)免費(fèi)的貢獻(xiàn)代碼去幫助那些需要從雇主那里獲得 KPI 的工程師。
更諷刺的是,stack clash 的部分修復(fù)居然來(lái)自 PaX/Grsecurity 于 2010 年的代碼,Linus 說(shuō) PaX/Grsecurity 是垃圾也等同于打 KSPP 的臉,因?yàn)?KSPP 還在繼續(xù)抄襲 PaX/Grsecurity,而針對(duì)Linux 內(nèi)核的漏洞利用是否大規(guī)模被惡代使用只是曝光與否的問(wèn)題。此外,雖然 Stack clash 的 * EMBARGOED" 從開(kāi)始到現(xiàn)在已經(jīng) 1 個(gè)月,但至今CVE-2017-1000370(offset2lib bypass) 仍然未修復(fù),RedHat 網(wǎng)站上所謂的 "Under Investigation" 只是繼續(xù)等待 Linux 主線(xiàn)內(nèi)核的修復(fù),或許要讓 Linux 內(nèi)核安全有所改善我們需要更多的 stack clash 和 DirtyCow 持續(xù)曝光。
因?yàn)槔娴年P(guān)系,Linux 基金會(huì)對(duì)自由軟件社區(qū)和 GPL 已經(jīng)非常不友好,雖然 Greg K-Hartman 一直強(qiáng)調(diào) Linux 基金會(huì)是一個(gè)非盈利組織,但一個(gè) NGO 的 CEO 為什么有高達(dá) 49 萬(wàn)美金(2014 財(cái)年)的年薪,也沒(méi)人知道為什么Greg 本人會(huì)有 Google 的郵箱(拿 Linux 基金會(huì)和 Google 雙薪水?),Linux 內(nèi)核本來(lái)有一次改善安全的機(jī)會(huì),可惜 Linux 基金會(huì)的市場(chǎng) PR 需求搞砸了整件事。HardenedLinux 社區(qū)在這里建議所有的 GNU/Linux 用戶(hù)請(qǐng)認(rèn)真重新評(píng)估數(shù)據(jù)資產(chǎn)的重要性所對(duì)應(yīng)的安全等級(jí)。"
匿名網(wǎng)友評(píng)論:
Linus 的立場(chǎng)其實(shí)很清楚,合并到 Linux mainstream 的代碼必須邏輯拆分(便于各子系統(tǒng)統(tǒng)一維護(hù))、可閱讀理解、可審計(jì)。其中,可審計(jì)的要求有兩方面:代碼在版權(quán)上不存在問(wèn)題;代碼容易理解技術(shù)原理和設(shè)計(jì)思路。Linux 現(xiàn)在的內(nèi)核代碼貢獻(xiàn)機(jī)制是長(zhǎng)期以來(lái)形成的,特別是 commit log 這個(gè)環(huán)節(jié),拆分后的 commit log 描述是技術(shù)上的需要,更是版權(quán)上的需要。了解 commit log 約定的歷史的人,會(huì)很清楚為什么這么要求。不了解但感興趣的可以看 SCO v IBM 案之后,在 Linux 內(nèi)核 commit log 中引入 signoff 標(biāo)簽的歷史(https://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for 。Linus 的原始郵件沒(méi)搜索到,知道的人請(qǐng)補(bǔ)充)。PaX/Grsecurity 一直以來(lái)漠視這方面的要求,不拆分 patch(提交的是大 patch),不符合代碼進(jìn)入 Linux mainstream 的約定規(guī)范。相關(guān)維護(hù)者不得不猜測(cè)邏輯并拆分相關(guān)代碼,這又被 PaX/Grsecurity 描述為 copy/paste “抄代碼”。PaX/Grsecurity 對(duì) Linux 內(nèi)核維護(hù)方式、對(duì) Linux Foundation 充滿(mǎn)敵意。即使在這次論戰(zhàn)中,Linus 也一貫地表達(dá) PaX/Grsecurity 應(yīng)該拆分代碼以達(dá)成直接貢獻(xiàn) Linux mainstream 的目標(biāo),避免其他人去猜測(cè)實(shí)現(xiàn)原理及拆分代碼;而 PaX/Grsecurity 則糾纏于 Linux 中存在各種 bug(包括 Linus 自己引入的 security bug),消極合作甚至不合作。Spender 提到的的 vmappable stack 的 CVE,更是其不合作、看笑話(huà)的敵視態(tài)度的體現(xiàn)。一個(gè)特性進(jìn)入 Linux mainstream,特別是核心的 vm 管理部分,是需要長(zhǎng)時(shí)間的反復(fù) RFC (request for comment),反復(fù)改進(jìn)過(guò)程的。不在 RFC 過(guò)程中指出問(wèn)題和改進(jìn),其“我是對(duì)的,我是專(zhuān)家,你們這些Linux maintainer都是傻瓜”的心態(tài)可見(jiàn)一斑。至于 KPI 之說(shuō),更是欲加之罪。Linux 發(fā)展到今天,依賴(lài)出于興趣的 random contributor 是不夠的,sponsored developer 成為主力是不可避免的。某些代碼代表廠商利益和訴求,但大部分的貢獻(xiàn)是 vendor neutral 的。比如 Google 塞進(jìn)了 binder (Android 需要),但也貢獻(xiàn)了 TFO (tcp fast open)、lockless listen、BBR(bottleneck bandwidth & rtt) 等相當(dāng)大一批重要的代碼,這些是所有使用者及那些并不貢獻(xiàn)代碼的互聯(lián)網(wǎng)公司都受益的;又比如 livepatch 方面,SUSU/RedHat 扯皮拉筋,政治因素比較多,但項(xiàng)目也一直在前行?!盞SPP 大多時(shí)候只是在重復(fù)的抄襲 PaX/Grsecurity 的各種特性以獲得各自雇主那里的 KPI 和 credit,各種混亂的代碼合并到了 Linux 主線(xiàn)影響了 PaX/Grsecurity 的正常開(kāi)發(fā)“,這個(gè)困境并不是 Linus 及 Linux Foundation 愿意的,但 Pax/Grsecurity 顯然不想正常方式解決,只想內(nèi)核維護(hù)者屈服和放棄原則。
-
Linux系統(tǒng)
+關(guān)注
關(guān)注
4文章
605瀏覽量
28585
原文標(biāo)題:2017年的Linux內(nèi)核防護(hù)依然脆弱
文章出處:【微信號(hào):magedu-Linux,微信公眾號(hào):馬哥Linux運(yùn)維】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
CYW20829是否能夠同時(shí)通過(guò)BT/BLE連接最多3臺(tái)設(shè)備?
IP防護(hù)等級(jí)小知識(shí)
時(shí)源芯微 接口濾波與防護(hù)電路的設(shè)計(jì)
時(shí)源芯微ESD防護(hù)ANT靜電防護(hù)方案

授時(shí)安全防護(hù)裝置是什么?怎么選?

機(jī)械碰撞防護(hù)等級(jí)測(cè)試

電磁脈沖防護(hù)系統(tǒng)的作用有哪些
ADS8381是否具備輸入過(guò)壓保護(hù)功能和靜電防護(hù)功能?
使用TPD12S016用于HDMI接口的ESD防護(hù),在linux讀取下總是超時(shí),為什么?
AFE4900是否能夠實(shí)現(xiàn)FNIR的功能?
IP等級(jí)外殼:防護(hù)性能試驗(yàn)全解析

EMC浪涌防護(hù)設(shè)計(jì)方案

浪涌及過(guò)電壓防護(hù)方法

評(píng)論