Selinux Rule

DAC和MAC

SELinux出现之前，Linux上的安全模型叫DAC，全称是Discretionary Access Control，翻译为自主访问控制。DAC的核心思想很简单，就是：进程理论上所拥有的权限与执行它的用户的权限相同。比如，以root用户启动Browser，那么Browser就有root用户的权限，在Linux系统上能干任何事情；

MAC（Mandatory Access Control），强制访问控制，即任何进程想在SELinux系统中干任何事情，都必须先在安全策略配置文件中赋予权限。凡是没有出现在安全策略配置文件中的权限，进程就没有该权限；
e.g: allow netd sysfs:file write;

DAC：

1.自主访问控制
2.主体（Process）的权限Capability决定了它能访问和操作什么ROOT进程可以访问和操作一切！
3.传统（legacy）Linux的安全模式，基于UID/GID/Capability

MAC：

1.强制访问控制
2.系统的Policy决定了主体能操作访问哪些客体
3.即便是ROOT进程，系统Policy配置了你能做什么，你只能做什么，在下MAC模式，ROOT进程和普通进程是无区别对待的。

Selinux Code:

system/sepolicy

查看Selinux

adb shell getenforce
Enforcing

•enforcing：强制模式，代表 SELinux 运作中，且已经正确的开始限制 domain/type 了；
•permissive：宽容模式：代表 SELinux 运作中，不过仅会有警告讯息并不会实际限制 domain/type
的存取。这种模式可以运来作为 SELinux 的 debug 之用； •disabled：关闭，SELinux 并没有实际运作。

关闭Selinux

setenforce [enforcing,permissive,1,0]

关掉Selinux, 查看问题是否和Selinux相关

device/qcom/xxx/BoardConfig.mk
BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive

常见错误修改

• ServiceManager add_service SELinux Permission Denied

E SELinux : avc: denied { add } for service={com.zhidao.services.radio.ZDRadioService} scontext=u:r:system_server:s0 tcontext=u:object_r:default_android_service:s0 tclass=service_manager

device/qcom/sepolicy/common/service.te
type car_service, system_api_service, system_server_service, service_manager_type;

device/qcom/sepolicy/common/service_contexts
com.zhidao.services.radio.ZDRadioService u:object_r:car_service_service:s0

如果是system_app需要add权限，需要如下操作：

device/qcom/sepolicy/common/system_app.te
allow system_app {
atfwd_service
atfwd_quec_service dun_service
# access to color service SDK
color_service
car_service //添加此权限
}:service_manager add;

• write SELinux Permission Denied

avc:denied { write } for pid=2646 comm=“gfslog” name="/" dev=“mmcblk0p21” ino=2 scontext=u:r:gfslog:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0

一般按照规则 allow scontex tcontex:tclass action 来改即可

allow gfslog system_data_file:dir write

安全上下文

由四部分内容组成：SELinux用户、SELinux角色、类型、安全级别
格式为“user:role:type:sensitivity”

文件init.rc的安全上下文类似如下：（ $ls -Z /init.rc）

-rwxr-x— root root u:object_r:rootfs:s0 init.rc

进程init的安全上下文类似如下：（$ps -Z）

LABEL USER PID PPID NAME
u:r:init:s0 root 1 0 /init

进程的安全上下文中，用户固定为 u，角色固定为 r。
文件的安全上下文中，用户固定为 u，角色固定为 obejct_r

在SELinux中，安全级别是可选的，也就是说，可以选择启用或者不启用。通常在进程及文件的安全上下文中安全级别都设置为s0。

进程的安全上下文的类型称为domain，文件的安全上下文中的类型称为file_type

上面我们看到进程init的安全上下文为u:r:init:s0，type为init
在Android中我们可以通过如下语句定义type:

type init domain;
即将domain设置为init的属性，这样就可以用init为type来描述进程的安全上下文了

Seapp_contexts

用于声明APP进程和创建数据目录的安全上下文，O上将该文件拆分为plat和nonplat 前缀的两个文件，plat前缀的文件用于声明system app，nonplat前缀的文件用于声明vendor app。
seinfo可以从mac_permissions.xml查看
对于使用平台签名的App来说，它的seinfo为“platform”。这样我们就可以知道，使用平台签名的App所运行在的进程domain为“platform_app”，并且它的数据文件的file_type为“platform_app_data_file”。

安全策略

SEAndroid安全机制又称为是基于TE（Type Enforcement）策略的安全机制。所有安全策略都存放在.te结尾的文件中，一般放在 /system/sepolicy/private/，厂商定制的一般放在/device/xxx/common/sepolicy/下
一个Type所具有的权限是通过allow语句来描述的，SEAndroid使用的是最小权限原则，也就是说，只有通过allow语句声明的权限才是允许的，而其它没有通过allow语句声明的权限都是禁止，这样就可以最大限度地保护系统中的资源。

语句格式为：allow scontex tcontex:class action

除了allow还有：neverallow （检查并记录是否有违反这条策略的）、allowaudit（检查记录权限成功及失败的操作，默认只记录检查失败的）、dontaudit（不记录权限检查失败的记录），后三个仅是检查及记录，并不赋予或禁止权限