Android安全机制.docx

关键词：Sandbox（沙盒机制）Permission（权限机制）SELinux MAC机制（强制访问控制机制）ALSR（地址空间分配随机化）PIE（独立位置的可执行区域（position-independent executables））FORTIFY_SOURCE（内存溢出检查）Encrypt（加密）Certificate（证书验证，签名机制）签名机制apk文件在发布时必须被签名（用私钥）。签名标识应用的作者，建立应用之间的信任关系。比如微信和qq是同一个开发者，是一个私钥，所以两者相互信任，可以相互获取信息。使用相同私钥签名的应用，将会具备相同的UID。关于签名的安全机制还有，如果两个应用包名相同，但是签名不同，是无法覆盖安装的。比如你修改了qq，原先的正版没卸载，修改版是安不上去的。在安装应用程序APK时，系统安装程序首先检查APK是否被签名，有签名才能够安装。当应用程序升级时，需要检查新版应用的数字签名与已安装的应用程序的签名是否相同，否则，会被当作一个全新的应用程序。通常，由同一个开发者设计的多个应用程序可采用同一私钥签名，在manifest文件中声明共享用户ID，允许它们运行在相同的进程中，这样一来，这些应用程序可以共享代码和数据资源。Android开发者们有可能把安装包命名为相同的名字，通过不同的签名可以把它们区分开，也保证了签名不同的包不被替换掉，同时有效地防止了恶意软件替换安装的应用。弊端：Android自签名机制允许开发人员发布未经应用市场验证的APP，从而导致应用市场鱼龙混杂。沙盒机制多应用模型不同应用分配不同的UID不同应用运行不同的进程系统应用的沙盒机制Dalvik虚拟机为每个应用提供一个虚拟机实例运行一个进程。为每个应用创建一个对应于Linux底层的用户名。应用是虚拟机实例，相互独立（沙盒的意义），当应用出现问题，可以通过消除该虚拟机实例来保证系统的安全运行。可通过设置AndroidManifest文件中manifest标签内的ShareUserID属性。拥有同一UserID，被认为是同一应用程序，只有两个具有相同签名的应用程序而且请求相同的shareUserID属性的时候，才会分配相同的UserID。弊端：仍然没有办法避免某些恶意应用程序通过自签名和更改相同shareUserID属性获得相同UserID。权限机制 PermissionAndroid 应用程序安全的核心机制是权限控制。应用程序必须在系统给予的权限中运行，不得访问未被赋予权限的其它任何内容。程序安装时由包管理器赋予权限，运行时由应用程序框架层执行权限控制。Android内置大约有一百多种行为或服务的权限控制，包括打电话、发短信息、访问互联网等。应用程序在安装时必须申明其运行时需获得的权限，Android 通过检查签名和与用户的交互赋予相应权限。权限的申请只能在安装时得到批准或拒绝，在运行过程中不得再申请任何权限。 弊端：应用程序可以自由地命名一个新的权限，无须遵循一定的命名规则和限制。权限一经被授权给应用程序后，在应用程序的生命期间，它将不会被移除，即使声明此权限的源程序被删除。一个系统内两个不同的权限可以共用相同的名字，以至于他们中的其中一个权限可以在未声明的前提下正常使用。Android 文件(包括应用程序文件和系统文件)管理属于Linux 权限机制。每个文件与用户ID 和用户组ID 以及三组Read / Write / eXecute(RWX)权限密切相关。文件在创建时将被赋予不同应用程序ID，从而只能被特定的应用程序所访问，非授权的其他应用程序则是不能访问，除非它们拥有相同的ID或者该文件的访问属性设置为在全局下都是可以读写的。另一个增强安全的设计：将镜像挂载为只读。比较重要的可执行程序和配置文件，只有在系统初始化的时候加载。 弊端：一般来说，无论是“system”还是“root”用户都拥有整个系统中文件访问权限，而一个特定的应用程序用户则拥有本身应用程序文件访问权限。仍然没有办法避免某些获取root权限的用户恶意访问文件系统。3、组件封装：exported属性一个Android系统中的应用可以在其程序内将其某些组成部分的内容封装，这样可以防止其他不同的用户ID的应用程序访问他们。这种功能实现主要是通过定义组件的“exported”属性。如果“exported”属性设置为“假”，则组件只能被通过应用程序本身所访问，或拥有同一个user工D的其他程序通过使用sharedUserId的特征来访问。反之，如果设置为“真”，则外部的实体可以调用或访问它。 弊端：用户设置错误导致组件被非授权访问。SEAndroid（MAC策略）在Linux系统中，文件的权限控制在所有者的手中。因此，这种权限控制方式就称为自主式的，正式的英文名称为Di