[置顶] Android访问控制系统测试与评估
5.1实验方案
通过以上章节，本文阐述了目前Android平台上的恶意软件以“隐私窃取”和“恶意扣费”类为主，本研究课题访问控制的目标也正是阻止恶意软件“隐私窃取”和“恶意扣费”的行为，因此，本实验方案选取良性软件和恶意软件，分别针对拨打电话、发送短信、联网、访问sd卡、访问通讯录、查看短信行为进行测试和分析。测试用例选取百度通讯录、360通讯录、酷狗音乐、DroidDream，实验环境为Ubuntu10.04和Android4.0模拟器以及相应的goldfish内核。
1. 测试360通讯录
360通讯录既可以打电话也可以发短信，因此为360通讯录分配“game”角色，由于“game”角色不能打电话、发短信，因此，当打开360通讯录时，如果这些功能都不能使用则符合预期结果。测试效果图如下所示：
图5.1360通讯录测试效果图1-不能查看短信和通讯录
2. 测试百度通讯录
百度通讯录功能和360通讯录相似，在此，为百度通讯录分配“contact”角色，那么如果它能够打电话和发短信，则符合预期效果。测试效果图如下所示：
3. 测试酷狗音乐
酷狗音乐是可以读取sd卡音乐文件进行播放，为此，给酷狗音乐分配“mediaplayer”角色，但不把它设置读写sd卡角色，那么如果它不能播放sd卡音乐文件则符合预期效果。测试效果图如下：
4. 测试DroidDream—Advanced File Manager和Super Ringtone Maker
DroidDream[18]是一款著名的Android平台上的恶意软件，它的最大特征之一是后台联网，泄露用户隐私。Advanced File Manager和SuperRingtone Marker是DroidDream系列的两款款恶意软件，前者它用于文件管理，可以访问sd卡，后者用于铃声制作，可以访问Internet。新建角色“Malware”，并只给该角色一个访问摄像头的权限，将“Malware”角色分配给AdvancedFile Manager和Super Ringtone Maker。测试效果图如下：
5.3实验分析
1. 360通讯录测试分析
由于为360通讯录分配了“game”角色，而此角色关联的smack规则已经禁止担任“game”角色的App拨打电话、发送短信、访问通讯录等行为，因此无法用360通讯录查看通讯录、短信等内容。下图为使用“adb shell”查看/smack/load里内容：
图5.8Android模拟器启动后smack/load中的smack规则
360通讯录的uid为10034，从上图可以看出smack规则“10034 1001 -”已经禁止它与radio进程通信，因此360通讯录不能发送短信。若使用360通讯录发送短信，360通讯录会提示“发送失败”的信息，查看Android的logcat会有如下的信息：
从上图可以看出，smack标签是“10034”的360通讯录进程无法在BinderDriver中与radio通信，那么360通讯录进程就无法实现发短信。
当用户在键盘上输入不是通讯录里号码时，出现拨号结束的画面，这是因为本课题已经对radio进行访问控制，拨打或发送不是通讯录中号码的打电话和发短信的行为都被阻止。当拨打电话时，出现了拨号界面，这是因为尽管“10034 1001 -”被写入/smack/load文件，但此时拨号的Activity是运行在1001进程，如果使用smackload工具在/smack/load写下smack规则“1001 _ -”，那么拨号界面的读秒行为终止，电话无法拨打。这是因为本课题在IPC中加了访问控制，而打电话是radio和rild进程在binder中通信，而rild（radiointerface layer daemon）进程的安全标签是“_”，因此如果有“1001 _ -”这样的规则，radio和rild无法通信，那么拨号过程终止。如果用户不给“game”拨打电话的权限，那么360仍然无法拨号，这是由于框架层的RBAC机制起了作用，它会在开启拨号的Activity之前对此Activity按照uid和申请的权限进行权限检查，如果此组件没有拨打电话权限，那么拨号的Activity不会出现。
2. 百度通讯录测试分析
百度通讯录的uid为10037，通讯录进程的uid为10000，因为/smack/load有规则“10037 10000 rwxa”，所以在百度通讯录中用户可以看到通讯录。由于181不是通讯录里的号码，所以用百度通讯录向这个号码发送短信会失败，号码666是通讯录里的号码，所以用百度通讯录向这个号码发送短信会成功。
3. 酷狗音乐测试分析
由于sd卡里文件都被打上了“sdcard”安全标签，而酷狗音乐没有被分配读写sd卡角色，因此，酷狗音乐无法打开sd卡里的音乐。
4. DroidDream测试分析
由于“Malware”角色只有一个访问摄像头的权限，因此担任“Malware”角色的App除了能够使用摄像头，不能使用其它权限。从测试结果可以看出：使用File Manager查看sd卡里文件长度都是0B，这说明了File Manager不能访问sd卡。同样，Super Ringtone Maker软件有一个功能是搜索互联网，而这个功能也不能用了，框架层的RBAC已经把相应的权限拒绝了，以下为“adb logcat”里内容：
系统评估
1. 功能评估
通过以上实验验证，本系统不仅能够通过定制角色限制权限，而且使用smack规则对内核的进程实施了强制访问控制，因此本系统能够保护用户隐私数据和阻止“恶意扣费”等行为，下表将国外典型的Android安全加固技术成果与本系统进行了功能对比：
表5.1 国外典型技术成果与本系统功能对比
|
|
安全策略可定制 |
限制权限 |
内核加固 |
上下文支持 |
阻止提权攻击 |
|
CRePE |
是 |
是 |
否 |
是 |
否 |
|
Apex |
是 |
是 |
否 |
是 |
否 |
|
SEAndroid |
是 |
是 |
是 |
否 |
是 |
|
本系统 |
是 |
是 |
是 |
否 |
否 |
CRePE和Apex的安全机制共同特点是基于Android权限检查机制，因此，它们的安全机制都可以被恶意软件利用Android系统漏洞或者使用Linux系统调用而直接绕过，本课题不仅在Android权限基础上实现了RBAC，而且使用了Smack模块实现了对Linux进程的控制，因此，本系统比CRePE和Apex具备更高的安全性。SEAndroid是一个“重量级”的Android安全增强系统，它要求智能手机配置较高，不太适合普通Android手机用户，而本系统采用的轻量级访问控制模块Smack作为Android内核访问控制机制，由于Smack对Android系统性能损耗很小，因此，本系统比SEAndroid在性能上有优势，虽然本系统有着以上优点，但本系统也有一些缺陷：
第一，本系统的一部分访问控制是基于Zygote模块，但Zygote不会重复“fork”相同uid的进程，因此，当用户在定制安全策略时，本系统的强制访问控制未必及时生效，比如当某个App被启动后，它的进程一直会存在，而不会被Zygote重复“fork”，因此这个App的smack规则不会被更新，只有让模拟器重启，Zygote进程重新装载smack安全策略；
第二，本系统没有考虑到上下文环境，用户在制定安全策略时，会出现“要么容许，要么拒绝”这种情况，因此，本系统下一步工作就是将上下文考虑进来；
第三，本系统的访问控制对特权进程失效。由于Smack安全模块不能阻止Linux超级用户或进程一切行为，因此，当Android手机被“root”后，本系统的访问控制将失效；
第四，本系统没有考虑审计。审计是保障计算机系统安全的重要手段，Smack内核本身就提供了审计功能，如果本系统在此基础上设计入侵检测模块，那么Android系统的安全性将进一步增强。
