本篇內(nèi)容介紹了“SElinux是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

為瓦房店等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及瓦房店網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站制作、成都網(wǎng)站制作、瓦房店網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

背景

SELinux(Security-Enhanced Linux) 是美國國家安全局（NSA）對(duì)于強(qiáng)制訪問控制的實(shí)現(xiàn)，是 Linux歷史上最杰出的新安全子系統(tǒng)。NSA是在Linux社區(qū)的幫助下開發(fā)了一種訪問控制體系，在這種訪問控制體系的限制下，進(jìn)程只能訪問那些在他的任務(wù)中所需要文件

在 SELinux 出現(xiàn)之前，Linux 上的安全模型叫 DAC，全稱是 Discretionary Access Control，翻譯為自主訪問控制。 DAC 的核心思想很簡(jiǎn)單，就是：進(jìn)程理論上所擁有的權(quán)限與執(zhí)行它的用戶的權(quán)限相同。比如，以 root 用戶啟動(dòng) Browser，那么 Browser 就有 root 用戶的權(quán)限，DAC 管理太過寬松，不夠靈活所以有了SELinux。

作用

在這種訪問控制體系的限制下，進(jìn)程只能訪問那些在他的任務(wù)中所需要文件。

SELinux使用類型強(qiáng)制來改進(jìn)強(qiáng)制訪問控制。所有的主體（程序進(jìn)程）對(duì)客體（文件/socket等資源）的訪問都有一條TE規(guī)則來許可。當(dāng)程序訪問一個(gè)資源的時(shí)候，系統(tǒng)會(huì)搜索所有的TE規(guī)則集，并根據(jù)結(jié)果進(jìn)行處理。這個(gè)規(guī)則集是由訪問向量規(guī)則（AV， Access Vector）來描述的。

內(nèi)核向外部暴露允許訪問的資源權(quán)限，由TE來描述主體擁有什么樣的訪問權(quán)。SELinux定義了30個(gè)不同的客體類別：

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

每個(gè)客體類別都定義了操作許可，比如針對(duì)file有19個(gè)操作許可：

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

查看進(jìn)程的SElinux權(quán)限

在 SELinux 中，每種東西都會(huì)被賦予一個(gè)安全屬性，官方說法叫做 Security Context，Security Context 是一個(gè)字符串，主要由三個(gè)部分組成，例如 SEAndroid 中，進(jìn)程的 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

上面的最左邊的一列就是進(jìn)程的 Security Context，以第一個(gè)進(jìn)程 wpa_supplicant 為例

u:r:hal_wifi_supplicant_default:s0

• u 為 user 的意思，SEAndroid 中定義了一個(gè) SELinux 用戶，值為 u

• r 為 role 的意思，role 是角色之意，它是 SELinux 中一個(gè)比較高層次，更方便的權(quán)限管理思路。簡(jiǎn)單點(diǎn)說，一個(gè) u 可以屬于多個(gè) role，不同的 role 具有不同的權(quán)限。

• hal_wifi_supplicant_default 代表該進(jìn)程所屬的 Domain 為 hal_wifi_supplicant_default。MAC（Mandatory Access Control）強(qiáng)制訪問控制 的基礎(chǔ)管理思路其實(shí)是 Type Enforcement Access Control（簡(jiǎn)稱TEAC，一般用TE表示），對(duì)進(jìn)程來說，Type 就是 Domain，比如 hal_wifi_supplicant_default 需要什么權(quán)限，都需要通過 allow 語句在 te 文件中進(jìn)行說明。

• s0 是 SELinux 為了滿足軍用和教育行業(yè)而設(shè)計(jì)的 Multi-Level Security（MLS）機(jī)制有關(guān)。簡(jiǎn)單點(diǎn)說，MLS 將系統(tǒng)的進(jìn)程和文件進(jìn)行了分級(jí)，不同級(jí)別的資源需要對(duì)應(yīng)級(jí)別的進(jìn)程才能訪問

訪問規(guī)則

AV用來描述主體對(duì)客體的訪問許可。通常有四類AV規(guī)則：

• allow：表示允許主體對(duì)客體執(zhí)行許可的操作.

• neverallow：表示不允許主體對(duì)客體執(zhí)行制定的操作。

• auditallow： 表示允許操作并記錄訪問決策信息。

• dontaudit：表示不記錄違反規(guī)則的決策信息，切違反規(guī)則不影響運(yùn)行`

通用的類型規(guī)則語法位：

1 allow platform_app debugfs:file { read ioctl };

表示類別為platform_app的程序進(jìn)程，對(duì)debugfs類型的文件執(zhí)行read和ioctl操作。

模式切換

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

Disabled就不用說了。

permissive就是Selinux有效，但是即使你違反了策略的話它讓你繼續(xù)操作，但是把你的違反的內(nèi)容記錄下來。在我們開發(fā)策略的時(shí)候非常的有用，是UserDebug的默認(rèn)模式。

Enforcing就是你違反了策略，你就無法繼續(xù)操作下去。

通過以下命令可以切換系統(tǒng)的SElinux模式 adb shell setenforce 0

0--代表Permissive

1--代表Enforcing

adb shell getenforce---查看狀態(tài)

Android系統(tǒng)上遇到SElinux如何調(diào)試

在android系統(tǒng)開發(fā)中，因?yàn)閟elinux權(quán)限問題一般會(huì)在user版本出現(xiàn)，但我們?cè)趗serdebug版本通過以下方式可以驗(yàn)證

１、第一步先確定問題是否由selinux權(quán)限問題引起

通過命令： adb shell getenforce //查看當(dāng)前SePolicy權(quán)限狀態(tài)（Enforcing　表示打開　Permissive表示關(guān)閉）

userdebug版本處于permissive關(guān)閉狀態(tài) 　　settenforce 1 //更改狀態(tài)到Enforcing，０表示Permissive 　　進(jìn)行測(cè)試，如果此時(shí)問題會(huì)出現(xiàn)，那么就是selinux權(quán)限問題

2、解決方法

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

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

2.adb logcat –b events

關(guān)鍵字：

avc: denied

如圖：

這是一個(gè)selinux權(quán)限問題，我們只關(guān)注denied{} 、scontext 、tcontext 和 tclass 四個(gè)關(guān)鍵字就可以

• denied{}括號(hào)內(nèi)的內(nèi)容表示被拒的權(quán)限動(dòng)作

• scontext的值表示需要在哪個(gè)te文件添加

• tcontext 表示需要賦予權(quán)限的目標(biāo)

• tclass 表示權(quán)限問題的類型

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

注意：有時(shí)在Enforcing模式時(shí)不能看到所有缺少的權(quán)限日志，例如：

這個(gè)日志由于FileNotFoundException問題導(dǎo)致程序不會(huì)繼續(xù)執(zhí)行到代碼終點(diǎn)，所以沒有執(zhí)行的代碼所缺少的權(quán)限日志就不能得到，但是在Permissive模式所有權(quán)限問題會(huì)打印出來，所以建議抓log在Permissive模式下或者兩種模式都抓

“SElinux是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！