Android 安全访问机制

鉴客 发布于 2011/11/18 14:01
阅读 260
收藏 0

Android是一个多进程系统,在这个系统中,应用程序(或者系统的部分)会在自己的进程中运行。系统和应用之间的安全性通过Linux的 facilities(工具,功能)在进程级别来强制实现的,比如会给应用程序分配user ID和Group ID。更细化的安全特性是通过"Permission"机制对特定的进程的特定的操作进行限制,而"per-URI permissions"可以对获取特定数据的access专门权限进行限制。 所以,应用程序之间的一般是不可以互相访问的,但是anroid提供了一种permission机制,用于应用程序之间数据和功能的安全访问。

1.安全架构
Android安全架构中一个中心思想就是:应用程序在默认的情况下不可以执行任何对其他应用程序,系统或者用户带来负面影响的操作。这包括读或写用户的私有数据(如联系人数据或email数据),读或写另一个应用程序的文件,网络连接,保持设备处于非睡眠状态。
一个应用程序的进程就是一个安全的沙盒。它不能干扰其它应用程序,除非显式地声明了“permissions”,以便它能够获取基本沙盒所不具备的额外的能力。它请求的这些权限“permissions”可以被各种各样的操作处理,如自动允许该权限或者通过用户提示或者证书来禁止该权限。应用程序 需要的那些“permissions”是静态的在程序中声明,所以他们会在程序安装时被知晓,并不会再改变。
所有的Android应用程序(。apk文件)必须用证书进行签名认证,而这个证书的私钥是由开发者保有的。该证书可以用以识别应用程序的作者。该证书也不需要CA签名认证(注:CA就是一个第三方的证书认证机构,如verisign等)。Android应用程序允许而且一般也都是使用self- signed证书(即自签名证书)。证书是用于在应用程序之间建立信任关系,而不是用于控制程序是否可以安装。签名影响安全性的最重要的方式是通过决定谁可以进入基于签名的permisssions,以及谁可以share 用户IDs。

2.用户IDs和文件存取
每一个Android应用程序(。apk文件)都会在安装时就分配一个独有的Linux用户ID,这就为它建立了一个沙盒,使其不能与其他应用程序进行接触(也不会让其它应用程序接触它)。这个用户ID会在安装时分配给它,并在该设备上一直保持同一个数值。
由于安全性限制措施是发生在进程级,所以两个package中的代码不会运行在同一个进程当中,他们要作为不同的Linux用户出现。我们可以通过 使用AndroidManifest。xml文件中的manifest标签中的sharedUserId属性,来使不同的package共用同一个用户 ID。通过这种方式,这两个package就会被认为是同一个应用程序,拥有同一个用户ID(实际不一定),并且拥有同样的文件存取权限。注意:为了保持安全,只有当两个应用程序被同一个签名签署的时候(并且请求了同一个sharedUserId)才会被分配同样的用户ID。
所有存储在应用程序中的数据都会赋予一个属性——该应用程序的用户ID,这使得其他package无法访问这些数据。当通过这些方法 getSharedPreferences(String, int),openFileOutput(String, int)或者 openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory)来创建一个新文件时,你可以通过使用MODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLE标志位来设置是否允许其他package来访问读写这个文件。当设置这些标志位时,该文件仍然属于该应用程序, 但是它的global read and/or write权限已经被设置,使得它对于其他任何应用程序都是可见的。
例如:APK A 和APK B 都是C公司的产品,那么如果用户从APK A中登陆成功。那么打开APK B的时候就不用再次登陆。 具体实现就是A和B设置成同一个User ID:

这个"com.c" 就是user id。 APK B就可以像打开本地数据库那样打开APK A中的数据库了。APK A把登陆信息存放在A的数据目录下面。APK B每次启动的时候读取APK A下面的数据库判断是否已经登陆:

3.权限
权限用来描述是否拥有做某件事的权力。Android系统中权限分为普通级别(Normal),危险级别(dangerous),签名级别 (signature)和系统/签名级别(signature or system)。系统中所有预定义的权限根据作用的不同,分别属于不同的级别。
对于普通和危险级别的权限,我们称之为低级权限,应用申请即授予。其他两级权限,我们称之为高级权限或系统权限,应用拥有platform级别的认证才能申请。当应用试图在没有权限的情况下做受限操作,应用将被系统杀掉以警示。
系统应用可以使用任何权限。权限的声明者可无条件使用该权限。
目前Android系统定义了许多权限,通过SDK文档用户可以查询到哪些操作需要哪些权限,然后按需申请。
为了执行你自己的权限,你必须首先在你的AndroidManifest.xml中使用一个或多个<permission> 标签声明。例如,一个应用程序想用控制谁能启动一个activities,它可以为声明一个做这个操作的许可,如下:

4.使用权限
应用需要的权限应当在users-permission属性中申请,所申请的权限应当被系统或某个应用所定义,否则视为无效申请。同时,使用权限的申请需要遵循权限授予条件,非platform认证的应用无法申请高级权限。
所以,程序间访问权限大致分为两种:
-第一种低级点的(permission的protectlevel属性为normal或者dangerous),其调用者apk只需声明<uses-permission>即可拥有其permission。
-第二种高级点的(permission的protectlevel属性为signature或者signatureorsystem),其调用者apk就需要和被调用的apk一样拥有相同的signature。
若想拥有使用权限,必须在AndroidManifest.xml文件中包含一个或更多的<uses-permission> 标签来声明此权限。

应用程序安装的时候,应用程序请求的permissions是通过package installer来批准获取的。package installer是通过检查该应用程序的签名来确定是否给予该程序request的权限。在用户使用过程中不会去检查权限,也就是说要么在安装的时候就批准该权限,使其按照设计可以使用该权限;要么就不批准,这样用户也就根本无法使用该feature,也不会有任何提示告知用户尝试失败。
例如高级权限用有system级别权限设定的api时,需要使其apk拥有system权限。比如在 android 的API中有供给SystemClock.setCurrentTimeMillis()函数来修改系统时间。有两个方法:

第一个方法简单点,不过需要在Android系统源码的情况下用make来编译:
1. 在应用程序的AndroidManifest.xml中的manifest节点中插手android:sharedUserId="android.uid.system"这个属性。
2. 修改Android.mk文件,插手LOCAL_CERTIFICATE := platform这一行
3. 使用mm命令来编译,生成的apk就有修改系统时间的职权范围了。

第2个方法麻烦点,不外不消开虚拟机跑到源码情况下用make来编译:
1. 同上,插手android:sharedUserId="android.uid.system"这个属性。
2. 使用eclipse编译出apk文件,但是这个apk文件是不能用的。
3. 使用针系统的platform密码钥匙来从头给apk文件签名。signapk platform.x509.pem platform.pk8 input.apk output.apk

加载中
返回顶部
顶部