android中SELINUX規則分析和語法簡介

 

 1. SELINUX是可以理解為一種android上面的安全機制，是有美國國家安全局和一些公司設計的一個針對linux的安全加強系統
我們可以通過配置SELINUX的相關policy，來定制自己的手機的一些權限，比如，我們可以完全讓root用戶沒有任何的權限和user一樣
2. 在android裡面，有兩個類型，一種是文件，一種是進程。
針對這兩種類型，我們可以先來看看他們的不同。
在android上面，adb shell之後進入手機，ps -Z可以查看當前進程所擁有的selinux的權限。

舉例：

LABEL                          USER     PID   PPID  NAME
u:r:init:s0                    root      1     0     /init
u:r:kernel:s0                  root      2     0     kthreadd
...
u:r:kernel:s0                  root      258   2     irq/322-HPH_R O
u:r:logd:s0                    logd      259   1     /system/bin/logd
u:r:healthd:s0                 root      260   1     /sbin/healthd
u:r:lmkd:s0                    root      261   1     /system/bin/lmkd
u:r:servicemanager:s0          system    262   1     /system/bin/servicemanager
u:r:vold:s0                    root      263   1     /system/bin/vold
u:r:surfaceflinger:s0          system    264   1     /system/bin/surfaceflinger
u:r:tctd:s0                    root      265   1     /system/bin/tctd
u:r:rfs_access:s0              system    268   1     /system/bin/rfs_access
u:r:tee:s0                     system    271   1     /system/bin/qseecomd
u:r:kernel:s0                  root      280   2     kworker/3:1H
u:r:kernel:s0                  root      290   2     kauditd
u:r:rmt_storage:s0             nobody    291   1     /system/bin/rmt_storage
u:r:shell:s0                   shell     292   1     /system/bin/sh
u:r:netd:s0                    root      295   1     /system/bin/netd
u:r:debuggerd:s0               root      296   1     /system/bin/debuggerd
u:r:tee:s0                     system    297   271   /system/bin/qseecomd

在這個例子中，我們可以進行分析。
在android中，只定義了一個user即為u. 另外，如果是進程的話，都會統一定義為r，如果是文件的話，會被定義為object_r. 第三個是這個進程type，在andorid裡面，定義了100多個type.按照目前我的理解，這個是進程所屬的>類型。第四個是s0，這個是一個安全的等級。但是暫時還沒有接觸到配置這個的地方。

另外就是文件，文件想要查看相關SELINUX權限的話，需要去執行ls -Z

drwxr-x--x root     sdcard_r          u:object_r:rootfs:s0 storage
drwx--x--x root     root              u:object_r:tmpfs:s0 synthesis
dr-xr-xr-x root     root              u:object_r:sysfs:s0 sys
drwxr-xr-x root     root              u:object_r:system_file:s0 system
drwxrwxr-x system   tctpersist          u:object_r:tct_persist_file:s0 tctpersist
lrwxrwxrwx root     root              u:object_r:rootfs:s0 tombstones -> /data/tombstones
-rw-r--r-- root     root              u:object_r:rootfs:s0 ueventd.qcom.rc
-rw-r--r-- root     root              u:object_r:rootfs:s0 ueventd.rc

在這個例子中，結合上面的分析，我們知道了object_r是代表的文件，u是android的唯一的用戶，rootfs是這個文件所對應的類型，s0是一個安全的等級限制。

3. 如何配置selinux
首先，按照Google的官方文檔：
需要linux內核首先是支持selinux的，另外需要android的selinux的配置文件，也就是extern/sepolicy裡面的內容。
然後就是修改BoardConfig.mk
Google的nexus的sepolicy的支持就放在了device/lge/mako/sepolicy
首先會包含廠商定制的sepolicy的文件夾：BOARD_SEPOLICY_DIRS
然後將規則添加到了sepolicy中：BOARD_SEPOLICY_DIRS

這樣的話，我們編譯出來的image其實就是具有了selinux的功能。
其實如果沒有廠商定制的話，也是會編譯到external/sepolicy的，這樣的話，就是使用andriod所有默認的sepolicy（It defines the domains and types for the AOSP services and apps common to all devices. ）

然後理解了這個之後，我們可以看到其實很多的廠商也是有自己的配置規則在device/***/***/sepolicy下面的.

 

4. selinux的配置規則：
首先要了解sepolicy的結構：
a. App進程 -> mac_permissions.xml
b. App數據文件 -> seapp_contexts
c. 系統文件 -> file_contexts
d. 系統屬性 -> property_contexts

在te文件中，我們一般遇到的語法是這樣的：
rule_name source_type target_type:class perm_set
解讀為： 為source_type設置一個rule_name的規則，規則是對target_type的class 進行 perm_set的操作。

然後是一些特殊的配置文件：
a. external/sepolicy/attributes -> 所有定義的attributes都在這個文件
b. external/sepolicy/access_vectors -> 對應了每一個class可以被允許執行的命令
c. external/sepolicy/roles -> Android中只定義了一個role，名字就是r，將r和attribute domain關聯起來
d. external/sepolicy/users -> 其實是將user與roles進行了關聯，設置了user的安全級別，s0為最低級是默認的級別，mls_systemHigh是最高的級別
e. external/sepolicy/security_classes -> 指的是上文命令中的class，個人認為這個class的內容是指在android運行過程中，程序或者系統可能用到的操作的模塊
f. external/sepolicy/te_macros -> 系統定義的宏全在te_macros文件
g. external/sepolicy/***.te -> 一些配置的文件，包含了各種運行的規則

另外，selinux有兩種工作模式：
“permissive”：所有操作都被允許（即沒有MAC），但是如果有違反權限的話，會記錄日志
“enforcing”：所有操作都會進行權限檢查

最後，type的命令如下：
type type_id [alias alias_id,] [attribute_id] # 將type_id（別名為alias）關聯到attribute. 這樣的話，方便用attribute來管理不同的type中包含相同的屬性的部分。

class命令的格式為：
class class_name [ inherits common_name ] { permission_name ... }
inherits表示繼承了common定義的權限，然後自己額外實現了permission_name的權限

在te文件中常見的四種命名的規則：
allow：賦予某項權限。
allowaudit：audit含義就是記錄某項操作。默認情況下是SELinux只記錄那些權限檢查失敗的操作。allowaudit則使得權限檢查成功的操作也被記錄。注意，allowaudit只是允許記錄，它和賦予權限沒關系。賦予權限必須且只能使
用allow語句。
dontaudit：對那些權限檢查失敗的操作不做記錄。
neverallow：前面講過，用來檢查安全策略文件中是否有違反該項規則的allow語句。如例子5所示：

舉例：

type init, domain;

將init關聯到domain，即將domain設置為init類型的屬性

allow init unlabeled:filesystem mount;

允許init類型對unlabeled類型的filesystem進行mount的操作

allow init fotad:unix_stream_socket { bind create };

允許init類型對fotad類型的unix_stream_socket 進行bind和create的操作

allow appdomain anr_data_file:dir search;
allow appdomain anr_data_file:file { open append };

首先appdomain是定義在te_macros裡面的一個宏，很多的app規則會使用類似app_domain(shell)的命令將其添加進去
這兩句話的意思是：1. 允許app去對anr_data_file類型的目錄進行查找的操作
2. 允許app對anr_data_file類型的file進行打開和添加操作 其實就是規定了出現anr時候，app往/data/anr/裡面寫入的權限限制

 

 

   neverallow { appdomain -unconfineddomain } kmem_device:chr_file { read write };

 

絕對不允許app(除了有unconfineddomain屬性的app)對kmem_device類型的字符設備進行讀寫的操作

   neverallow { appdomain -unconfineddomain } self:capability2 *;

絕對不允許除了unconfineddomain以外的app對self類型的capability2進行任何的操作

   type httpd_user_content_t, file_type, httpdcontent;

聲明一個httpd_user_content_t的類型，具有file_type和httpdcontent的屬性

   type httpd_user_content_t;
   typeattribute httpd_user_content_t file_type, httpdcontent;

聲明一個httpd_user_content_t的類型
定義httpd_user_content_t具有file_type, httpdcontent的屬性

   allow appdomain self:rawip_socket create_socket_perms;

所有可以設置類型的地方其實都可以設置為屬性。
比如這個例子，我們允許所有具有app屬性的內容可以去對self屬性的rawip_socket進行create的操作

allow {user_t domain} {bin_t file_type sbin_t}:file execute ;

允許user_t和domain屬性的類對bin_t, file_type, sbin_t類型的file進行可執行的操作

   allow user_t user_t:process signal;
   allow user_t self:process signal;

這兩條語句的表述其實是一致的，其實self指的是目標的類型和發起人的類型是一致的
所以不能聲明一個類型或者屬性叫做self

allow user_t bin_t:file ~{ write setattr ioctl };

允許user_t對bin_t類型的file進行除了write setattr ioctl相關的操作

type_transition system wifi_data_file:sock_file system_wpa_socket;

當一個類型為system的類別去進行wifi_data_file類型的sock_file訪問時，類型默認切換到system_wpa_socket

如果下面這條語句想要執行成功
type_transition init_t apache_exec_t:process apache_t;
至少首先聲明下面的三條規則：
allow init_t apache_exec_t:file execute;
allow init_t apache_t:process transition;
allow apache_t apache_exec_t:file entrypoint;

type_transition和type_change的語法規則是一樣的， type_change規則的影響不會在內核中生效，而是依賴於用戶空間應用程序，如login或sshd