建站
咨詢
售后
建站咨詢
新聞中心
SELinux是一種安全增強(qiáng)型的Linux安全機(jī)制，它可以使系統(tǒng)管理員更好的保護(hù)服務(wù)器和應(yīng)用程序，防止黑客和病毒攻擊。在SELinux中，策略是核心部分，它規(guī)定了哪些進(jìn)程可以訪問(wèn)哪些系統(tǒng)資源。本文將介紹如何編寫SELinux策略，由淺入深地分析策略文件的語(yǔ)法結(jié)構(gòu)和使用方法。
一、了解SELinux策略的類型
在SELinux中，策略分為多種類型，每種類型對(duì)應(yīng)著特定的用途。之一個(gè)類型是默認(rèn)策略，它與基于角色的訪問(wèn)控制（RBAC）相似?？梢酝ㄟ^(guò)修改 /etc/selinux/config 文件來(lái)修改默認(rèn)策略。第二個(gè)類型是定制策略，它是特定應(yīng)用程序所需要的策略。為了實(shí)現(xiàn)定制策略，需要針對(duì)應(yīng)用程序的特殊要求，創(chuàng)建一個(gè)新的策略模塊。第三個(gè)類型是輕量級(jí)策略，它是較新版本的SELinux中推出的。輕量級(jí)策略與默認(rèn)策略類似，但它所需的資源更少，因此可以提供更高的性能和更少的內(nèi)存占用。
二、編寫策略文件
在編寫SELinux策略文件時(shí)，要遵循以下步驟：
1. 安裝policycoreutils-devel
首先需要安裝 policycoreutils-devel 軟件包，該軟件包包含了許多 SELinux 開(kāi)發(fā)所需要的工具和庫(kù)，例如，seinfo、semanage、restorecond等等。
2. 創(chuàng)建策略文件
創(chuàng)建一個(gè)策略文件，文件名以 .te 結(jié)尾，例如 myapp.te。然后在該文件中聲明需要的類型和權(quán)限、角色以及訪問(wèn)策略。
3. 編譯策略文件
使用命令 checkmodule 來(lái)編譯 *.te 文件，并生成 *.mod 文件。例如：
checkmodule -M -m -o myapp.mod myapp.te
4. 生成策略包
使用命令 semodule_package 來(lái)生成一個(gè)策略包，該包可以通過(guò)安裝到系統(tǒng)的方式來(lái)應(yīng)用 SELinux 策略。例如：
semodule_package -o myapp.pp -m myapp.mod
5. 安裝策略包
使用命令 semodule 來(lái)安裝策略包：
semodule -i myapp.pp
以上就是編寫 SELinux 策略文件的主要步驟。接下來(lái)，我們將深入了解策略文件的語(yǔ)法和使用。
三、語(yǔ)法解析
在SELinux的策略文件中，有四種類型的語(yǔ)句，分別是類型聲明、屬性聲明、訪問(wèn)控制聲明和其他聲明。下面分別介紹這些語(yǔ)句的使用方法：
1. 類型聲明
類型聲明語(yǔ)句用于定義 SELinux 的類型。它包括類型的名稱和類型的種類，例如：
type myapp_t;
類型聲明語(yǔ)句是一個(gè)必需的語(yǔ)句，因?yàn)樵S多其他類型的語(yǔ)句都需要引用已存在的類型。
2. 屬性聲明
屬性聲明語(yǔ)句用于給 SELinux 對(duì)象定義屬性。一個(gè)對(duì)象可以有多個(gè)屬性。這些屬性通常用于描述對(duì)象的特征，例如：
attribute user_myapp_role;
3. 訪問(wèn)控制聲明
訪問(wèn)控制聲明語(yǔ)句用于定義 SELinux 的基本性質(zhì)，包括：
– 許可模式：表示允許或禁止特定的操作；
– 源類型：代表數(shù)據(jù)來(lái)源的特定類型；
– 目標(biāo)類型：目標(biāo)資源的特定類型；
– 類別：代表SELinux上下文中的安全標(biāo)簽。
其中，許可模式包括以下幾種：
– allow：允許指定操作；
– dontaudit：記錄指定操作，但不強(qiáng)制執(zhí)行；
– auditallow：允許指定操作，并記錄在審計(jì)日志中。
例如：
allow myapp_t httpd_sys_content_t:file {read getattr};
4. 其他聲明
其他聲明語(yǔ)句包含條件語(yǔ)句和模塊引用。條件語(yǔ)句可以讓我們根據(jù)規(guī)則來(lái)允許或拒絕訪問(wèn)，模塊引用允許我們引用其他模塊中定義的規(guī)則。
四、使用方法
本節(jié)將介紹如何使用SELinux策略文件來(lái)保護(hù)應(yīng)用程序或系統(tǒng)資源。
1. 創(chuàng)建應(yīng)用程序策略
創(chuàng)建一個(gè)策略文件，例如 myapp.te。該文件包含以下內(nèi)容：
policy_module(myapp, 1.0)
type myapp_t;
type httpd_myapp_script_t;
allow myapp_t httpd_myapp_t:process { getattr setuid };
allow httpd_myapp_script_t myapp_data_t:file { read write };
然后，編譯策略文件并生成策略包，以在系統(tǒng)上安裝：
checkmodule -M -m -o myapp.mod myapp.te
semodule_package -o myapp.pp -m myapp.mod
semodule -i myapp.pp
2. 修改文件SELinux安全性上下文
如果您想修改某個(gè)文件的SELinux安全性上下文，可以使用 chcon 命令來(lái)修改，但該修改只對(duì)一次啟動(dòng)后有效。要對(duì)文件進(jìn)行持久的SELinux安全性上下文設(shè)置，則需要使用 semanage fcontext 命令。例如：
chcon -t myapp_data_t /var/www/html/myapp/data.txt
semanage fcontext -a -t myapp_data_t “/var/www/html/myapp(/.*)?”
restorecon -v /var/www/html/myapp
以上是基本的策略創(chuàng)建和使用方法。但是，SELinux作為一種復(fù)雜的安全機(jī)制，還有很多高級(jí)的用法和細(xì)節(jié)需要深入研究和理解。希望本文能夠引導(dǎo)讀者進(jìn)入SELinux的世界，更好地保護(hù)服務(wù)器和應(yīng)用程序。
相關(guān)問(wèn)題拓展閱讀：
- SELinux權(quán)限
SELinux權(quán)限
在了解SELinux之前，我們先來(lái)了解一下Linux的兩種訪問(wèn)控制策略：DAC和MAC
DAC，自主訪問(wèn)控制（Discretionary Access control）。系統(tǒng)只提供基本的驗(yàn)證, 完整的訪問(wèn)控制由開(kāi)發(fā)者自己控制。
?DAC將資源訪問(wèn)者分成三類：Owner、Group、Other 。
?將訪問(wèn)權(quán)限也分成三類：read、write、execute
資源針對(duì)資源訪問(wèn)者設(shè)置不同的訪問(wèn)權(quán)限。訪問(wèn)者通常是各個(gè)用戶喊雀的進(jìn)程，有自己的uid/gid，通過(guò)uid/gid 和文件權(quán)限匹配, 來(lái)確定前滲行是否可以訪問(wèn)。DAC機(jī)制下，每一個(gè)用戶進(jìn)程默認(rèn)都擁有該用戶的所有權(quán)限。
DAC 有兩個(gè)嚴(yán)重問(wèn)題：
?問(wèn)題一：
?因?yàn)镽oot用戶是擁有所有權(quán)限的，所以DAC對(duì)Root用戶的限制是無(wú)效的。并且在Linux Kernel 2.1以后，Linux將Root權(quán)限根據(jù)不同的應(yīng)用場(chǎng)景劃分成許多的Root Capabilities, 普通用戶也可以被設(shè)置某個(gè)Root Capability。普通用戶如果被設(shè)置了CAP_DAC_OVERRIDE， 也可以繞過(guò) DAC 限制。
?問(wèn)題二：
?用戶進(jìn)程擁有該用戶的所有權(quán)限，可以修改/刪除該用戶的所有文件資源, 難以防止
惡意軟件
。
可見(jiàn)，DAC 有明顯的缺陷，一旦被入侵，取得Root權(quán)限的用戶進(jìn)程就可以無(wú)法無(wú)天，胡作非為，早期android版本就深受其害。
MAC， 強(qiáng)制性訪問(wèn)控制（Mandatory Access control）。 系統(tǒng)針對(duì)每一項(xiàng)訪問(wèn)都進(jìn)行嚴(yán)格的限制, 具體的限制策略由開(kāi)發(fā)者給出。
Linux MAC 針對(duì)DAC 的不足, 要求系統(tǒng)對(duì)每一項(xiàng)訪問(wèn), 每訪問(wèn)一個(gè)文件資源都需要根據(jù)已經(jīng)定義好了的策略進(jìn)行針對(duì)性的驗(yàn)證。系統(tǒng)可以針對(duì)特定的進(jìn)程與特定的文件資源來(lái)進(jìn)行權(quán)限的控制。即使是root用戶，它所屬的不同的進(jìn)程，并不一定能取得
root權(quán)限
，而得要看事先為該進(jìn)慧嘩程定義的訪問(wèn)限制策略。如果不能通過(guò)MAC 驗(yàn)證，一樣無(wú)法執(zhí)行相關(guān)的操作。
與DAC相比，MAC訪問(wèn)控制的“主體”變成了“進(jìn)程”而不是用戶。這樣可以限制了Root 權(quán)限的濫用，另外要求對(duì)每一項(xiàng)權(quán)限進(jìn)行了更加完整的細(xì)化, 可以限制用戶對(duì)資源的訪問(wèn)行為。
SELinux就是目前更好的MAC機(jī)制，也是目前的行業(yè)標(biāo)準(zhǔn)。
SELinux，安全增強(qiáng)Linux（Security-Enhanced Linux），是由
美國(guó)國(guó)家安全局
(NSA)發(fā)起, 多個(gè)
非營(yíng)利組織
和高校參與開(kāi)發(fā)的強(qiáng)制性安全審查機(jī)制（Mandatory Access control，簡(jiǎn)稱MAC）。SELinux最早于2023年12月采用GPL許可發(fā)布。目前，Linux Kernel 2.6 及以上的版本都已經(jīng)集成了SELinux。
SELinux 分成三種模式：
Android 5.x及以上強(qiáng)制開(kāi)啟，因此，disabled(關(guān)閉)模式并沒(méi)有什么用了。 通常在調(diào)試時(shí)，我們會(huì)啟用Permissve(寬容模式), 以便盡可能的發(fā)現(xiàn)多的問(wèn)題, 然后一次修正。 在量產(chǎn)時(shí)啟用Enfocing mode(強(qiáng)制模式)來(lái)保護(hù)系統(tǒng)。
查看SELinux模式：adb shell getenforce
設(shè)置SELinux模式：adb shell setenforce 1 //0是Permissve，1是Enfocing
SELinux 的訪問(wèn)控制示意圖：
通常我們開(kāi)發(fā)的過(guò)程中，就是配置Subject、Object、Security Policy。
SELinux 給Linux 的所有對(duì)象都分配一個(gè)安全上下文(Security Context)， 描述成一個(gè)標(biāo)準(zhǔn)的
字符串
。
安全上下文的標(biāo)準(zhǔn)格式：
user:role:type
Security Label 用來(lái)綁定被訪問(wèn)資源和安全上下文，描述它們的對(duì)應(yīng)關(guān)系。標(biāo)準(zhǔn)格式為：resource security_context。即：res user:role:type。這里也可以使用
通配符
，例如 net.就可以綁定所有以net.開(kāi)頭的屬性，除此之外，還有類似
正則表達(dá)式
的*、？等等通配符。Security Label 都定義在type_contexts當(dāng)中，例如file的定義在file_contexts中，service定義在service_contexts中，property定義在property_contexts中。
舉例：
file_contexts:
service_contexts:
查看進(jìn)程安全上下文：
ps -AZ
。例如，查看Settings進(jìn)程的安全上下文，ps -AZ | grep settings：
??u:r:system_app:s0 system S com.android.settings
查看文件安全上下文：
ls -Z
。例如，查看文件build.prop的安全上下文：
??u:object_r:system_file:s0 build.prop
Type Enforcement (TE) 是根據(jù)Security Context中的 type 進(jìn)行權(quán)限審查, 審查 subject type 對(duì) object type 的某個(gè)class 類型中某種permission 是否具有訪問(wèn)權(quán)限，是目前使用最為廣泛的MAC 審查機(jī)制, 簡(jiǎn)單易用。
TE控制語(yǔ)句格式 :
rule_name source_type target_type : class perm_set
Type Enforcement規(guī)則說(shuō)明：
舉個(gè)例子，logd.te、tombstoned.te中定義的TE規(guī)則：
??allow logd runtime_event_log_tags_file:file rw_file_perms;
??dontaudit domain runtime_event_log_tags_file:file { open read };
??auditallow tombstoned anr_data_file:file { append write };
??neverallow logd { app_data_file system_data_file }:dir_file_class_set write;
SELinux 中每一個(gè)進(jìn)程或者文件都對(duì)應(yīng)一個(gè)type, 而每一個(gè)type 都對(duì)應(yīng)有一個(gè)或幾個(gè)attribute。所有常見(jiàn)的attribute定義在以下文件中：
??system/sepolicy/public/attributes
??system/sepolicy/prebuilts/api//public/attributes
??system/sepolicy/prebuilts/api//private/attributes
其中的即為android
版本號(hào)
，例如android O為28.0。常見(jiàn)的attribute定義：
Type對(duì)應(yīng)一個(gè)或者幾個(gè)attribute，Type的定義格式：
??type type_name, attribute1, attribute2；
Type的定義通常分散在各個(gè)te文件中。例如，常用普通文件的type定義在file.te中：
SEAndroid對(duì)于不同的資源類型，定義了不同的Class。比如普通的file、socket等等，比如SELinux 使用的security, 比如針對(duì)每個(gè)process 參數(shù)的process 等定義相關(guān)的class。這些class，每一個(gè)class 都有相對(duì)應(yīng)的permissions。 比如file 就有 read, write, create, getattr, setattr, lock, ioctl 等等. 比如process 就有fork, sigchld, sigkill, ptrace, getpgid, setpgid 等等。這些相關(guān)的class, 以及他們具有那些Permissions都定義在以下文件中：
??system/sepolicy/private/access_vectors
??system/sepolicy/reqd_mask/access_vectors
??system/sepolicy/prebuilts/api/版本號(hào)/private/access_vectors
例如：
定義完之后，在以下對(duì)應(yīng)的security_classes 文件中聲明定義的classes。
??system/sepolicy/private/security_classes
??system/sepolicy/reqd_mask/security_classes
??system/sepolicy/prebuilts/api/版本號(hào)/private/security_classes
例如：
注意，Classes 和Permissions的定義與Kernel 中相關(guān)API是強(qiáng)相關(guān)的，普通用戶嚴(yán)禁修改。
在SELinux 中, 我們通常稱一個(gè)進(jìn)程是一個(gè)domain, 一個(gè)進(jìn)程fork 另外一個(gè)進(jìn)程并執(zhí)行(exec) 一個(gè)執(zhí)行檔時(shí), 我們往往會(huì)涉及到domain 的切換. 比如init 進(jìn)程, SELinux 給予了它很大的權(quán)限, 而它拉起的服務(wù), 我們要限制這個(gè)服務(wù)的權(quán)限，于是就涉及到從一個(gè)domain 切換到另外一個(gè)domain, 不然默認(rèn)就使用init 進(jìn)程的domain.
在SELinux 里面有專門的一條語(yǔ)法: type_transition statement.
在準(zhǔn)備切換前我們先要確保有相關(guān)的權(quán)限操作：
如下面的demo, init 拉起apache 并且切換到 apache 的domain.
(1). 首先，你得讓init_t域中的進(jìn)程能夠執(zhí)行type為apache_exec_t的文件
??allow init_t apache_exec_t : file {read getattr execute};
(2). 然后，你還得告訴SELinux，允許init_t做DT切換以進(jìn)入apache_t域
??allow init_t apache_t : process transition;
(3). 然后，你還得告訴SELinux，切換入口（對(duì)應(yīng)為entrypoint權(quán)限）為執(zhí)行apache_exec_t類型 的文件
??allow apache_t apache_exec_t : file entrypoint;
(4).最后，Domain Transition
??type_transition init_t apache_exec_t : process apache_t;
可以看到，整個(gè)domain切換過(guò)程寫起來(lái)非常麻煩。因此，Google 為了使用方便, 在system/sepolicy/public/te_macros 文件中定義了宏：
我們可以使用這些宏來(lái)完成domain切換。
舉例：
kernel啟動(dòng)init進(jìn)程切換domain:
??domain_auto_trans(kernel, init_exec, init)
init啟動(dòng)netd、vold、zygote、installd切換domain:
??init_daemon_domain(netd)
??init_daemon_domain(vold)
??init_daemon_domain(zygote)
??init_daemon_domain(installd)
一個(gè)進(jìn)程創(chuàng)建在一個(gè)目錄下創(chuàng)建文件時(shí), 默認(rèn)是沿用父目錄的Security Context, 如果要設(shè)置成特定的Label, 就必須進(jìn)行Object Transitions.
同樣是使用：type_transition statement.
對(duì)應(yīng)的必須有兩個(gè)前提條件:
下面是一個(gè)demo, ext_gateway_t 這個(gè)domain 在類型為in_queue_t 的目錄下，創(chuàng)建類型為 in_file_t 的文件.
(1). 首先，你得讓ext_gateway_t 對(duì)in_queue_t 目錄具備訪問(wèn)權(quán)限
??allow ext_gateway_t in_queue_t : dir { write search add_name };
(2). 然后，你還得告訴SELinux，允許ext_gateway_t 訪問(wèn)in_file_t的文件
??allow ext_gateway_t in_file_t : file { write create getattr };
(3).最后，Object Transition
??type_transition ext_gateway_t in_queue_t : file in_file_t;
同樣的，為了方便使用，Google 也在system/sepolicy/public/te_macros 文件中定義了宏:
使用舉例：
??file_type_auto_trans(factory, system_data_file, factory_data_file)
android O 以前sepolicy 集中放在boot image 。前面提到SELinux在Android的主要變更歷史時(shí)，有提到android O 開(kāi)始，Google將system image 和 vendor image 分離。因此，sepolicy 也相應(yīng)的被分離存放到system image 以及 vendor image。與system 相關(guān)的sepolicy 就存放system image, 與SoC vendor 相關(guān)的sepolicy 就存放在vendor image。
對(duì)于原生AOSP，Google 設(shè)定了不同的存放目錄, 以便進(jìn)行分離, 以Google 默認(rèn)的sepolicy 為例，sepolicy主目錄為 /system/sepolicy，我們主要關(guān)注三個(gè)子目錄：
對(duì)于不同的平臺(tái)，不同平臺(tái)廠商也設(shè)定了不同的存放目錄，以MTK平臺(tái)為例：
首先，根據(jù)不同的platform共用sepolicy、platform獨(dú)有、project獨(dú)有，分為：
對(duì)應(yīng)的，不同版本會(huì)導(dǎo)入不同目錄下的sepolicy配置
以mt6763平臺(tái)為例，導(dǎo)入時(shí)：
路徑為：/device/mediatek/sepolicy
路徑為：/device/mediatek/mt6763/sepolicy/
具體的定義在BoardConfig.mk文件中:
然后，basic、bsp、full又可以主要細(xì)分為：
Google 在system/sepolicy 中定義了相關(guān)的neverallow 規(guī)則, 對(duì)SELinux Policy 的更新進(jìn)行了限制, 以防止開(kāi)發(fā)者過(guò)度開(kāi)放權(quán)限，從而引發(fā)安全問(wèn)題。并且還會(huì)通過(guò)CTS測(cè)試檢測(cè)開(kāi)發(fā)者是否有違法相關(guān)的規(guī)則。
因此，我們需要注意以下幾點(diǎn)：
出現(xiàn)SELinux Policy Exception時(shí)常見(jiàn)的兩種解決方案：
(1). 修改對(duì)應(yīng)節(jié)點(diǎn)的SELinux Security Label, 為特定的Subject，如system_app、platform_app、priv_app，例如Settings，SystemUI等內(nèi)置APP開(kāi)啟權(quán)限, 但嚴(yán)禁為untrsted app 開(kāi)啟權(quán)限。
(2). 通過(guò)system server service 或者 init 啟動(dòng)的service 讀寫操作, 然后app 通過(guò)binder/socket 等方式連接訪問(wèn). 此類安全可靠, 并且可以在service 中做相關(guān)的安全審查, 推薦這種方法.
情景: 定義由 init 進(jìn)程啟動(dòng)的service, factory, 其對(duì)應(yīng)的執(zhí)行檔是 /vendor/bin/factory。
(1). 在device/mediatek/mt6763/sepolicy/basic/non_plat 目錄下創(chuàng)建一個(gè)factory.te , 然后將te文件加入編譯，如放到這種指定目錄下不需要額外配置，sytem/sepolicy/Android.mk中定義的build_policy函數(shù)會(huì)遍歷指定目錄導(dǎo)入te文件。
(2). 在factory.te 中定義factory類型，init 啟動(dòng)service 時(shí)類型轉(zhuǎn)換,
??type factory, domain;
??type factory_exec, exec_type, file_type, vendor_file_type;
??init_daemon_domain(factory)
(3). 在file_contexts中綁定執(zhí)行檔
??/(system/vendor|vendor)/bin/factory u:object_r:factory_exec:s0
(4). 根據(jù)factory需要訪問(wèn)的文件以及設(shè)備, 定義其它的權(quán)限在factory.te 中.
??#Purpose: For key and touch event
??allow factory input_device:chr_file r_file_perms;
??allow factory input_device:dir rw_dir_perms;
情景: 添加一個(gè)自定義的system property： persist.demo，并為platform_app設(shè)置讀寫權(quán)限
(1). 在property.te中定義system property類型
??type demo_prop, property_type
(2). 在property_contexts中綁定system property的安全上下文。
??persist.demo u:object_r:demo_prop:s0
(3). 在platform_app.te 中新增寫權(quán)限，可以使用set_prop宏。
??set_prop(platform_app, demo_prop)
(4). 在platform_app.te 中新增讀權(quán)限，可以get_prop 宏。
??get_prop(platform_app, demo_prop)
情景: 有一個(gè)設(shè)備節(jié)點(diǎn)/dev/demo，有一個(gè)platform_app進(jìn)程需要讀寫這個(gè)設(shè)備節(jié)點(diǎn)。
(1). 在device.te中定義device 類型
??type demo_device dev_type;
(2). 在 file_contexts中綁定demo_device
??/dev/demo u:object_r:demo_device:s0
(3). 在platform_app.te中，允許platform_app使用demo device 的權(quán)限
??allow platform_app demo_device:chr_file rw_file_perms;
情景: 有一個(gè)擴(kuò)展的系統(tǒng)服務(wù)demo_service供APP調(diào)用。
(1). 在service.te 中定義service 類型
??type demo_service, app_api_service, system_server_service, service_manager_type;
(2). 在service_contexts 中綁定service
??demo u:object_r:demo_service:s0
(3). 在frameworks/base/core/java/android/content/Context.java中定義服務(wù)常量
??public static final String DEMO_SERVICE = “demo”;
(4). 在frameworks/base/core/java/android/app/SystemServiceRegistry.java中，參照其它系統(tǒng)服務(wù)注冊(cè)demo_service
(5). 在frameworks/base/services/java/com/android/server/SystemServer.java中，啟動(dòng)DemoService，添加到service_manager進(jìn)行管理。
(6). 最后一步，參考其它系統(tǒng)服務(wù)，實(shí)現(xiàn)DemoManager、DemoService，并定義如IDemoService等等的AIDL接口。
情景: 一個(gè)native service 通過(guò)init 創(chuàng)建一個(gè)socket 并綁定在 /dev/socket/demo, 并且允許某些process 訪問(wèn).
(1). 在file.te中定義socket 的類型
??type demo_socket, file_type;
(2). 在file_contexts中綁定socket 的類型
??/dev/socket/demo_socket u:object_r:demo_socket:s0
(3). 允許所有的process 訪問(wèn)，使用宏unix_socket_connect(clientdomain, socket, serverdomain)
??unix_socket_connect(appdomain, demo, demo)
(1). 在device/mediatek/mt6763/sepolicy/basic/non_plat目錄下創(chuàng)建一個(gè)demo.te。
(2). 在demo.te 中定義demo 類型，init 啟動(dòng)service 時(shí)類型轉(zhuǎn)換。并可以根據(jù)demo 需要訪問(wèn)的文件以及設(shè)備, 定義其它的權(quán)限在demo.te 中。
??type demo, domain;
??type demo_exec, exec_type, file_type;
??init_daemon_domain(demo)
(3). 綁定執(zhí)行檔 file_context 類型
??/vendor/bin/demo u:object_r:demo_exec:s0
(4). 創(chuàng)建demo的入口執(zhí)行檔demo_exec、并配置相應(yīng)的權(quán)限。
(1). 將SELinux 調(diào)整到Permissive 模式復(fù)測(cè)
使用eng/userdebug 版本，adb shell setenforce 0 將SELinux 模式調(diào)整到Permissive 模式，然后復(fù)測(cè)。如果還能復(fù)現(xiàn)問(wèn)題，則與SELinux 無(wú)關(guān)； 如果原本很容易復(fù)現(xiàn), 而Permissive mode 不能再?gòu)?fù)現(xiàn), 那么就可能與SELinux相關(guān)。
(2). 查看LOG 中是否有標(biāo)準(zhǔn)的SELinux Policy Exception.
在Kernel LOG / Main Log 中查詢關(guān)鍵字 “avc: denied” 看看是否有與目標(biāo)進(jìn)程相關(guān)的SELinux Policy Exception, 并進(jìn)一步確認(rèn)這個(gè)異常是否與當(dāng)時(shí)的邏輯相關(guān)。
一般情況我們?cè)诜螱oogle sepolicy策略及neverallow策略的前提下，根據(jù)LOG中的內(nèi)容，需要什么權(quán)限就加什么權(quán)限。例如LOG：
14:11:02./com.android.systemui W/FaceIdThread: type=1400 audit(0.0:481): avc: denied { read } for name=”als_ps” dev=”tmpfs” ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0
LOG說(shuō)明如下：
一般我們需要重點(diǎn)關(guān)注的是四個(gè)：permission、source type、target type、target class
根據(jù)這四個(gè)就可以配置出的所需要的selinux權(quán)限：
??
allow :
例1：
:45:22.W Camera: type=1400 audit(0.0:314): avc: denied { read } for name=”u:object_r:graphics_debug_prop:s0″ dev=”tmpfs” ino=2649 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:graphics_debug_prop:s0 tclass=file permissive=0
解決方案：
按正常的套公式，應(yīng)該是這樣修改platform_app.te，增加：
??allow platform_app graphics_debug_prop:file r_file_perms;
這里我們利用system/sepolicy/te_macros中定義的宏get_prop：
更多相關(guān)的宏定義請(qǐng)參考：system/sepolicy/public/te_macros。
所以最終簡(jiǎn)化后，修改platform_app.te，增加：
??get_prop(platform_app, graphics_debug_prop)
例2：
:11:02./com.android.systemui W/BackThread: type=1400 audit(0.0:481): avc: denied { read } for name=”als_ps” dev=”tmpfs” ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0
解決方案：
修改platform_app.te增加：
??allow platform_app als_ps_device:chr_file r_file_perms;
(1). 不符合neverallow規(guī)則或者修改了neverallow規(guī)則
編譯報(bào)錯(cuò)：
??neverallow check failed at xxx
CTS測(cè)試項(xiàng)failed：
??android.cts.security.SELinuxNeverallowRulesTest#testNeverallowRulesXXX
這類問(wèn)題在android O vendor和system分離之后，尤其容易出現(xiàn)?；旧线@類問(wèn)題都是因?yàn)樾薷幕蛘咴黾拥膖e配置不符合neverallow規(guī)則，導(dǎo)致編譯報(bào)錯(cuò)。而為了解決編譯報(bào)錯(cuò)，又修改了neverallow規(guī)則，最終在跑CTS時(shí)，沒(méi)法通過(guò)相關(guān)的測(cè)試項(xiàng)。
解決思路：
(2). init進(jìn)程fork新進(jìn)程沒(méi)有做domain切換
CTS測(cè)試項(xiàng)failed：
??android.security.cts.SELinuxDomainTest # testInitDomain
解決思路：
fork進(jìn)程時(shí)，參考3.4節(jié)中做domain切換。
selinux策略編寫教程的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于selinux策略編寫教程,學(xué)習(xí)SELinux：如何編寫策略教程？,SELinux權(quán)限的信息別忘了在本站進(jìn)行查找喔。
香港服務(wù)器選創(chuàng)新互聯(lián)，2H2G首月10元開(kāi)通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）互聯(lián)網(wǎng)服務(wù)提供商,擁有超過(guò)10年的服務(wù)器租用、服務(wù)器托管、云服務(wù)器、虛擬主機(jī)、網(wǎng)站系統(tǒng)開(kāi)發(fā)經(jīng)驗(yàn)。專業(yè)提供云主機(jī)、虛擬主機(jī)、域名注冊(cè)、VPS主機(jī)、云服務(wù)器、香港云服務(wù)器、免備案服務(wù)器等。
新聞名稱：學(xué)習(xí)SELinux：如何編寫策略教程？(selinux策略編寫教程)
網(wǎng)頁(yè)URL：http://m.5511xx.com/article/dpgihgp.html
