seandroid 如何添加被denied的权限

---

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.*/

如上，系统中的所有对象都被打上了一个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.    */

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:s0 tcontext=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;

这个type的名字为sysfs_button_backlight，为sysfs类型。

2.定义sys文件的security context

/sys/class/leds/button-backlight/brightness                              u:object_r:sysfs_button_backlight:s0

定义led灯sys文件系统中节点的security context。有了security context，domain就能访问了。

3.添加system_app对led的读写权限

allow system_app sysfs_button_backlight:file rw_file_perms;

允许system_app这个domain，进程，去读写label为sysfs_button_backlight的文件。