SElinux

背景

SELinux(Security-Enhanced Linux) 是美國國家安全局（NSA）對於強制訪問控制的實現，是 Linux歷史上最傑出的新安全子系統。NSA是在Linux社區的幫助下開發了一種訪問控制體系，在這種訪問控制體系的限制下，進程只能訪問那些在他的任務中所須要文件

在 SELinux 出現以前，Linux 上的安全模型叫 DAC，全稱是 Discretionary Access Control，翻譯爲自主訪問控制。 DAC 的核心思想很簡單，就是：進程理論上所擁有的權限與執行它的用戶的權限相同。好比，以 root 用戶啓動 Browser，那麼 Browser 就有 root 用戶的權限，DAC 管理太過寬鬆，不夠靈活因此有了SELinux。

做用

在這種訪問控制體系的限制下，進程只能訪問那些在他的任務中所須要文件。

SELinux使用類型強制來改進強制訪問控制。全部的主體（程序進程）對客體（文件/socket等資源）的訪問都有一條TE規則來許可。當程序訪問一個資源的時候，系統會搜索全部的TE規則集，並根據結果進行處理。這個規則集是由訪問向量規則（AV， Access Vector）來描述的。

內核向外部暴露容許訪問的資源權限，由TE來描述主體擁有什麼樣的訪問權。SELinux定義了30個不一樣的客體類別：

security process system capability filesystem file dir fd lnk_file chr_file blk_file socket_file ...

每一個客體類別都定義了操做許可，好比針對file有19個操做許可：

`ioctl read write create getattr setattr lock relablefrom relableto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint

查看進程的SElinux權限

在 SELinux 中，每種東西都會被賦予一個安全屬性，官方說法叫作 Security Context，Security Context 是一個字符串，主要由三個部分組成，例如 SEAndroid 中，進程的 Security Context 可經過 ps -Z 命令查看：

rk3288:/ $ ps -AZ
u:r:hal_wifi_supplicant_default:s0 wifi      1816     1   11388   6972 0                   0 S wpa_supplicant
u:r:platform_app:s0:c512,c768  u0_a14        1388   228 1612844  57396 0                   0 S android.ext.services
u:r:system_app:s0              system        1531   228 1669680 119364 0                   0 S com.android.gallery3d
u:r:kernel:s0                  root           582     2       0      0 0                   0 S [kworker/1:2]
u:r:radio:s0                   radio          594   228 1634876  89296 0                   0 S com.android.phone
u:r:system_app:s0              system         672   228 1686204 141716 0                   0 S com.android.settings
u:r:platform_app:s0:c512,c768  u0_a18         522   223 1721656 152116 0                   0 S com.android.systemui

上面的最左邊的一列就是進程的 Security Context，以第一個進程 wpa_supplicant 爲例

u:r:hal_wifi_supplicant_default:s0

• u 爲 user 的意思，SEAndroid 中定義了一個 SELinux 用戶，值爲 u
• r 爲 role 的意思，role 是角色之意，它是 SELinux 中一個比較高層次，更方便的權限管理思路。簡單點說，一個 u 能夠屬於多個 role，不一樣的 role 具備不一樣的權限。
• hal_wifi_supplicant_default 表明該進程所屬的 Domain 爲 hal_wifi_supplicant_default。MAC（Mandatory Access Control）強制訪問控制 的基礎管理思路實際上是 Type Enforcement Access Control（簡稱TEAC，通常用TE表示），對進程來講，Type 就是 Domain，好比 hal_wifi_supplicant_default 須要什麼權限，都須要經過 allow 語句在 te 文件中進行說明。
• s0 是 SELinux 爲了知足軍用和教育行業而設計的 Multi-Level Security（MLS）機制有關。簡單點說，MLS 將系統的進程和文件進行了分級，不一樣級別的資源須要對應級別的進程才能訪問

訪問規則

AV用來描述主體對客體的訪問許可。一般有四類AV規則：

• allow：表示容許主體對客體執行許可的操做.

• neverallow：表示不容許主體對客體執行制定的操做。

• auditallow： 表示容許操做並記錄訪問決策信息。

• dontaudit：表示不記錄違反規則的決策信息，切違反規則不影響運行`

通用的類型規則語法位：

1 allow platform_app debugfs:file { read ioctl };

表示類別爲platform_app的程序進程，對debugfs類型的文件執行read和ioctl操做。

模式切換

SELINUX有「disabled」「permissive」，「enforcing」3種選擇。

Disabled就不用說了。

permissive就是Selinux有效，可是即便你違反了策略的話它讓你繼續操做，可是把你的違反的內容記錄下來。在咱們開發策略的時候很是的有用，是UserDebug的默認模式。

Enforcing就是你違反了策略，你就沒法繼續操做下去。

經過如下命令能夠切換系統的SElinux模式 adb shell setenforce 0

0--表明Permissive

1--表明Enforcing

adb shell getenforce---查看狀態

Android系統上遇到SElinux如何調試

在android系統開發中，由於selinux權限問題通常會在user版本出現，但咱們在userdebug版本經過如下方式能夠驗證

１、第一步先肯定問題是否由selinux權限問題引發 　　

經過命令： adb shell getenforce //查看當前SePolicy權限狀態（Enforcing　表示打開　Permissive表示關閉）

userdebug版本處於permissive關閉狀態 　　settenforce 1 //更改狀態到Enforcing，０表示Permissive 　　進行測試，若是此時問題會出現，那麼就是selinux權限問題

二、解決方法

1.adb shell dmesg----抓kernel log

(特別說明：adb shell "cat /proc/kmsg | grep avc" > avc_log.txt  能夠直接提出avc的log)

2.adb logcat –b events

關鍵字：

avc: denied

如圖：

　　

這是一個selinux權限問題，咱們只關注denied{} 、scontext 、tcontext 和 tclass 四個關鍵字就能夠

• denied{}括號內的內容表示被拒的權限動做

• scontext的值表示須要在哪一個te文件添加

• tcontext 表示須要賦予權限的目標

• tclass 表示權限問題的類型

這個問題的修改方式是在system_app.te文件添加以下代碼： allow system_app sysfs_thermal:dir search;

注意：有時在Enforcing模式時不能看到全部缺乏的權限日誌，例如：

這個日誌因爲FileNotFoundException問題致使程序不會繼續執行到代碼終點，因此沒有執行的代碼所缺乏的權限日誌就不能獲得，可是在Permissive模式全部權限問題會打印出來，因此建議抓log在Permissive模式下或者兩種模式都抓