SEAndroid 问题解决

终于把2个月纠结的功能做完了。 完成功能特地也总结一下

1. 命令一些常用的命令

1.1 adb shell getenforce (查看selinux 当前的状态)

Enforcing： 代表SELinux处于开启状态，会阻止进程违反SELinux策略访问资源的行为。
Permissive： 代表SELinux关闭，不会阻止进程违反SELinux策略访问资源的行为。

1.2 设置selinux 的状态 adb shell setenforce (开发时 userdebug 或者 eng )

0  Permissive：
1  Enforcing：

1.3 查询文件信息，进程信息

ls -Z  XXX  , ls -Z                      查看文件上下文

ps -Z  XXX  , ps -Z   ps -Z | grep qq    查看进程上下文

id -Z                                    查看当前用户信息

1.4

adb logcat | grep avc 

1.5

安装  sudo apt-get install policycoreutils 
          audit2allow -i  xxx.txt

1.6

   qcom

   androi M
        make bootimage

        adb reboot bootloader

        fastboot flash boot  

        fastboot devices

        fastboot reboot

android N:

        make ramdisk -j16

        make bootimage-nodeps -j16


    mtk
       KK:
       ./mk project_name mm external/sepolicy
       ./mk project_name bootimage

       L:
           mmm external/sepolicy
           make -j24 ramdisk-nodeps
           make -j24 bootimage-nodeps

1. 看源码，由于这里列出来的内容是来自Android 4.3的，而Android 4.3开启的是Permissive的SEAndroid模式。

 #Untrusted apps. 
type untrusted_app, domain; 
permissive untrusted_app; 
app_domain(untrusted_app) 
net_domain(untrusted_app) 
bluetooth_domain(untrusted_app) 
unconfined_domain(untrusted_app)

第二个permissive语句指定当domain为init的进程违反SEAndroid安全策略访问资源时，只进行日志输出，而不是拒绝执行。
测试时可以使用，正常版本user编译不过的

question:
http://seandroid-list.tycho.nsa.narkive.com/TqnE0zOs/i-have-some-question-about-mls-in-android-m-os

Daer SEAndroid-developers.

I heard that after android m os, mls is applied.
When I develop my model, I met this denials log.

avc: denied { ioctl } for pid=9055 comm=”Binder_2” path=”socket:[53263]”
dev=”sockfs” ino=53263 ioctlcmd=8927
scontext=u:r:untrusted_app:s0:c512,c768
tcontext=u:r:untrusted_app:s0:c512,c768 tclass=udp_socket permissive=1

I think this untrusted_app is gms app, because I can see this issue at
Google Account display.

When I check my policy, but already policy is included my source.
allow untrusted_app self:udp_socket ioctl;

I think it maybe mls problem.
I can fixed bellow method, but it should be wrong method.
(If i applied it, mls need not anymore.)
typeattribute untrusted_app mlstrustedsubject;
Please help me this issue.

seclabel u:r:XXXX:s0:c512,c768

other
http://blog.csdn.net/myarrow/article/details/9856095/ chcon 命令， 修改用户 安全type等

chcon 修改文件、目录的安全上下文
      chcon –u[user]
      chcon –r[role]
      chcon –t[type] 
      chcon –R  递归



domain_auto_trans
file_type_auto_trans
默认域转变：type_transition指令
修改 安全级别 gen_levels   

1. SEAndroid中共定义了三个拥有巨大权限的attribute , MLS

http://blog.csdn.net/myarrow/article/details/9856095/ 进程安全的上下文 mls

3.1 mlstrustedsubject  这一attribute包含了所有能越过MLS检查的主体domain

(type AAA, domain ,  mlstrustedsubject )

在SEAndroid中被分在mlstrustedsubject attribute中的type有adbd、debuggerd、drmserver、init、installd、kernel、mediaserver、netd、surfaceflinger、su、system、vold、zygote。


3.2 mlstrustedsObject  这一attribute包含了所有能越过MLS检查的客体type 

被分在mlstrustedobject attribute中的type有alarm_device、ashmem_device、binder_device、log_device、mtp_device、nv_device、powervr_device、
ptmx_device、null_device、cgroup、sysfs、sysfs_writable、sysfs_writable、sysfs_writable、debugfs、apk_data_file、cache_file、dnsproxyd_socket。

(type BBB, dev_type ,  mlstrustedsObject )


3.3 unconfineddomain: 这一attribute包含了所有拥有无限权限的type , 拥有所有权限可对客体进行任意操作。

(unconfined.te 主要是为unconfineddomain属性制定策略，这些策略基本就是对各种访问客体拥有所有的权限)

被分在unconfineddomain的type有init、kernel、su。

http://blog.sina.com.cn/s/blog_67521b8c0102wpoj.html

http://mt.sohu.com/20170308/n482657337.shtml mls 相关函数
http://blog.csdn.net/modianwutong/article/details/43114883 .为文件或文件系统打标签
http://book.51cto.com/art/200811/98789.htm mlsconstrain
http://book.51cto.com/art/200811/98791.htm MLS的其它影响

每个APP都会在mac_permissions.xml中找到一个对应的seinfo，然后在seapp_contexts中找到对应的domain和type。其中，domain就用来给应用程序进程当作安全上下文了。
       详细地说，在android5.x中，为支持多用户，应用程序的UID由两部分组成，User Id和App Id。赋值方法：
    userid = uid / AID_USER;
    appid = uid % AID_USER;
其中，AID_USER是一个常量，值为100000。
       App Id小于AID_APP(10000)是保留给系统使用的，它们对应的username保存在数组android_ids中，具体可以参考文件system/core/include/private/android_filesystem_config.h。
       App Id大于等于AID_APP(10000)并且小于AID_ISOLATED_START(99000)是分配给应用程序使用的，它们对应的username统一设置为“_app”。      
       App Id大于等于AID_ISOLATED_START(99000)是分配给运行在独立沙箱（没有任何自己的Permission）的应用程序使用的，它们对应的username统一设置为“_isolated”

1. 通过system server service 或者 init 启动的service 读写, 然后app 通过binder/socket 等方式连接APP 访问. 此类安全可靠, 并且可以在service 中做相关的安全审查 .

2. Zygote进程是由init进程创建的，它的启动命令定义在文件system/core/rootdir/init.rc

   照猫画虎，我们启动自己的 服务也在 此文件中 system/core/rootdir/init.rc

   如果新的设备节点没有在 file_contexts 中定义, 那么默认属于 root 组 , root 所有

3. 6.

* device  
  -- 类型定义: external/sepolicy/device.te;device/mediatek/common/sepolicy/device.te 
  -- 类型绑定: external/sepolicy/file_contexts;device/mediatek/common/sepolicy/file_contexts

  * File 类型: 
  -- 类型定义: external/sepolicy/file.te;device/mediatek/common/sepolicy/file.te
  -- 绑定类型: external/sepolicy/file_contexts;device/mediatek/common/sepolicy/file_contexts

  * 虚拟File 类型: 
  -- 类型定义: external/sepolicy/file.te;device/mediatek/common/sepolicy/file.te
  -- 绑定类型: external/sepolicy/genfs_contexts;device/mediatek/common/sepolicy/genfs_contexts

  * Service 类型:
  -- 类型定义: external/sepolicy/service.te; device/mediatek/common/sepolicy/service.te
  -- 绑定类型：external/sepolicyservice_contexts;device/mediatek/common/sepolicy/service_contexts

  * Property 类型:
  -- 类型定义: external/sepolicy/property.te;device/mediatek/common/sepolicy/property.te
  -- 绑定类型: external/sepolicy/property_contexts;device/mediatek/common/sepolicy/property_contexts;

7.各种宏要了解 （external/sepolicy/te_macros ），并 mac dac 会区分宏的权限

Apps signed with the platform key.

type platform_app, domain; 
permissive platform_app; 
app_domain(platform_app) 
platform_app_domain(platform_app) 
 Access the network. 
net_domain(platform_app) 
Access bluetooth. 
bluetooth_domain(platform_app) 
unconfined_domain(platform_app) 
......

前面在分析seapp_contexts文件的时候，我们提到，使用平台签名的App所运行在的进程的domain指定为”platform_app”。
从上面列出的内容可以看出，platform_app接下来会通过app_domain、platform_app_domain、net_domain、bluetooth_domain和unconfined_domain宏分别加入到其它的domain中去，
以便可以获得相应的权限。接下来我们就以unconfined_domain宏为例，分析platform_app获得了哪些权限。

宏unconfined_domain定义在文件te_macros文件中

......  ##################################### # 
unconfined_domain(domain) 
# Allow the specified domain to do anything. # 
define(`unconfined_domain', ` typeattribute $1 mlstrustedsubject; typeattribute $1 unconfineddomain; ')  ......

$1引用的就是unconfined_domain的参数，即platform_app。通过接下来的两个typeattribute语句，

为platform_app设置了mlstrustedsubject和unconfineddomain两个属性。也就是说，
mlstrustedsubject和unconfineddomain这两个Type具有权限，
platform_app这个Type也具有。

接下来我们主要分析unconfineddomain这个Type具有哪些权限。

文件unconfined.te定义了unconfineddomain这个Type所具有的权限，如下所示：

一个Type所具有的权限是通过allow语句来描述的，以下这个allow语句：
allow unconfineddomain domain:binder { call transfer set_context_mgr };
表明domain为unconfineddomain的进程可以与其它进程进行binder ipc通信（call），并且能够向这些进程传递Binder对象（transfer），以及将自己设置为Binder上下文管理器（set_context_mgr）。
注意，SEAndroid使用的是最小权限原则，也就是说，只有通过allow语句声明的权限才是允许的，而其它没有通过allow语句声明的权限都是禁止，这样就可以最大限度地保护系统中的资源。
如果我们继续分析app.te的内容，会发现使用第三方签名的App所运行在的进程同样是加入到unconfineddomain这个domain的，如下所示：

# Untrusted apps
type untrusted_app, domain; 
permissive untrusted_app; 
app_domain(untrusted_app) 
net_domain(untrusted_app) 
bluetooth_domain(untrusted_app) 
unconfined_domain(untrusted_app)

这是不是意味着使用平台签名和第三方签名的App所具有的权限都是一样的呢？
答案是否定的。
虽然使用平台签名和第三方签名的App在SEAndroid安全框架的约束下都具有unconfineddomain这个domain所赋予的权限，
但是别忘记，在进行SEAndroid安全检查之前，使用平台签名和第三方签名的App首先要通过DAC检查，
也就是要通过传统的Linux UID/GID安全检查。由于使用平台签名和第三方签名的App在安装的时候分配到的Linux UID/GID是不一样的，因此就决定了它们所具有权限是不一样的。

8.

必须要理解的一些概念

8.1 DAC和MAC的区别：

DAC核心思想：进程理论上所拥有的权限与执行它的用户的权限相同。比如，以root用户启动Browser，那么Browser就有root用户的权限，在Linux系统上能干任何事情。

MAC核心思想：即任何进程想在SELinux系统中干任何事情，都必须先在安全策略配置文件中赋予权限。凡是没有出现在安全策略配置文件中的权限，进程就没有该权限。

DAC和MAC的联系：

Linux系统先做DAC检查，如果没有通过DAC权限检查，则操作直接失败。通过DAC检查之后，再做MAC权限检查。

8.2 用户(user)和角色(role)：
路径：external/sepolicy/users

user u roles { r } level s0 range s0 - mls_systemhigh;

上述语句声明了一个SELinux用户u，它可用的SELinux角色为r，它的默认安全级别为s0，可用的安全级别范围为s0~mls_systemhigh，其中，mls_systemhigh为系统定义的最高安全级别。

路径：external/sepolicy/roles

role r;

role r types domain;

第一个语句声明了一个SELinux角色r；第二个语句允许SELinux角色r与类型domain关联。

对于进程来说，SELinux用户和SELinux角色只是用来限制进程可以标注的类型，
以前面列出的 external/sepolicy/users和external/sepolicy/roles文件内容来例，如果没有出现其它的user或者 role声明，
那么就意味着只有u、r, domain 和mls 安全级别(s0 - mls_systemhigh)可以组合在一起形成一个合法的安全上下文，而其它形式的安全上下文定义均是非法的。

一些好文章，当时解决功能问题的参照

http://www.ithao123.cn/content-719375.html SEAndroid策略分析（挺详细的）

http://source.android.com/devices/tech/security/se-linux.html

http://cfanz.cn/index.php?c=article&a=read&id=176584 老罗

http://blog.csdn.net/luoshengyang/article/details/37613135 老罗，SEAndroid安全机制框架分

http://blog.csdn.net/luoshengyang/article/details/38054645 老罗 SEAndroid安全机制中的进程安全上下文关联分析

http://blog.csdn.net/innost/article/details/19299937 深入理解SELinux SEAndroid（第一部分）

http://blog.csdn.net/innost/article/details/19641487 深入理解SELinux SEAndroid之二

http://blog.csdn.net/syhost/article/details/41496701 深入理解SELinux SEAndroid Sepolicy（第一部分）

http://loda.hala01.com/2013/08/android-4-3%E5%AE%89%E5%85%A8%E6%A9%9F%E5%88%B6%E6%8E%A2%E8%A8%8E/ 4.3安全机制探讨

http://www.th7.cn/system/lin/201603/156856.shtml

http://www.jianshu.com/p/a3572eee341c se框架