SEAndroid安全机制对Binder IPC的保护分析.docVIP

SEAndroid安全机制对Binder IPC的保护分析 在SEAndroid安全机制中，除了文件和属性，还有Binder IPC需要保护。Binder IPC是Android系统的灵魂，使用得相当广泛又频繁。例如，应用程序都是Binder IPC请求访问系统服务和资源。因此，SEAndroid安全机制必须要为Binder IPC保驾护航，阻止一个进程非法访问其它进程的服务和资源。本文就详细分析SEAndroid安全机制对Binder IPC提供的支持。 关于Binder IPC的知识，可以参考这个系列的文章。SEAndroid安全机制对Binder IPC的保护实现在Binder驱动中，如图1所示： 从图1可以看到，当Service Manager将自己注册为Context Manager时，Binder驱动会检查它是否具有设置Context Manager的SEAndroid安全权限。Service Manager将自己注册为Context Manager的过程，可以参考前面一文。 此外，当Client通过Binder驱动请求与Server发送通信时，Binder驱动会检查Client是否具有与Server通信的SEAndroid安全权限。如果Client与Server的通信数据带有Binder对象或者文件描述符，那么Binder驱动还会进一步检查源进程是否具有向目标进程传输Binder对象或者文件描述符的SEAndroid权限。Client与Server的通信过程可以参考前面一文。 以上提到的与Binder IPC相关的SEAndroid安全权限定义在内核的SELinux模块的数组secclass_map中，如下所示： [cpp] view plain copy struct security_class_mapping secclass_map[] = { ...... { binder, { impersonate, call, set_context_mgr, transfer, NULL } }, ...... }; 这个数组定义在文件kernel/goldfish/security/selinux/include/classmap.h中。 数组secclass_map列出的Binder IPC相关的SEAndroid权限有四种，分别是impersonate、call、set_context_mgr和transfer。其中，call、set_context_mgr和transfer就对应我们前面说的Client与Server通信、设置Context Manager和传输Binder对象权限。 数组secclass_map没有列出传输文件描述符的权限，是因为传输文件描述符权限实质上是属于文件读写相关的权限，也就是检查目标进程是否具有访问在通信数据附带的文件描述符所描述的文件的权限，这属于文件类别的SEAndroid安全权限。 同时，数组secclass_map多出了一个impersonate权限。当进程1代表进程2与进程3执行Binder IPC时，Binder驱动需要检查进程1是否具有模拟进程2的impersonate权限。目前，不会发生一个进程代表另外一个进程与目标进程执行Binder IPC的情况，因此，impersonate权限实际上是没有使用到的。 在SEAndroid安全策略中，定义有一个名称为unconfineddomain的domain，它具有上述的call、set_context_mgr和transfer权限，如下所示： [plain] view plain copy 在CODE上查看代码片派生到我的代码片 allow unconfineddomain domain:binder { call transfer set_context_mgr }; 上述安全策略定义在文件external/sepolicy/unconfined.te中。 在Android系统中，所有类型的应用程序进程的domain都具有unconfineddomain属性，如下所示： [plain] view plain copy 在CODE上查看代码片派生到我的代码片 # # Apps signed with the platform key. # type platform_app, domain; ...... unconfined_domain(platform_app) # Apps signed