Android安全机制分析与解决方案初探

Android安全机制分析与解决方案初探
文本预览:

示 在 屏 幕 列 上。用户要么同意安装, 要么中止安装。 同意安装 意味着授权所有被请求的权限。 (3) ICC( intercomponent communication) 权限保 护: < application > 元 素 和 组 件 元 素 都 有 android: permission 的属性, 在这里我们称这个属性分别为应 用程序和组件的权限标签。 应用程序内的组件可 以继承应用程序元素设置的权限标签 。 当某一组 件启动 ICC 时, 相关的访问控制器就会查看组件和 组件所在应用程序的权限标签集合。 如目标组件

[3 ]

的访问权限标签在以上的集合内, 允许 ICC 的建立 否则将会被拒绝, 即使这两个组件在同 继续进行, 一应用程序内。图 3 描述了该逻辑的进程: 组件 A 是否可以访问组件 B 和 C, 取决于比较 B 和 C 内的 访问权限标签与应用程序 1 内的标签集合的结果。 B 和应用程序 1 内都有 i1 标签, 所以组件 A 可以访 相反应用程序 1 内没有标签 i2, 组件 A 不 问组件 B, 可以访问组件 B

[4 ]

图3

ICC 访问权限逻辑

②防护等级 防护等级是权限的一个属性, 它决定了权限怎 样被授权。 现今的 Android 安全架构支持四种防护 dangerous、 signature 和 signatureOrSys等级: normal、 tem。 (1) Normal:不是特别危险的权限拥有, 在程序 安装时, 此等权限隐藏在屏幕折叠的菜单内 。 (2) Dangerous:一个可能提供访问私有数据或 如果没有用户的 有害功能的高危险度的权限拥有, 明确证实, 应用程序将不会接受这种权限, 程序安 此等权限明显地罗列在屏幕上。 装时, (3) Signature: 当请求该权限的应用程序与声 明该权限的应用程序拥有相同的数字证书签名时 , 才会授权该权限。 (4) signatureOrSystem:一种特殊的 Signature 权 限, 只会授权给安装在 Android 系统镜像的包。 ③一个不容忽视的缺陷 Android 权限体制有一些很小但不容忽视的缺 点, 它表现在以下情况中: (1) 应用程序可以自由地命名一个新的权限, 无须遵循一定的命名规则和限制。 期盼用户对不 同应用程序 ( 包括未曾安装过的程序 ) 所使用的任 意给定的权限名称保持警觉是不够明智的 。 (2) 权限一经被授权给应用程序后, 在应用程

26 期

廖明华, 等:Android 安全机制分析与解决方案初探

6353

序的生命期间, 它将不会被移除, 即使声明此权限 的源程序被删除。 (3) 一个系统内两个不同的权限可以共用相同 的名字, 以至于他们中的其中一个权限可以在未声 明的前提下正常使用 2. 1. 2 组件包装

[5 ]

用等。

3

安全解决方案

1] 文献[ 提出许多减轻恶意软件损害移动设备

的方法。根据这些方法在 Google Android 上被实施 我

寻找更多 "Android安全机制分析与解决方案初探"