SEAndroid学习笔记
SELinux概念
以一个例子来记录下学习SEAndroid的笔记。
需求：很简单，一个system进程要往ServiceManager中添加服务。没写对应的SELinux策略时遇到的错误：
02-21 10:37:25.662 484 484 E SELinux : avc: denied { add } for service=car_model_service pid=10283 uid=1000 scontext=u:r:system_app:s0 tcontext=u:object_r:default_android_service:s0 tclass=service_manager permissive=0这个错误是说啥呢
denied 拒绝
{ add } 是指被拒绝的权限，或者叫被拒绝的动作
service=car_model_service 是指服务名称，这里就是要add到ServiceManager中的那个字符串"car_model_service"
pid=10283 是指这个进程的操作被拒绝了
uid=1000 这个进程的uid，1000就是Android中的system user
scontext=u:r:system_app:s0 这个是重点1，scontext是指源标签，就是发起操作的进程的标签，这个标签就是SELinux中用来判断权限的重要依据（SELinux是一个基于标签的系统，这个文章解释了这个标签是怎么给进程和文件打上的）
tcontext=u:object_r:default_android_service:s0 tcontext是指目的标签，object_r这个是标签中的角色部分，Android中r角色表示进程，是活的，能发起动作的角色，object_r这个角色，是死的，只能被人操作、访问，一般是文件、设备、属性等，这里是服务，更精确点说，是服务名：car_model_service，但是这个标签里是default_android_service这个类型，或者叫域，因为我们还没有在SELinux策略里明确定义car_model_service这个服务定义所属的域，所以selinux给他一个default_android_service域。
tclass=service_manager 这个是说，要操作的具体对象的类别，在这里是指要操作一个default_android_service下的service_manager对象，tclass常见的类别还有file、device等。
所以，总结以上，那条log的意思就是：uid 是system的进程10283 （SELinux标签是u:r:system_app:s0 ）想要把标签是 u:object_r:default_android_service:s0 （car_model_service的标签）的对象对service_manager这个类型的对象做 { add } 操作，（就是要把car_model_service 加到 service_manager中），由于不符合现有的SELinux Policy的策略定义，被拒绝了。
注：标签u:r:system_app:s0中有4个部分分别是user:role:type:sec_level 其中SEAndroid中user都是u，role为r表示进程，role为object_r表示除进程外的其他可被进程操作的对象如file、device等，sec_level表示一个安全级别，Android中都是s0，为同一级别。所以SEAndroid大部分其实用到的只有type这部分即SELinux的子集，这篇介绍了SELinux中的三种强制执行模型，Android中主要是第一种基于类型的强制执行模型，有少部分用到了MCS（多类别安全模型）。。
所以，我们要增加策略，那就是允许system_app域（或类型）的进程把default_android_service域中（或类型）的service add 到 service_manager中，可以试下自动将拒绝log转换成 SELinux策略的工具 audit2allow（自行搜索用法，这东西只能参考，大部分不好使）给出的策略：
#=============system_app==============allow system_app default_android_service:service_manager add;输出的这个的意思是，可以把这句加到system_app.te（system_app.te是什么？）文件中 试试。但是，如果真这么加起作用，那就坏了，因为策略中没有定义的service名，系统都给打上了u:object_r:default_android_service:s0 标签（这个标签怎么来的），上面那句真起作用，那不就很容易破坏了SELinux的保护了吗？显然SELinux没有这么脆弱，上面那句规则会违反neverallow 规则，编译是无法通过的。
编译错误提示neverallow check failed at out/target/product/PRODUCT_NAME/obj/ETC/treble_sepolicy_tests_intermediates/built_plat_sepolicy:4273 from system/sepolicy/public/domain.te:432 (neverallow base_typeattr_9 default_android_service (service_manager (add))) <root> allow at out/target/product/PRODUCT_NAME/obj/ETC/treble_sepolicy_tests_intermediates/built_plat_sepolicy:11897 (allow system_app default_android_service (service_manager (add)))Failed to generate binaryFailed to build policydb根据错误提示可以找到对应的neverallow策略：
android/system/sepolicy/public/domain.te
# Do not allow service_manager add for default service labels.# Instead domains should use a more specific type such as# system_app_service rather than the generic type.# New service_types are defined in {,hw,vnd}service.te and new mappings# from service name to service_type are defined in {,hw,vnd}service_contexts.neverallow * default_android_service:service_manager add;这个策略的意思是，不允许 任何 进程将类型为default_android_service的service 对service_manager 做 add操作（service_manager.c中的add service 函数中会根据selinux策略来检查），显然上面的audit2allow输出的策略和这条neverallow策略冲突。
所以需要修改策略。
根据neverallow策略，要add的service，不能被打上u:object_r:default_android_service:s0 标签，不然天王老子（比如root进程）都不能add到ServiceManager中去，先看看这个标签怎么来的：
android/system/sepolicy/private/service_contexts
我们随便找一个可以添加到ServiceManager的服务看看是怎么定义的，例如SurfaceFlinger的标签定义：
SurfaceFlinger u:object_r:surfaceflinger_service:s0其他所有Android系统中由ServiceManager管理的服务都在这里做了定义，其中有一条规则是这样的：
* u:object_r:default_android_service:s0可以看到service名字为 * 被打上了u:object_r:default_android_service:s0 标签，是指没有在service_contexts定义的，都是这个标签，所以我们要自己给要添加的service写一条规则定义其标签。
上面这个文件中定义了android系统默认的service的标签，根据不同项目需要自定义的service标签最好在项目文件目录中定义：
android/device/qcom/sepolicy/private/service_contexts
Android中所有service 对应的selinux标签都由该文件定义，该文件可以有多份，编译时合并。所以我们在这个文件中定义要add的service 标签：
car_model_service u:object_r:my_car_model_service:s0当然 my_car_model_service这个域（或类型）也得定义，不然selinux不认识啊，service相关的域，或者叫类型的定义在如下文件（android默认肯定也有一个service.te的文件，定义所有Android原生的service域）：
android/device/qcom/sepolicy/common/service.te
type my_car_model_service, service_manager_type;这句话意思是，定义一个域（或类型）my_car_model_service，并且把它关联到service_manager_type，这个service_manager_type叫attribute，其实叫域的集合更好，这样关联后，有关service_manager_type的规则，同样也适用于my_car_model_service。照猫画虎的参考其他service，我们还发现，还需要修改system_app.te，因为我们的进程是属于system_app域的，有关system_app域的进程的访问权限都定义在此文件中（当然这个文件也可以有多份）。
android/vendor/myvendor/sepolicy/system_app.te
add_service(system_app, my_car_model_service)这里又出现一个概念，就是宏，就是可以展开的定义，add_service就是个宏，selinux宏的定义一般都在后缀为macros的文件中（system/sepolicy/中定义了大部分android默认的policy政策以及宏和其他的定义）：
android/system/sepolicy/public/te_macros
############################################ add_service(domain, service)# Ability for domain to add a service to service_manager# and find it. It also creates a neverallow preventing# others from adding it.define(`add_service', ` allow $1 $2:service_manager { add find }; neverallow { domain -$1 } $2:service_manager add;')所以上面system_app.te中的:
add_service(system_app, my_car_model_service)编译后就变成了
allow system_app my_car_model_service:service_manager { add find }; neverallow { domain -system_app } my_car_model_service:service_manager add;意思就是允许 system_app 域（或类型）的进程，就是打了标签 u:r:system_app:s0的进程，把my_car_model_service类型的服务对service_manager做 add 和 find 操作。就是能加进去，也能取出来用。下面为了安全，还又加了一个neverallow策略，不允许除了system_app以外的 domain域（或类型）的进程往service_manager里加my_car_model_service。Android中所有的进程都关联到了domain上了。可以随意查看一个.te文件，开头都会定义type ***, domain; 就是说，所有对domain策略，对关联了domain的域都起作用。如果你定义一个进程的域没有关联domain域，那么所有进程相关的操作，都得自己重写。domain.te中定义了允许所有进程进行的操作的规则。毕竟selinux上任何进程对任何资源要操作，都要定义对应的策略。
稍等：
type my_car_model_service, service_manager_type;这句有啥用呢？刚才说了type 的作用是把要定义的域关联到后面的属性(attribute)或域上，这样所有对于后面属性的策略都可以对新定义的域起作用，这句定义完成后，所有有关service_manager_type的规则，都可以对我们新的服务起作用，比如：
android/system/sepolicy/public/shell.te
allow shell { service_manager_type -gatekeeper_service -incident_service -installd_service -netd_service -virtual_touchpad_service -vr_hwc_service }:service_manager find;这样你不用去配置，shell域的进程就可以取service_manager中去查找服务，例如dumpsys就是shell域的进程，否则，你得单独去允许my_car_model_service被shell查询。
到这里，解决这个简单问题的se策略就加完了。
雷锋网按：本文节选自《2016年Android恶意软件专题报告》，作者：360烽火实验室，致力于Android病毒分析、移动黑产研究、移动威胁预警以及Android漏洞挖掘等移动安全领域及Android安全生态的深度研究。
2016年全年，从手机用户感染恶意程序情况看，360互联网安全中心累计监测到Android用户感染恶意程序2.53亿，平均每天恶意程序感染量约为70万人次。钓鱼软件、勒索软件、色情播放器软件、顽固木马成为2016年流行的恶意软件。
从恶意软件开发技术角度看， 2016年恶意软件利用社会工程学、界面劫持、破解接口、开源项目、简易开发工具、碎片化代码、注入系统根进程、篡改系统引导区以及代理反弹技术，成为主要使用的新技术。
一、社会工程学
社会工程学(Social Engineering)是一种通过对受害者心理弱点、本能反应、好奇心、信任、贪婪等心理陷阱进行诸如欺骗、伤害等危害手段，并以此来获取自身利益的手法。
随着Android系统版本升级的同时，Android系统在安全策略方面得到了进一步的增强和优化，像无障碍模式Accessibility和动态权限模型都需要用户主动授权后才可以使用。Android恶意软件借助社会工程学已成迅速上升甚至滥用的趋势，通过诱导性的图标和文字，引导用户授予相应的功能的权限，从而保证恶意软件正常的运行环境。
二、界面劫持
Android为了提高用户体验，对于不同应用程序之间的切换，基本上是无缝切换。他们切换的只是一个Activity，一个切换的到前台显示，另一个应用则被覆盖到后台不可见。每当一个Activity启动，它就压入历史栈顶，并在手机上显示。当用户按下返回键时，顶部Activity弹出，恢复前一个Activity，栈顶指向当前的Activity。
界面劫持技术指在Android 5.0以下的系统中，程序可以枚举当前运行的任务，恶意软件监控目标应用的运行，当检测到当前运行界面为被监控应用某个特定界面（一般为登录或支付界面）时，弹出伪造的钓鱼界面以覆盖原应用正常界面，诱导用户输入信息，回传输入信息，最终窃取用户隐私。
Google官方在Android 5.0系统及以上版本限制了获取栈顶Activity的获取方法getRunningTasks的使用[8]，并且说明这一方法不能再能获取第三方应用信息，只能获取自身或一些已知不含有敏感信息的程序。
虽然Android 5.0以上减弱了这种攻击方式，但是根据Google最新的Android系统版本占比统计，Android 5.0以下版本仍然有一定的市场占有率，这些手机仍然可能遭受到这种威胁。
三、被恶意利用的合法程序
(一)破解接口
破解接口是指通过逆向软件某个功能模块的原理机制后，通过修改并加以利用，达到利用的目的。
2016年，从我们截获的带有获取Root功能的恶意软件代码中发现，一些正规的提供手机Root服务的软件，Root功能接口遭到破解，被不法分子利用嵌入到恶意软件中。
(二)开源项目
GitHub是一个面向开源及私有软件项目的托管平台，同样，从我们截获的带有获取Root功能的恶意软件代码中还发现，GitHub中的一些开源项目比如“android-rooting-tools”被嵌入到Android木马中被恶意利用。
四、开发工具
(一) 简易开发工具被广泛应用
AIDE是Android环境下的开发工具，这种开发工具不需要借助电脑，只需要在手机上操作，便可以完成Android样本的代码编写、编译、打包及签名全套开发流程。
2016年，我们发布的《ANDROID勒索软件研究报告》，报告指出国内大量的锁屏软件都使用合法的开发工具AIDE，因为这种工具操作简单方便，开发门槛低，变化速度快，使得其成为不法分子开发勒索软件的首选。
(二) 借助工具碎片化代码
Instant Run是Android官方应用开发工具Android Studio 2.0版本新增的即时运行功能。它允许开发人员通过将更新.zip文件推送到应用程序来快速部署更新到调试应用程序。
Android恶意软件基于Instant Run功能，将恶意代码分散隐藏在zip文件中，规避安全软件检测与查杀。2016年，360互联网安全中心累计截获基于Instant Run功能的恶意软件约1400个，由于Android Studio在4月份才正式推出Instant Run功能，所以一季度新增样本量极少。
五、高级技术手段
(一) 注入系统根进程
Android系统根进程Zygote进程，它是Android系统所有进程的父进程。2016年3月，基于Zygote的攻击“Triada”木马家族曝光，该木马最显著的特点是使用Zygote进程，一旦进入系统，就会成为该应用进程的一部分，并可以在设备上启动的任何应用中预先进行安装，甚至改变应用的运行逻辑。当用户在应用内通过短信购买安卓游戏时，黑客可以利用Triada木马修改发送的短信，非法获取用户的支付费用。
(二) 篡改系统引导区
2016年6月，360互联网安全中心发现首个通过修改系统引导区Boot Image、替换系统核心文件的方式实现自我保护的Android恶意软件“地狱火”。Android系统以正常模式启动后会加载Boot.img分区。Boot.img分区包含Linux内核和Ramdisk。Ramdisk是一个小型文件系统，包括了初始化系统所需要的全部核心文件，例如：初始化init进程以及init.rc等文件。与Oldboot[14]相比该病毒还会绕过SEAndroid、dm_verify等Android系统安全防护
(三) 代理反弹
许多公司越来越重视企业网络安全问题，一般在企业信息系统前端均部署有防火墙，系统管理员根据业务需求将内部必要的服务端口通过端口映射等手段映射到公网中。通过部署防火墙可以将信息系统内部区域与公网逻辑隔离开来，利用相关的策略有效避免或减轻来自外部的攻击。
2016年9月，“DressCode”恶意软件家族使用SOCKS代理反弹技术突破内网防火墙限制，窃取内网数据，这种通过代理穿透内网绕过防火墙的手段在PC上并不新鲜，然而以手机终端为跳板实现对企业内网的渗透还是首见，是Android平台新出现的高级技术手段。
上一篇：苹果组装屏和原装区别_2
下一篇：ppt2013如何插入自选图形
发表评论