security context
/*
When SEAndroid is enabled, the following occurs:
a, All objects on the system are labeled with a security context.Objects inlcude files,
directoried,processes,sockets,drivers,and more.
b, A security context consists of a user, role, type identifier, and optional sensitivity, separated with colons;
for example,
user:role:type:sensitivity.
user is unrelated to a Linux user, and type is unrelated to what kind of object it is.
A set of valid users, roles, and types is defined in the policy.
c, Different objects can be labeled with the same security context.
d, The MAC mechanism of SEAndroid is called type enforcement.
e, Uses the type field of a security context; the other filds are not as important.
*/- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
如上，系統中的所有對象都被打上了一個security context的標籤，這些對象包括文件，目錄，進程，socket,drivers等等。而security context中最重要的是第三列的type。
下面看下這個type到底是如何使用的。
policy rule
/*
The policy rules come in the form:
allow source-type destination-type:classes permissions ,
where:
source-type(Domain) - A label for the process or set of processes. Also called a domain type as it is just a type for a process.
destination-type - A label for the object (e.g. file, socket) or set of objects.
Class - The kind of object (e.g. file, socket) being accessed.
Permission - The operation (e.g. read, write) being performed.
*/- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
And so an example use of this would follow the structure:
allow appdomain app_data_file:file rw_file_perms;
This says that all application domains are allowed to read and write files labeled app_data_file. Note that this rule relies upon macros defined in the global_macros file, and other helpful macros can also be found in the te_macros file, both of which can be found in the external/sepolicy directory in the AOSP source tree. Macros are provided for common groupings of classes, permissions and rules, and should be used whenever possible to help reduce the likelihood of failures due to denials on related permissions.
通過denied log添加policy rule
例如下面一個denied log，
type=1400 audit(0.0:7): avc: denied { open } for path=”/system/bin/sh” dev=”mmcblk0p23” ino=724 scontext=u:r:system_server:s0tcontext=u:object_r:shell_exec:s0 tclass=file permissive=0
注意上面log中加深的部分，分別對應：
a, source-type, scontext=u:r:system_server:s0中的第三列，即system_server。
b, destination-type, tcontext=u:object_r:shell_exec:s0中的第三列，即shell_exec。
c, Class,tclass=file，即爲file。
d, Permission,{ open }，即爲open。
所以需要添加的policy rule爲，
allow system_server shell_exec:file open
上述命令表示允許打着system_server 標籤的domain，即進程去open打着shell_exec標籤的文件。上面例子是在security context 已經定義的情況下，根據denied log添加policy rule的過程，下面以新建一個led燈的讀寫權限爲例，允許system_app去讀寫這個led燈（當然system_app的security context系統早就定義好了）。
1.定義新的一個type
type sysfs_button_backlight, sysfs_type, fs_type;- 1
- 1
這個type的名字爲sysfs_button_backlight，爲sysfs類型。
2.定義sys文件的security context
/sys/class/leds/button-backlight/brightness u:object_r:sysfs_button_backlight:s0- 1
- 1
定義led燈sys文件系統中節點的security context。有了security context，domain就能訪問了。
3.添加system_app對led的讀寫權限
allow system_app sysfs_button_backlight:file rw_file_perms;- 1
- 1
允許system_app這個domain，進程，去讀寫label爲sysfs_button_backlight的文件。
