分享常见selinux相关命令

selinux简单介绍

SELinux出现之前，Linux上的安全模型叫DAC，全称是Discretionary Access Control，翻译为自主访问控制。DAC的核心思想很简单，就是：进程理论上所拥有的权限与执行它的用户的权限相同。比如，以root用户启动Browser，那么Browser就有root用户的权限，在Linux系统上能干任何事情。
显然，DAC太过宽松了，所以各路高手想方设法都要在Android系统上搞到root权限。那么SELinux如何解决这个问题呢？原来，它在DAC之外，设计了一个新的安全模型，叫MAC（Mandatory Access Control），翻译为强制访问控制。MAC的处世哲学非常简单：即任何进程想在SELinux系统中干任何事情，都必须先在安全策略配置文件中赋予权限。凡是没有出现在安全策略配置文件中的权限，进程就没有该权限。

问题背景：

近来有一些粉丝朋友问到了一些selinux相关问题如何定位，怎么可以准确看selinux相关日志问题？avc相关的日志很多，怎么就可以确定这个avc就是自己进程搞出来的呢？下面就分享一些工作中经常会使用到的selinux技巧命令，方便大家更加准确定位一些selinux问题。

判断是否属于selinux引起的问题：setenforce、getenforce

首先自己程序中调用某些代码，比如ServiceManager获取相关service，发现获取不成功，或者是访问某个文件死活不成功，这个时候确定程序的manifest等已经加入了相关权限，已经不是systemserver层面的权限拦截了，那么就需要考虑是否是selinux相关权限阻碍了。

NX563J:/ # setenforce 1
NX563J:/ # getenforce                                                                                                                                                                                     
Enforcing
NX563J:/ # setenforce 0                                                                                                                                                                                   
NX563J:/ # getenforce                                                                                                                                                                                     
Permissive

上面的setenforce即来设置是否开放selinux拦截，setenforce 0即可以关闭selinux拦截，setenforce 1就是恢复selinux拦截
getenforce命令则是看看当前selinux是否处于拦截还是非拦截状态。Enforcing代表拦截，Permissive代表不拦截，即哪怕有avc相关日志报错也不会影响权限获取，直接可以得到，基本上属于没有selinux拦截，即setenforce 0一般只能用于普通定位是否属于selinux问题引起的，不能用于正式发布产品版本。

总结：平时用setenforce 0既可以关闭掉系统selinux

当然avc日志也可以看出：

05-23 11:08:39.316 1068 1068 I auditd : type=1400 audit(0.0:7291): avc: denied { read } for comm=“HwBinder:1068_3” name=“u:object_r:default_prop:s0” dev=“tmpfs” ino=19151 scontext=u:r:hal_camera_default:s0 tcontext=u:object_r:default_prop:s0 tclass=file permissive=0

比如看如下的日志，这里permissive=0，说明不是宽限模式，会启动selinux拦截

05-23 11:06:55.106 24439 24439 I auditd : type=1400 audit(0.0:7288): avc: denied { bind } for comm=“ip” scontext=u:r:untrusted_app_30:s0:c89,c256,c512,c768 tcontext=u:r:untrusted_app_30:s0:c89,c256,c512,c768 tclass=netlink_route_socket permissive=1 app=com.tencent.mm

比如看如下的日志，这里permissive=1，说明是宽限模式，不会启动selinux拦截，但是日志还是会打印的

查看进程或文件属于什么context命令：

ps -AZ | grep xxxx 命令查看
一般上下文主要分为进程上下文，这个一般是各个进程要啥事，即上面avc的selinux日志中的scontext
例如：

05-23 11:06:55.106 24439 24439 I auditd : type=1400 audit(0.0:7288): avc: denied { bind } for comm=“ip” scontext=u:r:untrusted_app_30:s0:c89,c256,c512,c768 tcontext=u:r:untrusted_app_30:s0:c89,c256,c512,c768 tclass=netlink_route_socket permissive=1 app=com.tencent.mm

这里面的进程上下 文就是untrusted_app_30

NX563J:/ # ps -AZ | grep untrusted_app_30
u:r:untrusted_app_30:s0:c96,c256,c512,c768 u0_a96 4245 1001 15031040 82040 SyS_epoll_wait     0 S com.android.inputmethod.latin
u:r:untrusted_app_30:s0:c89,c256,c512,c768 u0_a89 15328 1001 18351568 187400 SyS_epoll_wait   0 S com.tencent.mm:push
u:r:untrusted_app_30:s0:c89,c256,c512,c768 u0_a89 15447 1001 19730956 320804 SyS_epoll_wait   0 S com.tencent.mm

可以看到有多个进程，但是日志中还有app=com.tencent.mm,那么就很好确认了包名，但是有一些打印如下
name=search scontext=u:r:permissioncontroller_app:s0:xxx tcontext=u:object_r:search_service:s0 tclass=service_manager permissive=0

没有发现有包名情况，只有个scontext为permissioncontroller_app,这个看着说实话你其实并不清楚具体是哪个进程，那么这个时候就需要ps -AZ | grep permissioncontroller_app来定位

130|NX563J:/ # ps -AZ | grep permissioncontroller_app
u:r:permissioncontroller_app:s0:c123,c256,c512,c768 u0_a123 2992 1001 15398216 105888 SyS_epoll_wait 0 S com.android.permissioncontroller

可以看到是com.android.permissioncontroller这个权限弹框的进程

ls -Z 查看文件的上下文
比如访问某个文件一直不成功，这个时候想看看文件到底是什么上下文，只有知道了文件是什么上下文才可以准确确定如何写selinux的te文件等

NX563J:/vendor # ls -Z                                                                                                                                                                                    
u:object_r:vendor_app_file:s0      app          u:object_r:vendor_configs_file:s0  etc           u:object_r:vendor_file:s0          lost+found  u:object_r:vendor_file:s0          recovery-from-boot.p
u:object_r:vendor_file:s0          bin          u:object_r:vendor_firmware_file:s0 firmware      u:object_r:vendor_file:s0          odm         u:object_r:vendor_file:s0          rfs
u:object_r:bt_firmware_file:s0     bt_firmware  u:object_r:firmware_file:s0        firmware_mnt  u:object_r:vendor_file:s0          odm_dlkm    u:object_r:vendor_file:s0          usr
u:object_r:vendor_file:s0          build.prop   u:object_r:vendor_file:s0          lib           u:object_r:vendor_overlay_file:s0  overlay     u:object_r:vendor_file:s0          vendor_dlkm
u:object_r:adsprpcd_file:s0        dsp          u:object_r:vendor_file:s0          lib64         u:object_r:vendor_file:s0          radio

可以看到上面vendor下面app目录属于vendor_app_file，其他vendor下的目录如果没有特别指定单独的上下文，那就只是普通的vendor_file

总结

1、setenforce、getenforce一般用于临时关闭selinux，来确定是否属于selinux类型的权限问题

2、ps -AZ 查看运行进程的上下文

3、ls -Z 查看文件的上下文

更多framework实战干货，请关注下面“千里马学框架”