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 service
type 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 service
allow pekiserver pekiserver_service:service_manager add;
# Execute commands
allow 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.txt
allow pekiserver system_data_file:file { open read };
經過SELinux策略調整後，Native級服務調用成功執行，如下圖所示，可以在應用中正常顯示出iptables防火牆規則。
