Android selinux权限设置

背景

在做指纹的过程中遇到了很多权限设置的问题，sepolicy权限。

selinux权限设置

---

案例一 db访问不了了

背景

有需求需要db目录修改，由/data目录转到/data/app目录之后，结果出现生成不了db文件的问题。

解决方案及过程

• 最终解决方案

在系统fingerprint.te里添加权限

allow fingerprintserver apk_data_file:dir {read write open ioctl execute search getattr add_name create_dir_perms};

allow fingerprintserver apk_data_file:file {read write open ioctl create_file_perms};

第一句意思是允许fingerprintserver类型对apk_data_file类型的目录(dir)执行 read 、 write 、open 等操作

第二句意思是允许fingerprintserver类型对apk_data_file类型的文件(file)执行 read 、 write 、open 等操作

• 如何判断的fingerprintserver类型、apk_data_file类型以及要执行什么操作

由于db文件是在/data/app目录下，那么肯定是要对/data/app目录下的文件进行操作。

所以我们只要找一下/data/app所在的域

查看/data/app目录所在的域 , adb shell 进入data目录，并执行如下命令

root@XXX :/data # ls -Z

…

drwxrwx— system system u:object_r:system_data_file:s0 amit

drwxrwxr-x system system u:object_r:anr_data_file:s0 anr

drwxrwx–x system system u:object_r:apk_data_file:s0 app

drwx—— root root u:object_r:asec_image_file:s0 app-asec

drwxrwx–x system system u:object_r:system_data_file:s0 app-lib

…

可以看出来data目录下有很多子目录，这里列出了amit 、anr、app、app-asec、app-lib等子目录，

其中app目录所在的域为apk_data_file就是这么找的。

• 那为什么是 fingerprintserver 类型

前提是我们知道谁即哪个进程操作了这个db，

本例中是fp_native_service访问db

知道谁操作了这个db可以用以下方法查找进程所在的域 , adb shell 然后作如下操作

root@XXX :ps -Z

…

u:r:drmserver:s0 drm 302 1 /system/bin/drmserver

u:r:mediaserver:s0 media 303 1 /system/bin/mediaserver

u:r:fingerprintserver:s0 system 258 1 /system/bin/fp_native_service

u:r:installd:s0 install 304 1 /system/bin/installd

u:r:keystore:s0 keystore 306 1 /system/bin/keystore

…

这里没有将所有进程都列出来，只列出了部分进程，

但可以看到fp_native_service所在的域是fingerprintserver

即fingerprintserver类型的进程要对apk_data_file类型的文件进行某些操作

• 如何判断要执行什么操作

即排查是哪个权限问题

kenel.log中关键错误信息如下 这里搜的是 avc: denied

[ 486.936152] (0)[286:logd.auditd]type=1400 audit(1420041749.210:15756): avc: denied { write } for pid=5927 comm=”fp_native_servi” name=”app” dev=”mmcblk0p22″ ino=425985 scontext=u:r:fingerprintserver:s0 tcontext=u:object_r:apk_data_file:s0 tclass=dir permissive=0

其实log里已经包含了所有问题了。

scontext=u:r:fingerprintserver:s0 tcontext=u:object_r:apk_data_file:s0 tclass=dir permissive=0

那怎么知道是不是sepolicy权限引起的问题

判断是否是sepolicy权限问题

adb shell 之后执行setenforce 0可以暂时去除sepolicy权限 （不用重启机器，而且重启之后权限又恢复成原来的了）

具体操作为：

C:\Users>adb shell
root@XXX :/ # setenforce 0
setenforce 0

sepolicy权限去除之后发现db文件可以生成了。说明是sepolicy权限的问题。

这个setenforce 0 后面的零是什么意思 （只能是0或者1）

usage: setenforce [ Enforcing | Permissive | 1 | 0 ]

setenforce 0 设置SELinux 成为Permissive模式 (不检测sepolicy权限，但是会将违反权限的操作记录到log)

setenforce 1 设置SELinux 成为Enforcing模式 (强制检测sepolicy权限)

selinux sepolicy权限语法规则

查看当前进程拥有的selinux权限

查看进程拥有的selinux权限，adb shell 然后执行 ps -Z

LABEL USER PID PPID NAME

u:r:servicemanager:s0 system 260 1 /system/bin/servicemanager

u:r:vold:s0 root 261 1 /system/bin/vold

u:r:surfaceflinger:s0 system 262 1 /system/bin/surfaceflinger

u:r:init:s0 root 263 1 /system/bin/sh

u:r:kernel:s0 root 273 2 kauditd

u:r:ccci_fsd:s0 radio 274 1 /system/bin/ccci_fsd

u:r:ccci_mdinit:s0 system 275 1 /system/bin/ccci_mdinit

u:r:kernel:s0 root 277 2 kworker/3:2H

LABEL里

u:r:servicemanager:s0

u：android只定义了一个user
r:进程统一定义成r ， 文件统一定义成 object_r
servicemanager：进程所属的域 , 不唯一。 
s0:一种安全等级

查看当前文件拥有的selinux权限

查看文件拥有的selinux权限需要执行 ls -Z

root@XXX :/data # ls -Z

…

drwxrwx— system system u:object_r:system_data_file:s0 amit

drwxrwxr-x system system u:object_r:anr_data_file:s0 anr

drwxrwx–x system system u:object_r:apk_data_file:s0 app

drwx—— root root u:object_r:asec_image_file:s0 app-asec

drwxrwx–x system system u:object_r:system_data_file:s0 app-lib

…

u:android定义的user，只有一个
object_r:代表是一个文件
apk_data_file:这种代表文件所属的域，看有的解释说可以理解成type
s0:一种安全等级

mtk平台 selinux有三种工作模式

\bootable\bootloader\lk\platform\mtXXXX\rules.mk

# choose one of following value -> 1: disabled/ 2: permissive /3: enforcing
SELINUX_STATUS := 3

SELINUX_STATUS值代表的含义如下：

1:disabled (不检测权限)

2:permissive (警告模式运行，所有操作都被允许，但是如果违反权限会被记录到日志，目测就是kernel.log)

3:enforcing (强制检测)

sepolicy权限设置报错

ERROR: end of file in comment

这是由于文件最后加了 注释

例如
type gx_fpd_data_file, file_type, data_file_type;
######## end ####

Multiple same specifications for 这个是重复定义了。

本来是external/sepolicy权限已经定义了

结果在device/mediatek/common/sepolicy目录下又定义了一遍