se與linux

『壹』 什麼是selinux 為什麼使用 SE Linux

SELinux，Security Enhanced
Linux的縮寫，也就是安全念者強化的Linux，是由美國國家安全局聯合其他安全機構共同開發的，旨在增強傳統Linux操作系統的安全性，解決傳統Linux系統中自主仔握薯訪問控制系統中的各種權皮森限問題。

對於SELinux，初學者可以這么理解，它是部署在Linux上用於增強系統安全的功能模塊。

傳統的Linux系統安全，採用的是DAC，而SELinux是部署在Linux系統中的安全增強功能模塊，它通過對進程和文件資源採用MAC為Linux系統提供了改進的安全性。

SELinux的主要作用

①通過對進程和文件資源採用MAC控制方式，為Linux系統提供了改進的安全性。

②最大限度地減小系統中服務進程可訪問的資源。

它賦予了主體最小的訪問特權，這也就意味著，每個主體僅被賦予了完成相關任務所必須的一組有限的許可權。通過賦予最小訪問特權，可以防止主體對其他用戶或進程產生不利的影響。

③SELinux管理過程中，每個進程都有自己的運行區域，各進程僅運行在自己的域內，無法訪問其他進程和文件，除非被授予了特殊許可權。

④SELinux能最大程序上限制Linux系統中的惡意代碼活動。

『貳』 SELinux許可權

在了解SELinux之前，我們先來了解一下Linux的兩種訪問控制策略：DAC和MAC

DAC，自主訪問控制（Discretionary Access control）。系統只提供基本的驗證, 完整的訪問控制由開發者自己控制。
 DAC將資源訪問者分成三類：Owner、Group、Other 。
 將訪問許可權也分成三類：read、write、execute
資源針對資源訪問者設置不同的訪問許可權。訪問者通常是各個用戶的進程，有自己的uid/gid，通過uid/gid 和文件許可權匹配, 來確定是否可以訪問。DAC機制下，每一個用戶進程默認都擁有該用戶的所有許可權。
DAC 有兩個嚴重問題：
 問題一：
 因為Root用戶是擁有所有許可權的，所以DAC對Root用戶的限制是無效的。並且在Linux Kernel 2.1以後，Linux將Root許可權根據不同的應用場景劃分成許多的Root Capabilities, 普通用戶也可以被設置某個Root Capability。普通用戶如果被設置了CAP_DAC_OVERRIDE， 也可以繞過 DAC 限制。
 問題二：
 用戶進程擁有該用戶的所有許可權，可以修改/刪除該用戶的所有文件資源, 難以防止惡意軟體。

可見，DAC 有明顯的缺陷，一旦被入侵，取得Root許可權的用戶進程就可以無法無天，胡作非前滲行為，早期android版本就深受其害。

MAC， 強制性訪問控制（Mandatory Access control）。 系統針對每一項訪問都進行嚴格的限制, 具體的限制策略由開發者給出。

Linux MAC 針對DAC 的不足, 要求系統對每一項訪問, 每訪問一個文件資源都需要根據已經定義好了的策略進行針對性的驗證。系統可以針對特定的進程與特定的文件資源來進行許可權的控制。即使是root用戶，它所屬的不同的進程，並不一定能取得root許可權，而得要看事先為該進程定義的訪問限制策略。如果不能通過MAC 驗證，一樣無法執行相關的操作。

與DAC相比，MAC訪問控制的「主體」變成了「進程」而不是用戶。這樣可以限制了Root 許可權的濫用，另外要求對每一項許可權進行了更加完整的細化, 可以限制用戶對資源的訪問行為。

SELinux就是目前最好的MAC機制，也是目前的行業標准。

SELinux，安全增強Linux（Security-Enhanced Linux），是由美國國家安全局(NSA)發起, 多個非營利組織和高校參與開發的強制性安全審查機制（Mandatory Access control，簡稱MAC）。SELinux最早於2000年12月採用GPL許可發布。目前慧嘩，Linux Kernel 2.6 及以上的版本都已經集成了SELinux。

SELinux 分成三種模式：

Android 5.x及以上強制開啟，因此，disabled(關閉)模式並沒有什麼用了。 通常在調試時，我們會啟用Permissve(寬容模式), 以便盡可能的發現多的問題, 然後一次喊雀修正。 在量產時啟用Enfocing mode(強制模式)來保護系統。

查看SELinux模式：adb shell getenforce
設置SELinux模式：adb shell setenforce 1 //0是Permissve，1是Enfocing

SELinux 的訪問控制示意圖：

通常我們開發的過程中，就是配置Subject、Object、Security Policy。

SELinux 給Linux 的所有對象都分配一個安全上下文(Security Context)， 描述成一個標準的字元串。

安全上下文的標准格式： user:role:type[:range]

Security Label 用來綁定被訪問資源和安全上下文，描述它們的對應關系。標准格式為：resource security_context。即：res user:role:type[:range]。這里也可以使用通配符，例如 net.就可以綁定所有以net.開頭的屬性，除此之外，還有類似正則表達式的*、？等等通配符。Security Label 都定義在type_contexts當中，例如file的定義在file_contexts中，service定義在service_contexts中，property定義在property_contexts中。
舉例：
file_contexts:

service_contexts:

查看進程安全上下文： ps -AZ 。例如，查看Settings進程的安全上下文，ps -AZ | grep settings：
  u:r:system_app:s0 system 1381 585 4234504 201072 0 0 S com.android.settings
查看文件安全上下文： ls -Z 。例如，查看文件build.prop的安全上下文：
  u:object_r:system_file:s0 build.prop

Type Enforcement (TE) 是根據Security Context中的 type 進行許可權審查, 審查 subject type 對 object type 的某個class 類型中某種permission 是否具有訪問許可權，是目前使用最為廣泛的MAC 審查機制, 簡單易用。

TE控制語句格式 : rule_name source_type target_type : class perm_set

Type Enforcement規則說明：

舉個例子，logd.te、tombstoned.te中定義的TE規則：
  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 中每一個進程或者文件都對應一個type, 而每一個type 都對應有一個或幾個attribute。所有常見的attribute定義在以下文件中：
  system/sepolicy/public/attributes
  system/sepolicy/prebuilts/api/[build version]/public/attributes
  system/sepolicy/prebuilts/api/[build version]/private/attributes
其中的[build version]即為android版本號，例如android O為28.0。常見的attribute定義：

Type對應一個或者幾個attribute，Type的定義格式：
  type type_name, attribute1, attribute2；
Type的定義通常分散在各個te文件中。例如，常用普通文件的type定義在file.te中：

SEAndroid對於不同的資源類型，定義了不同的Class。比如普通的file、socket等等，比如SELinux 使用的security, 比如針對每個process 參數的process 等定義相關的class。這些class，每一個class 都有相對應的permissions。 比如file 就有 read, write, create, getattr, setattr, lock, ioctl 等等. 比如process 就有fork, sigchld, sigkill, ptrace, getpgid, setpgid 等等。這些相關的class, 以及他們具有那些Permissions都定義在以下文件中：
  system/sepolicy/private/access_vectors
  system/sepolicy/reqd_mask/access_vectors
  system/sepolicy/prebuilts/api/版本號/private/access_vectors
例如：

定義完之後，在以下對應的security_classes 文件中聲明定義的classes。
  system/sepolicy/private/security_classes
  system/sepolicy/reqd_mask/security_classes
  system/sepolicy/prebuilts/api/版本號/private/security_classes
例如：

注意，Classes 和Permissions的定義與Kernel 中相關API是強相關的，普通用戶嚴禁修改。

在SELinux 中, 我們通常稱一個進程是一個domain, 一個進程fork 另外一個進程並執行(exec) 一個執行檔時, 我們往往會涉及到domain 的切換. 比如init 進程, SELinux 給予了它很大的許可權, 而它拉起的服務, 我們要限制這個服務的許可權，於是就涉及到從一個domain 切換到另外一個domain, 不然默認就使用init 進程的domain.

在SELinux 裡面有專門的一條語法: type_transition statement.
在准備切換前我們先要確保有相關的許可權操作：

如下面的demo, init 拉起apache 並且切換到 apache 的domain.
(1). 首先，你得讓init_t域中的進程能夠執行type為apache_exec_t的文件
  allow init_t apache_exec_t : file {read getattr execute};
(2). 然後，你還得告訴SELinux，允許init_t做DT切換以進入apache_t域
  allow init_t apache_t : process transition;
(3). 然後，你還得告訴SELinux，切換入口（對應為entrypoint許可權）為執行apache_exec_t類型 的文件
  allow apache_t apache_exec_t : file entrypoint;
(4).最後，Domain Transition
  type_transition init_t apache_exec_t : process apache_t;

可以看到，整個domain切換過程寫起來非常麻煩。因此，Google 為了使用方便, 在system/sepolicy/public/te_macros 文件中定義了宏：

我們可以使用這些宏來完成domain切換。

舉例：
kernel啟動init進程切換domain:
  domain_auto_trans(kernel, init_exec, init)
init啟動netd、vold、zygote、installd切換domain:
  init_daemon_domain(netd)
  init_daemon_domain(vold)
  init_daemon_domain(zygote)
  init_daemon_domain(installd)

一個進程創建在一個目錄下創建文件時, 默認是沿用父目錄的Security Context, 如果要設置成特定的Label, 就必須進行Object Transitions.
同樣是使用：type_transition statement.
對應的必須有兩個前提條件:

下面是一個demo, ext_gateway_t 這個domain 在類型為in_queue_t 的目錄下，創建類型為 in_file_t 的文件.

(1). 首先，你得讓ext_gateway_t 對in_queue_t 目錄具備訪問許可權
  allow ext_gateway_t in_queue_t : dir { write search add_name };
(2). 然後，你還得告訴SELinux，允許ext_gateway_t 訪問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的主要變更歷史時，有提到android O 開始，Google將system image 和 vendor image 分離。因此，sepolicy 也相應的被分離存放到system image 以及 vendor image。與system 相關的sepolicy 就存放system image, 與SoC vendor 相關的sepolicy 就存放在vendor image。

對於原生AOSP，Google 設定了不同的存放目錄, 以便進行分離, 以Google 默認的sepolicy 為例，sepolicy主目錄為 /system/sepolicy，我們主要關注三個子目錄：

對於不同的平台，不同平台廠商也設定了不同的存放目錄，以MTK平台為例：
首先，根據不同的platform共用sepolicy、platform獨有、project獨有，分為：

對應的，不同版本會導入不同目錄下的sepolicy配置

以mt6763平台為例，導入時：
[common] 路徑為：/device/mediatek/sepolicy
[platfrom] 路徑為：/device/mediatek/mt6763/sepolicy/
具體的定義在BoardConfig.mk文件中:

然後，basic、bsp、full又可以主要細分為：

Google 在system/sepolicy 中定義了相關的neverallow 規則, 對SELinux Policy 的更新進行了限制, 以防止開發者過度開放許可權，從而引發安全問題。並且還會通過CTS測試檢測開發者是否有違法相關的規則。

因此，我們需要注意以下幾點：

出現SELinux Policy Exception時常見的兩種解決方案：

(1). 修改對應節點的SELinux Security Label, 為特定的Subject，如system_app、platform_app、priv_app，例如Settings，SystemUI等內置APP開啟許可權, 但嚴禁為untrsted app 開啟許可權。
(2). 通過system server service 或者 init 啟動的service 讀寫操作, 然後app 通過binder/socket 等方式連接訪問. 此類安全可靠, 並且可以在service 中做相關的安全審查, 推薦這種方法.

情景: 定義由 init 進程啟動的service, factory, 其對應的執行檔是 /vendor/bin/factory。

(1). 在device/mediatek/mt6763/sepolicy/basic/non_plat 目錄下創建一個factory.te , 然後將te文件加入編譯，如放到這種指定目錄下不需要額外配置，sytem/sepolicy/Android.mk中定義的build_policy函數會遍歷指定目錄導入te文件。

(2). 在factory.te 中定義factory類型，init 啟動service 時類型轉換,
  type factory, domain;
  type factory_exec, exec_type, file_type, vendor_file_type;
  init_daemon_domain(factory)

(3). 在file_contexts中綁定執行檔
  /(system/vendor|vendor)/bin/factory u:object_r:factory_exec:s0

(4). 根據factory需要訪問的文件以及設備, 定義其它的許可權在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;

情景: 添加一個自定義的system property： persist.demo，並為platform_app設置讀寫許可權

(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 中新增寫許可權，可以使用set_prop宏。
  set_prop(platform_app, demo_prop)

(4). 在platform_app.te 中新增讀許可權，可以get_prop 宏。
  get_prop(platform_app, demo_prop)

情景: 有一個設備節點/dev/demo，有一個platform_app進程需要讀寫這個設備節點。

(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 的許可權
  allow platform_app demo_device:chr_file rw_file_perms;

情景: 有一個擴展的系統服務demo_service供APP調用。

(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中定義服務常量
  public static final String DEMO_SERVICE = "demo";

(4). 在frameworks/base/core/java/android/app/SystemServiceRegistry.java中，參照其它系統服務注冊demo_service

(5). 在frameworks/base/services/java/com/android/server/SystemServer.java中，啟動DemoService，添加到service_manager進行管理。

(6). 最後一步，參考其它系統服務，實現DemoManager、DemoService，並定義如IDemoService等等的AIDL介面。

情景: 一個native service 通過init 創建一個socket 並綁定在 /dev/socket/demo, 並且允許某些process 訪問.

(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 訪問，使用宏unix_socket_connect(clientdomain, socket, serverdomain)
  unix_socket_connect(appdomain, demo, demo)

(1). 在device/mediatek/mt6763/sepolicy/basic/non_plat目錄下創建一個demo.te。

(2). 在demo.te 中定義demo 類型，init 啟動service 時類型轉換。並可以根據demo 需要訪問的文件以及設備, 定義其它的許可權在demo.te 中。
  type demo, domain;
  type demo_exec, exec_type, file_type;
  init_daemon_domain(demo)

(3). 綁定執行檔 file_context 類型
  /vendor/bin/demo u:object_r:demo_exec:s0

(4). 創建demo的入口執行檔demo_exec、並配置相應的許可權。

(1). 將SELinux 調整到Permissive 模式復測
使用eng/userdebug 版本，adb shell setenforce 0 將SELinux 模式調整到Permissive 模式，然後復測。如果還能復現問題，則與SELinux 無關； 如果原本很容易復現, 而Permissive mode 不能再復現, 那麼就可能與SELinux相關。

(2). 查看LOG 中是否有標準的SELinux Policy Exception.
在Kernel LOG / Main Log 中查詢關鍵字 "avc: denied" 看看是否有與目標進程相關的SELinux Policy Exception, 並進一步確認這個異常是否與當時的邏輯相關。

一般情況我們在符合Google sepolicy策略及neverallow策略的前提下，根據LOG中的內容，需要什麼許可權就加什麼許可權。例如LOG：
2020-03-27 14:11:02.596 1228-1228/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說明如下：

一般我們需要重點關注的是四個：permission、source type、target type、target class

根據這四個就可以配置出的所需要的selinux許可權：
   allow [source type] [target type]: [target class] [permission]
例1：
03-27 03:45:22.632 2958 2958 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

解決方案：
按正常的套公式，應該是這樣修改platform_app.te，增加：
  allow platform_app graphics_debug_prop:file r_file_perms;
這里我們利用system/sepolicy/te_macros中定義的宏get_prop：

更多相關的宏定義請參考：system/sepolicy/public/te_macros。
所以最終簡化後，修改platform_app.te，增加：
  get_prop(platform_app, graphics_debug_prop)

例2：
03-27 14:11:02.596 1228-1228/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規則或者修改了neverallow規則
編譯報錯：
  neverallow check failed at xxx
CTS測試項failed：
  android.cts.security.SELinuxNeverallowRulesTest#testNeverallowRulesXXX
這類問題在android O vendor和system分離之後，尤其容易出現。基本上這類問題都是因為修改或者增加的te配置不符合neverallow規則，導致編譯報錯。而為了解決編譯報錯，又修改了neverallow規則，最終在跑CTS時，沒法通過相關的測試項。

解決思路：

(2). init進程fork新進程沒有做domain切換
CTS測試項failed：
  android.security.cts.SELinuxDomainTest # testInitDomain

解決思路：
fork進程時，參考3.4節中做domain切換。

本文主要參考了MTK-Online的Quick-start中《SELinux 問題快速分析》的內容，感謝原作者們的辛勤付出。另外，結合源碼和自身開發實踐，增加了一些自身理解和實踐內容。

『叄』 linux 為什麼要關閉selinux

一般安裝linux課程時都把SELinux與iptables安排在後面，使初學者配置linux伺服器時不成功，卻沒有頭緒，那是因為在RedHat linux操作系統中默認開啟了防火牆，SELinux也處於啟動狀態，一般狀態為enforing。致使很多服務埠默認是關閉的。

所以好多服務初學者明明配置文件正確，等驗證時有時連ping也ping不通。建議初學者在未學到SELlinux與iptables之前，配置伺服器把這兩項都關掉。

(3)se與linux擴展閱讀

SELinux 的作用及許可權管理機制：

SELinux 主要作用就是最大限度地減小系統中服務進程可訪問的資源（最小許可權原則）。

SELinux 有三種工作模式，分別是：

1、enforcing：強制模式。違反 SELinux 規則的行為將被阻止並記錄到日誌中。

2、permissive：寬容模式。違反 SELinux 規則的行為只會記錄到日誌中。一般為調試用。

3、disabled：關閉 SELinux。

SELinux 工作模式可以在 /etc/selinux/config 中設定。

如果想從 disabled 切換到 enforcing 或者 permissive 的話，需要重啟系統。反過來也一樣。

enforcing 和 permissive 模式可以通過 setenforce 1|0 命令快速切換。

需要注意的是，如果系統已經在關閉 SELinux 的狀態下運行了一段時間，在打開 SELinux 之後的第一次重啟速度可能會比較慢。因為系統必須為磁碟中的文件創建安全上下文。

SELinux 日誌的記錄需要藉助 auditd.service 這個服務，請不要禁用它。

『肆』 linux之selinux

一、SELinux三種模式簡緩祥介

二、getenforce命令

功能：查看當前SELinux的運行模式

三、sestatus命令

功能：查看當前系統上面SELinux的策略，運行模遲哪搏式等信息

命令格式：

sestatus [-vb]

相關參數與選項：

-v：檢查列於/etc/sestatus.conf內的文件御錦城的安全上下文

-b：將目前策略的規則布爾值列出，亦即某些規則是否要啟動（0/1）之意

四、SELinux的配置文件（/etc/selinux/config）

SELINUX=enforcing：當前SELinux的模式

SELINUXTYPE=targeted：當前SELinux的策略

如果想要修改策略和模式，就更改這個文件裡面的內容即可

五、SELinux模式的更改（setenforce命令）

SELinux模式的更改規則：

setenforce命令格式：

# 轉換為Permissive寬容模式 setenforce 0

# 轉換為Enforcing強制模碼祥式 setenforce 1

注意事項：setenforce無法設置SELinux為Disabled模式

六、restorecon -Rv 命令

介紹：

當你從Disabled切換為Enforcing模式時，會有一堆服務無法順利啟動，會跟你說/lib/xxx裡面的數據沒有許可權讀取，所以啟動失敗。原因：大多是重新寫入SELinux類型時出錯的緣故

解決辦法：

切換為Permissive寬容模式，然後使用restorecon -Rv / 重新還原所有SELinux的類型，就能解決這個問題