当前位置: 代码迷 >> Android >> 探究一种Android保险解决方案
  详细解决方案

探究一种Android保险解决方案

热度:53   发布时间:2016-05-01 10:58:57.0
探究一种Android安全解决方案

一 引言

       Android系统由Google公司联合开放手机联盟OHA于2007年11月发布,正是由于Android强大的功能和开源的特性,Android一经推出就受到市场的热销,但随之而来的是Android的安全问题,许多恶意软件的作者瞄准了Android系统,恶意扣费,远程控制,隐私泄露等等安全问题接踵而来。国内外已经有许许多多专家和学者围绕着Android安全开展来了一系列深入的研究,其中关注Android权限的研究确比较少。Android强烈依赖于权限检查机制,玩过Android手机的朋友都知道,每当用户安装一款新的软件,在安装界面上Android总会提示用户此软件所需要的权限,用户要么全部接受这些权限要求,要么否定本次安装过程。这也表明了Android系统会对每个APP进行安装前的权限检查,那么我们很自然得要问,如果软件被安装完毕,用户点击了软件图标,或者此软件被启动运行,Android会对运行的程序进行权限检查吗?


二 从一封专家回信谈起


以上是美国安全局Stephen给我的回信,Stephen也是SEAndroid项目的发起人,SEAndroid是2011年发布的开源手机操作系统,它是在Android基础上进行了安全加固,其内核层采用了SELinux,但我要强调的是SEAndroid不等于Android + SELinux,由于本人对SEAndroid认识还比较浅,我画了一个SEAndroid研发流程图,如果不对,请大家指正,


从上图可以看出,SEAndroid非常复杂,但我们此时只讨论Stephen说的权限检查机制。从Stephen的回信可以看出Android的权限检查不是对APP本身,而是系统服务或系统进程,这是如何理解?


三 揭秘Android权限机制

1. Android权限到达是什么?

    美国的伯克利大学有一个博士叫Adrienne Porter Felt,她在Android安全方面有着比较高的造诣,目前Adrienne在Google公司工作。在她发表的一篇文章“Android Permissions Demystified”详细阐述了Android权限与Android的JAVA API关系。如果一个APP要想使用Android系统受限资源,比如读写SD卡,那么它必须在自己的manifest.xml文件中声明相应的权限,如<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE/>。一个权限一般是与Android的JAVA API对应,而且是多对多的关系,如下图:


而API调用又可以被分为三步,第一,应用程序获取相应权限后会调用公共库中的API,第二,公共API会调用一个叫API代理的接口(RPC stub),第三,此接口把请求传递给系统服务,由系统服务进程完成具体的功能。如下图所示:


权限检查恰恰发生在对系统服务和系统进程中。

2. Android系统完成权限检查的代码在哪?

打开Android系统框架层源码,切换到ActivityManagerService,java和PackageManagerService.java,在这两个文件中,有关于权限检查的代码,其中checkComponentPermissions在ActivityManagerService.java中,它会调用PackageManagerService.java中的checkUidPermission。如下图所示:


当一个APP的activity从开始到主界面显示之间,ActivityManagerService会对其进行权限检查,当主界面出现后,PackageManagerService会对应用程序调的系统进程进行权限检查,因此,Android系统既存在安装时的权限检查,又存在程序运行时的权限检查。


四 RBAC解决方案

    RBAC是上世纪70年代出现的一种简化权限管理的安全模型,目前已经在商业上取得了一定的成功,有着大量成熟的RBAC产品。RBAC(Role based Access Control)是一种基于角色的强制访问控制模型,它利用角色简化权限,当被用于商业系统管理时,权限不在直接分配给用户,而是安全管理员根据安全需求,设计出合适的角色,每种角色代表一定的权限,用户只有获取角色,才能行使一定的权限。下图是我开发出的简化版的Android RBAC系统:


这个系统包含五个模块,其实这五个模块是用户操作RBAC数据库的接口,RBAC数据库放在Android框架层,这也是出于效率的考虑。每当用户安装完了某款Android应用程序,那么此应用程序就成为了Android系统的一个用户,有着唯一的UID,这个UID是链接到Linux内核的进程UID。我们大家都玩过Android游戏,但很多恶意代码是嵌入到游戏中去的,它们会利用已经被用户批准的权限进行破坏活动,那么我们就可以利用这个我开发的这个系统对其进行管理和限制。

五 系统功能简易测试

为了验证系统的功能,我们选择一款Android模拟器上的游戏软件cheeseTower:



这个软件已经被安装成功了,我们查看它的权限,发现如下:


Android系统批准了网络通信和读取电话两项权限,这也是cheeseTower在自己manifest文件中声明的权限需求。我在PackageManagerService中做了数据库,记录了当checkUidPermission(int uid, String permName)中每个uid和相应的权限名。我们切换到adb shell,利用sqlite3打开rbac.db,查看相应的表,记录显示如下:


这里的uid=10035是我开发的RBAC系统中可以查看到的,我们发现,cheeseTower在运行时要求了过多的权限,即访问粗细位置。需要强调的是,有些权限是软件要想运行起来所必须的,cheeseTower要想运行起来,读电话状态和访问无线是必须的,而且cheeseTower正是通过访问wifi来连接网络的。

这样,我们利用RBAC系统新建一个game角色,并为它只分配读电话状态权限,如下图:






好了,我们角色新建就完成了,那么Android框架层RBAC控制代码就可以依据我们刚才建立的数据进行访问控制了。但值得注意的是,cheeseTower要想被Laucher启动起来出现主界面,必须获取读电话和访问wifi权限,我们没有分配给其启动时足够的权限,如果此时点击它的图标,会出现cheeseTower has stopped的提示,cheeseTower启动终止了。还记得我上面画的访问控制图吗,我对于启动Activity做了修改,让Launcher在启动应用程序时忽略RBAC访问控制,好的,以下的实验如下图:




从实验效果看,我们已经能够阻止cheeseTower连入网络,如果你回到RBAC管理系统,更改角色,不分配game访问wifi权限,而是访问Internet权限,cheeseTower仍然无法连入网络。我们进入修改角色模块,为game分配访问wifi权限,这样,cheeseTower可以连入网络了,如下图:


六 接下来的工作

     其实,我们不仅仅要拒绝应用程序使用某种权限,而且要能够在某种条件下拒绝权限,或者应用程序在什么样的条件下可以使用权限,使用权限能够做哪些事情。举个很简单例子,很多软件都要求访问网络权限,而恶意软件恰恰是利用此对Android系统进行远程监控或恶意扣费等。我们可以批准应用程序上网的权限,但我们能够限制应用程序可以访问站点的范围,比如我们可以建立白黑名单制度,再如发短信,我们可以指定应用程序向哪些号码发送短信,而这些工作难度确实比较大,我还在继续研究中。


  相关解决方案