CyanogenMod 將整合 NSA 開發的 SELinux,這具體有什麼用?

Solidot | CyanogenMod將整合SELinux

CyanogenMod宣布將合併SEAndroid項目,將SELinux整合到固件鏡像中。SELinux是NSA開發的訪問控制安全實現,CyanogenMod開發者表示它不是政府機構開發的監控後門,不是稜鏡或防火長城之類的老大哥風格的監控項目。它可以讓用戶和管理員對訪問控制有更大的控制,防止應用程序執行惡意功能,阻止其訪問特定數據,或以root許可權訪問。


謝邀。

selinux也有10+年的歷史了,並不是新鮮玩意,但最近兩年卻火起來了。這要歸功於APT、0day等安全威脅,傳統的防護、檢測方法根本就沒有用,AV、IPS都是基於規則的,在攻擊被發現之前都是沒有規則的,當然也就沒法檢測。

無法檢測、無法有效防禦,與此同時安全威脅越來越多,那怎麼辦呢?管!加強許可權管理自然是不二選擇。

selinux也好,sandbox也好,說到底都是邊界管理式的安全管理。

前段時間的struts2漏洞,導致無數網站被脫褲,試想如果做好了邊界管理(亦許可權管理),還會有這些可怕的損失嗎。

selinux現在並沒有用好,或者說還並沒有得到充足的發展,相信selinux、sandbox等相關安全技術會越來越火。


我業餘時稍微折騰一下 Linux,關於 SELinux 稍微有點了解,主要是這玩意許可權弄起來太麻煩(我是菜鳥)。

首先,SELinux 是 Linux 發行版 Fedora 的默認配置,現在安裝 Fedora 後,SELinux 是默認安裝並啟動的。說說 SELinux 麻煩在哪,SELinux 給系統里所有的文件都設置了訪問策略,比如某些文件只能由特定的程序或者用戶組進行訪問,其他的程序訪問一律阻止。

舉個例子,有一次我把 Fedora 里 /var/log 裡面的文件都刪了,然後發現有些程序運行出錯,於是我就從另外一個系統里把 /var/log 拷回來,並且許可權都改過來了,但是程序還是不能正常訪問,最後發現是複製回來的文件的文件類型標籤不對,訪問全被 SELinux 給阻止掉了。

還有一次,安裝完 Linux 版的 Matlab,但是無法啟動,一執行程序 SELinux 就報警,說 Matlab 里的庫文件無權執行,最後火了就把 SELinux 給關了。

SELinux 確實是提升系統安全的,不過如果策略沒有配置好,會給用戶造成非常多的麻煩。


回答這個問題,首先說一下Selinux是什麼,解決了什麼問題。

做為黑客最愛好的操作系統,現代IT技術和互聯網發展的基石,Linux操作系統的許可權設計囿於簡陋的ext文件系統,難以實現詳盡和豐富的用戶訪問及許可權管理。相對應於運行於Linux上的部署數量巨大的各類基礎服務、應用,尤其是隨著伺服器運算能力的提升而同時在同一台伺服器上運行的服務和應用,如何進行細粒度的訪問控制就成為一個非常嚴重的問題,另外考慮到伺服器上的數據、日誌、各類文件會不斷增長,單純通過基於文件或目錄加許可權的方式進行動態的訪問控制顯然是非常吃力的。

SElinux就是為了解決這一問題而產生的解決方案之一,它的設計思路是:對文件和目錄設定標籤,對所有需要運行的進程也設定標籤,並通過制定策略來控制特定進程對特定文件的訪問。通過這種方式,可以很方便的向一個新增加的服務開放一組不同位置的數據的訪問,也可以隨時調整某個應用對某類數據的訪問許可權。一個典型的例子就是,操作系統的大部分文件(比如,儲存用戶賬戶信息的passwd文件)默認許可權是對非指定用戶可讀(644許可權),而且如果改動為非指定用戶不可讀,就可能直接影響服務和進程的訪問(因為你不知道哪個進程出於什麼目的要參考一下這個文件,用戶home目錄的位置也在這裡),那麼如果web服務被發現漏洞後就可以訪問這個文件。通過SELinux的策略控制,就可以預先限定web服務進程能訪問的文件的標籤,預防可能的系統漏洞和泄露。

SELinux的實現是在Linux內核增加相關模塊,源代碼完全遵循Linux的開源協議GPL,換句話說,每個人都可以看到SELinux的源代碼進行審核;可以肯定的說,不存在NSA通過這個功能進行監控、後門、信息收集的可能性。


目錄

一、DAC 許可權模型的安全隱患

二、SELinux 的設計思想

三、SELinux 的世界觀

四、SELinux 的實現方法

正文

一、DAC 許可權模型的安全隱患

一個運行中的 Linux 系統,存在三個集合:用戶集合,進程集合,文件集合。每個進程和文件都有且僅有一個對應的用戶。所謂許可權模型,就是在系統運行過程中,如何決定屬於用戶 A 的進程是否可以對屬於用戶 B 的某個文件執行某種操作。

Linux 的許可權模型以 DAC( Discretionary Access Control)為基礎。 DAC 的核心機制可以簡述為:

? 每個用戶對屬於自己的任意文件,具有完全的控制權;

? 每個用戶對屬於自己的任意文件,可自由決定其他用戶是否可以【讀/寫/執行】;

? root 用戶對系統中的任意文件,具有完全的控制權;

? root 用戶對系統中的任意文件,可自由決定其他用戶是否可以【讀/寫/執行】。

雖然 DAC 許可權模型容易理解,且能簡單方便地解決大部分許可權控制問題,但在長期實踐中,已逐漸暴露出其存在重大安全隱患:

? 對一個文件而言,普通用戶很難事先判斷什麼樣的許可權才是合理的。很難避免因為許可權設置不合理而導致的安全漏洞。

? 把許可權管理的責任全部交給了用戶。系統的安全性完全取決於用戶本人的安全知識和安全意識,這顯然是非常脆弱、非常不可靠的。

? root 用戶的權力過大。任何以 root 身份運行的程序,只要有任何一個漏洞被利用,都意味著整個安全體系的崩潰。

二、SELinux 的設計思想

DAC 的問題出在對用戶的授權過於強大。 MAC( Mandatory Access Control)許可權模型則可解決上述問題。 MAC 和 DAC 不是對立關係,二者可以分別單獨存在,也可以共存於同一個系統。SELinux 是 MAC 許可權模型的一種實現,且與 DAC 共存。

安全審查機制可分為兩大類:

? 一種是「法無禁止則允許」的黑名單機制。典型例子:殺毒軟體利用病毒庫來決定是否應該允許某種操作。

? 一種是「法無允許則禁止」的白名單機制。典型例子:只有持有某小區門卡的人才能進入該小區。

在安全性方面,白名單機制要比黑名單機制可靠得多。 SELinux 就是一種白名單機制,其設計思想可表述為:

? 凡是與安全有關的任何進程行為,都必須事先獲得安全管理策略的明確允許,否則一律禁止。

? 凡是 SELinux 沒有明確允許的任何安全操作,任何用戶,哪怕是 root 用戶,都沒有允許的權力。

SELinux 引入了兩個重要概念:

? SELinux 安全策略: 是 SELinux 判定是否應該放行某項安全操作的唯一依據。

? SELinux 安全策略管理機構: 是組織內部的信息安全專家小組,負責開發組織內部的SELinux 安全策略。

通過下列系統級強制手段, SELinux 可有效防止因用戶安全知識不足或安全意識薄弱而導致的系統漏洞:

? 如果 SELinux 安全策略與 DAC 安全策略不一致, SELinux 將按照「一票否決」的原則從嚴把關。例如:某項安全操作, SELinux 安全策略允許,但是 DAC 安全策略禁止,那麼結果就是禁止;反之,如果 SELinux 安全策略禁止,但是 DAC 安全策略允許,那麼結果還是禁止。換句話說,只有二者同時允許,該項安全操作才會被允許。

? SELinux 安全策略管理機構的許可權要高於系統中的 root 用戶。 SELinux 安全策略管理機構下發的 SELinux 安全策略, root 用戶在運行過程中無權更改,除非 root 用戶卸載 SELinux安全策略並重啟系統。

三、SELinux 的世界觀

如果不糾結於 SELinux 的嚴格定義和技術實現細節,僅考察關鍵性的高層概念,我們可以簡單地認為,在 SELinux 的眼中:

1. Linux 系統是由主體( Subjects)和客體( Objects)構成的;

2. 主體就是進程,客體就是文件;

3. 每個主體都有一個分類標籤( Label),分類標籤相同的主體, SELinux 視為同一個主體;

4. 每個客體都有一個分類標籤( Label),分類標籤相同的客體, SELinux 視為同一個客體;

5. 每個客體都有一個的操作集合(例如:查詢目錄、讀寫數據、讀寫文件屬性、作為程序執行等);

6. 系統中的一切安全檢查行為都可歸納為這樣一個問題: 主體 A(假定標籤為 label_A)請求對客體 B(假定標籤為 label_B)執行操作 C(假定操作集合為 {read, write}),是否允許?

7. 對上述問題的應答演算法:如果 SELinux 之外的其他的系統安全機制已經禁止該操作,直接返回;否則繼續檢查 SELinux 的安全策略;如果找到一條明確允許該操作的安全策略(例如: allow label_A label_B:file {read,write};)則允許該操作;如果沒有找到這樣的安全策略,則禁止該操作。

四、SELinux 的實現方法

SELinux 的實現包括兩大部分:應用層實現和內核層實現。應用層實現包括安全策略編譯器和其他一些輔助工具。內核層實現包括內核函數 Hook 框架 LSM( Linux Security Modules)和Security Server。SELinux 的重要工作都是在內核層完成的,因此,我們只重點介紹一下內核層的

實現機制。

先用一句話概括: SELinux 是通過修改 Linux 內核源代碼,為有關內核數據結構添加安全上

下文指針域,為有關內核函數添加安全鉤子( Hook)而實現的。

LSM 的實現方式:

1. 找出 Linux 內核代碼中所有與安全有關的數據結構,添加一個指針域:void* security_context; 這個指針域負責保存與 SELinux 有關的上下文;

2. 找出 Linux 內核代碼中所有與安全有關的內核函數,在其入口處添加一個安全鉤子;

3. 維護安全上下文;

4. 為 Security Server 提供安全鉤子註冊和維護服務;

Security Server 的實現方式:

1. 向 LSM 註冊自己的安全鉤子;

2. 載入並解釋編譯後的安全策略資料庫;

3. 在安全鉤子回調函數中執行安全策略檢查任務。


CyanogenMOD確實是安卓最大的第三方MOD製作者,但是這次採用SElinux Until,我覺得更深層面上的應該是出於滿足越來越多的給予用戶Root許可權的第三方對於系統管理的需要。

Selinux確實是一款優秀的伺服器許可權管理系統,對於中小型企業來說,伺服器程序,例如Apache,出現0day或漏洞,往往自己無法做出技術上的響應,而同時在距離官方給出補丁的時候有一段真空期,而這個時候利用MAC(許可權管理系統),比如SElinux就可以防止入侵者提權獲得關鍵文件信息,比如/etc/passwd。

隨著,稜鏡計劃和一些類似的商業竊取事件的出現,我們不得不重新把注意力放在安卓系統的安全上,首先介紹一下安卓目前的安全機制。

應用程序建立在Davik虛擬機(一種類似java虛擬機,但比較輕量級)和JAVA編寫的類庫當中,apk文件中的Manifest XML文件攜帶了該應用程序需要的許可權信息,同時,每個apk會被內核分配一個(posix user)ID,每個Id會擁有一個進程,不同進程之間不能通信。相當於一個Sandbox機制。注意!除非在這個Manifest XML中聲明了一個別名,而兩個具有系統別名的APK被分配同一個posix user id.

在此之上,內核建立了一套文件許可權機制,不同的文件由不同Id user和用戶組擁有,並擁有相對用的r ,w ,x許可權。問題在於,安卓的授權機制,應用程序只想獲得A-,但是安卓本身並沒有A-這個選項,所以必須申請A。同時,Apk的許可權申請往往又是在安裝前批准的,你只有裝了之後,才知道這個程序要做什麼。這給apk的移植性確實帶來了巨大方便,但是問題在於,一些惡意竊取用戶隱私的程序也出現了,更別提國內絲毫不強調來源的安卓程序市場了。

簡單的說,一是用戶不知道這些許可權意味著什麼,二是許可權策略本身太過粗獷,三是存在繞過風險。

所以,這次引入SElinux並不是一個突發奇想,而是一個長期的需要,Selinux,你可以理解成運行在android上的HIPS,我們對於重點高許可權進程和關鍵系統文件採用二次確認許可。使用這樣的頂部策略可以規避絕大多數泄密和惡意事件。其性能影響也會隨著整合而降低不少。同時,對於定製用戶,SElinux可以進一步的滿足商務需求和個人隱私的保護。基於SElinux可以在一些非Root機器上安裝類似手機助手這樣的程序。從而實現定製化保護。


是引入了強制訪問模式,對自主訪問控制的缺陷做以補充

(1)Discretionary Access Control (DAC)自主訪問控制方案:在這個方案里,用 戶給予訪問資源的許可權,目標資源根據用戶的許可權屬性來判斷他是否有許可權執行請求的操作。在該模型中,同一用戶對不同的資源對象有不同許可權;不同的用戶對用 一資源對象有不同的許可權;用戶能自主地將自己擁有的許可權授予其他用戶。

缺點:由於DAC模型可以任意傳遞許可權,用戶能間接獲得本不具有的訪問許可權,因此DAC模 型的安全性較低,不能給系統充分的數據保護。

(2)Mandatory Access Control(MAC)強制訪問控制方案:在MAC方案中,每個目標由安全標籤分級,分級列表指定哪種類型的分級目標對象是可以訪問的。訪問時,系統先 對用戶的訪問許可級別和資源對象的密級進行比較,再決定用戶是否可以訪問資源對象。用戶不能改變自身和資源對象的安全級別,只有系統管理員或管理程序才能 控制資源對象和用戶的級別。

優點:用戶許可權的層次結構良好,存取控制相當嚴格

沒有加入seandroid之前Android系統僅僅是基於自主訪問控制的安全模式,安全性比較低,所以將強制訪問控制lselinux機制移植到Android中。SEAndroid在架構和機制上與SELinux一致,考慮到移動設備的特點,所以移植到SEAndroid的只是SELinux的一個子集。用來強化Android操作系統對App的存取控管,建立類似沙箱的執行隔離效果,來確保每一個App之間的獨立運作,也因此可以阻止惡意App對系統或其它應用程序的攻擊。

SEAndroid的安全檢查覆蓋了所有重要的方面包括了域轉換、類型轉換、進程相關操作、內核相關操作、文件目錄相關操作、文件系統相關操作、對設備相關操作、對app相關操作、對網路相關操作、對IPC相關操作。


selinux很牛逼

但是在一般情況下就是selinux=0

android其實很亂,只要你有root許可權你可以訪問任何文件。導致惡意軟體的產生。android完全基於linux,底層程序比較好寫,通訊監控很好做,ssl劫持啥的都不是問題。


推薦閱讀:

如何看待川普說斯諾登是一個bad guy並且暗示他應該被處決,以及川普未來對於舉報者可能的態度?

TAG:CyanogenMod | Android | SELinux | NSA |