DTE Linux、SELinux與SEAndroid之間的對比分析

標籤：安全   android   學術   存取控制   security   

2000年，美國威廉瑪麗學院的研究人員Serge等人在USENIX的4th annual Linux Showcase &Conference會議上發表了題為“Domainand Type Enforcement for Linux”的文章。該文章第一次將DTE模型用於Linux，實現了DTE Linux原型系統。

同年，美國國家安全域NSA的Stephen Smalley等人發布了開源的Linux安全架構SELinux，SELinux第一個版本基於Linux 2.5核心，並採用GPL開源協議發布。在2003年8月，SELinux正式整合進Linux官方核心的2.6.0版本。

SELinux作為目前DTE在Linux上實現的業界標準，其理念絕大部分是與DTE Linux一致的，但是由於兩個成果分屬不同的研究團隊，因此其具體機制仍稍有差別。由於目前介紹DTE的資料很多，因此本文從另外一個角度，主要介紹DTE Linux與SELinux的區別。同時，由於本人的研究方向是Android安全，SELinux在Android系統上也進行了實現，名為SEAndroid，因此本文會結合Android系統來闡述一個配置SELinux策略的具體案例。本文檔主要包括以下兩個部分：1）DTE Linux與SELinux的異同；2）SEAndroid策略配置案例。

第1章           DTE Linux與SELinux的異同
1.1           相同之處

DTE Linux和SELinux都實現了DTE模型，主要包括以下三類存取控制：

1）Type Access

2）Domain Access

3）Domain Transition

1.2           不同之處
1）策略檔案存放模式不同

DTE Linux採用了集中式的策略檔案方案，其策略檔案儲存體路徑為/etc/dte.conf；而SELinux採用了分散式的策略檔案方案，其策略檔案儲存體在/etc/selinux/檔案夾下，包括policy.conf檔案。我個人認為SELinux的方案更優，不同的策略檔案更為模組化，方便了不同組織、公司針對自身負責的程式邏輯進行策略編寫，最後通過策略編譯，所有的SELinux策略檔案被編譯成一個完整的策略庫，在核心可以高效運行，不會產生效率損失。

2）與傳統DAC判斷邏輯之間的順序不同

DTE Linux在訪問授權時，先判斷DTE策略，再判斷DAC策略；而SELinux相反，先判斷DAC策略，再判斷DTE策略。我個人認為SELinux的實現更好，這是考慮到DTE策略是以阻止惡意攻擊為目的，只有在攻擊出現時DTE策略才會執行拒絕，正常情況下的一個訪問被DAC策略拒絕的可能性比被DTE策略拒絕的可能性高得多，因此從效能角度考慮，將DAC策略判斷邏輯放在前面是合適的。

3）代碼實現是否依靠LSM

LSM是Linux Secrity Module的簡稱，即Linux安全模組。其是一種輕量級通用存取控制架構，適合於多種存取控制模型在它上面以核心可載入模組的形實現。使用者可以根據自己的需求選擇合適的安全模組載入到核心上實現。LSM架構在2003年12月整合到Linux 2.6官方代碼中。LSM目前支援包括AppArmor,SELinux, Smack and TOMOYO Linux等多種安全架構。（文章發表幾年之後，DTE Linux也在Linux 2.6 LSM進行了實現）

DTE Linux文章是文章作者自己基於Linux 2.3版本實現的原型系統，時間較早，當時還沒有LSM架構，因此所有的函數鉤子、新增加的系統調用都是DTE for Linux原型系統自己完成的。

SELinux架構是在LSM基礎上開發的。背後還有一段插曲：2001年Linux KernelSummit大會上NSA找到Linux創始人Linus希望將SELinux整合進Linux 2.5中，Linus當時拒絕了這一請求，這是由於當時除了SELinux之外還有其他的眾多安全架構，Linux社區無法達成共識採用哪一個架構。因此Linus決定將安全架構做成“一個模組”，於是後來就有了LSM和基於LSM的SELinux。

4）支援的模型不同

相比DTE Linux文章中只涉及DTE模型而言，SELinux在實現DTE模型的同時，還實現了RBAC模型和MLS模型（可選）。

第2章           SEAndroid策略配置案例

SEAndroid全稱Security Enhancements (SE) for Android?，是SELinux在Android作業系統上的一個實現。目前SEAndroid並不受限於SELinux的功能，已經開始研發專用於Android系統的新的安全特性。

最近我在從事Android安全強化方面研究，其中涉及到一個配置SELinux策略的真實的案例。需求是：在保證生產和維護人員充分許可權的情況下，防止普通使用者取得Root許可權。我們這裡主要說下如何保證生產和維護人員的充分許可權，本質上就是實現“root命令調用路徑”。

我們提出的方案是：

提供一個運行在root權限等級的Native級服務，提供命令執行介面供上層應用進行IBinder進程間調用，該Native級服務的調用需要提供安全秘鑰，以保證只有該應用能夠通過服務進行root命令的調用。同時該Native級服務具有一定的魯棒性，當遇到以外關閉時，系統會自動重啟該Native級服務。

本方案的一些功能，如網路存取控制，需要進行iptables規則配置，而iptables配置是需要用到root許可權的。為了保證上層應用能夠使用root許可權，本方案需要設計專供上層應用使用的、足夠安全的root許可權調用路徑。該方法主要依靠Native級服務實現。當上層應用在需要特殊許可權時，會調用Native級服務，Native級服務在驗證安全秘鑰成功後，自行以root許可權調用相關的命令，並嚮應用層返回結果。

目前我們這個方案是在Android5.1上實現的，Android5.1上預設開啟了SELinux功能，並且其原則設定非常嚴格，我們的方案受到很多SELinux策略的拒絕而無法成功執行，因此需要修改SELinux策略，開一個“口子“，允許存取我們的Native級服務調用。

SELinux策略調整方案主要有兩步：
1）添加標籤：

1. 聲明peki服務的type標籤為pekiserver_service

\51droid\android-5.1.0_r3\external\sepolicy\service_contexts

Line: 123添加：

peki                                     u:object_r:pekiserver_service:s0

 

2. 定義type標籤pekiserver_service為service_manager_type的子標籤

\51droid\android-5.1.0_r3\external\sepolicy\service.te

Line: 13添加：

type pekiserver_service,        service_manager_type;

 

3. 聲明pekiserver精靈的type標籤為pekiserver_exec

\51droid\android-5.1.0_r3\external\sepolicy\file_contexts

Line: 166添加：

/system/bin/pekiserver    u:object_r:pekiserver_exec:s0

 

2）配置規則：

4. 添加TE策略檔案pekiserver.te

\51droid\android-5.1.0_r3\external\sepolicy\

添加pekiserver.te檔案

pekiserver.te檔案內容如下：

# pekiserver - Peki servicetype pekiserver, domain;type pekiserver_exec, exec_type, file_type;init_daemon_domain(pekiserver)typeattribute pekiserver mlstrustedsubject;net_domain(pekiserver)# Perform Binder IPC to system server.binder_use(pekiserver)binder_call(pekiserver, system_server)binder_call(pekiserver, appdomain)binder_service(pekiserver)# Add serviceallow pekiserver pekiserver_service:service_manager add;# Execute commandsallow pekiserver shell_exec:file { execute execute_no_trans read open};allow pekiserver system_file:file { execute_no_trans };# popen() failed to execute "iptables -L"allow pekiserver self:rawip_socket { create getopt setopt };allow pekiserver self:capability { net_raw net_admin};# Read iptables configuration file: /data/pekisafe/ctx_current/iptables_cfg.txtallow pekiserver system_data_file:file { open read };

經過SELinux策略調整後，Native級服務調用成功執行，如所示，可以在應用中正常顯示出iptables防火牆規則。 

DTE Linux、SELinux與SEAndroid之間的對比分析