Android安全机制之设备管理

本文转载自：
http://blog.sina.com.cn/s/blog_606334a20100gmxo.html

Android安全机制之设备管理 (2009-12-30 02:20:57)转载▼
标签： android 安全 设备管理 it 分类： programming
Andoid安全机制包括两个层次：系统层和应用层。应用层的安全机制建立在授权与申请基础上，本文不讲。系统层的安全机制包括给每个用户进程分配单独的uid和gid，使用进程本身可以防止地址空间的共享，从而避免使用线程方式对数据的全局可见性。使用了uid则对于外存也加了封锁，当然这得感谢UNIX的用户空间机制。系统层安全机制还包括对设备访问的控制，在这个方面，Android的做法与传统有所不同。

Android除了给予用户进程以单独的uid外，给系统服务也分配了固定的uid，诸如system/core/include/private/android_filesystem_config.h文件中定义了这些固定的uid：

define AID_SYSTEM 1000

define AID_RADIO 1001

define AID_BLUETOOTH 1002

define AID_GRAPHICS 1003

define AID_INPUT 1004

define AID_AUDIO 1005

define AID_CAMERA 1006

define AID_LOG 1007

………………………………..

传统的做法是，出了root，其它全是普通用户，两类用户的权限在内核里是规定死的，这也保证了UNIX内核的安全性。比如dev目录下的设备文件，一般用户主是root，而且对其他用户不开放读写能力。用户使用设备一般通过系统调用如ioctl，而系统调用属于受信代码。

Android的问题是，引入的这些系统用户，实际上在权限方面是无法与普通uid区分的，如果系统用户能访问一个设备，那么一般用户也能。所以，Andoid没有别的选择，只能默认开启设备文件的全局读写。这在systemcore/init/device.c做 了定义：

{ "/dev/urandom",       0666,   AID_ROOT,       AID_ROOT,       0 },
{ "/dev/ashmem",        0666,   AID_ROOT,       AID_ROOT,       0 },
{ "/dev/binder",        0666,   AID_ROOT,       AID_ROOT,       0 },

设备文件当然还是存放于/dev目录下，但dev目录的填充不是由udev做的，而是由Android的init进程做的。这个步骤由make_device函数完成，各个设备的权限来自于上述device.c文件的规定。

这种设备权限分配的潜在危险是，任何用户进程都可以操作设备，如果底层设备驱动有漏洞，那么整个系统的安全性就是存在风险的，而UNIX系统最大的安全隐患，正是来自于设备驱动。