Android安全机制之设备管理

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系统最大的安全隐患，正是来自于设备驱动。