5.1实验方案
通过以上章节,本文阐述了目前Android平台上的恶意软件以“隐私窃取”和“恶意扣费”类为主,本研究课题访问控制的目标也正是阻止恶意软件“隐私窃取”和“恶意扣费”的行为,因此,本实验方案选取良性软件和恶意软件,分别针对拨打电话、发送短信、联网、访问sd卡、访问通讯录、查看短信行为进行测试和分析。测试用例选取百度通讯录、360通讯录、酷狗音乐、DroidDream,实验环境为Ubuntu10.04和Android4.0模拟器以及相应的goldfish内核。
5.2实验过程
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系统的安全性将进一步增强。