SEandroid 安全机制---整体框架

在Java层和native守护进程socket通信一文中,新建了一个名为myguard的socket。然后修改了5个权限相关的文件,1,在device/qcom/sepolicy/common/路径下添加myguard.te文件,内容如下,#myguardallowmyguard_socketmyguard_socket:sock_filecreate_file_perms;type_transitio...

在Java层和native守护进程socket通信一文中,新建了一个名为myguard的socket。然后修改了5个权限相关的文件,

1,在device/qcom/sepolicy/common/路径下添加myguard.te文件,内容如下,

2,在device/qcom/sepolicy/common/的file_contexts文件中添加

3,在device/qcom/sepolicy/common/file.te中添加

4,在device/qcom/sepolicy/common/system_app.te中添加

5,在device/qcom/sepolicy/common/system_server.te中添加

编译刷入版本开机启动之后,在dev/ socket路径下出现myguard

还不是SEAndroid安全机制!

在引进SEAndroid安全机制之前，Android系统的安全机制分为应用程序和内核两个级别。

应用程序级别的安全机制就是通常说的Permission机制。一个应用如果需要访问一些系统敏感或者特权资源，

那么就必须要在AndroidManifest.xml配置文件中进行申请，并且在安装的时候由用户决定是否赋予相应的权限(android 5.0),

或者在apk运行的时候由用户决定是否赋予相应的权限(android 6.0)。

内核级别的安全机制就是传统的Linux UID/GID机制。在Linux中，每一个用户都拥有一个用户ID，并且也有一个用户组ID，

分别简称为UID和GID。此外，Linux系统的进程和文件也有UID和GID的概念。Linux就是通过用户、进程、

文件的UID/GID属性来进行权限管理的。文件的权限控制在所有者的手中。因此，这种权限控制方式就称为自主式的，

正式的英文名称为Discretionary Access Control，简称为DAC。

例如, myguard设置为660(二进制110 110 000)对应 rw- rw----

对于root用户,该socket可读可写；对于同组的其他用户,该socket可读可写；对于其他用户,该socket不可读也不可写。

为什么会有这2个机制呢,因为一些别有用心的为达目的不择手段;为什么还要有SEAndroid安全机制呢?

因为前面2个机制已经无法阻止一些素丧心病狂的开发人员了。

SEAndroid安全机制与传统的Linux UID/GID安全机制是并存关系的，也就是说，它们同时用来约束进程的权限。

当一个进程访问一个文件的时候，首先要通过基于UID/GID的DAC安全检查，接着才有资格进入到基于SEAndroid的MAC安全检查。

只要其中的一个检查不通过，那么进程访问文件的请求就会被拒绝。上述的安全检查过程如图所示：

SEAndroid安全机制的整体框架如下,

以SELinux文件系统接口为边界，SEAndroid安全机制包含有内核空间和用户空间两部分支持。

在内核空间，主要涉及到一个称为SELinux LSM的模块。而在用户空间中，涉及到Security Context、Security Server

和SEAndroid Policy等模块。这些内核空间模块和用户空间模块的作用以及交互如下所示：

1.内核空间的SELinux LSM模块负责内核资源的安全访问控制。

2.用户空间的SEAndroid Policy描述的是资源安全访问策略。系统在启动的时候，用户空间的Security Server

需要将这些安全访问策略加载内核空间的SELinux LSM模块中去。这是通过SELinux文件系统接口实现的。

3.用户空间的Security Context描述的是资源安全上下文。SEAndroid的安全访问策略就是在资源的安全上下文基础上实现的。

4.用户空间的Security Server一方面需要到用户空间的Security Context去检索对象的安全上下文，另一方面也需要到内核空间去操作对象的安全上下文。

5.用户空间的selinux库封装了对SELinux文件系统接口的读写操作。用户空间的Security Server访问内核空间的SELinux LSM模块时，

都是间接地通过selinux进行的。这样可以将对SELinux文件系统接口的读写操作封装成更有意义的函数调用。

6.用户空间的Security Server到用户空间的Security Context去检索对象的安全上下文时，同样也是通过selinux库来进行的。

内核中的资源在访问的过程中，一般需要获得三次检查通过：

1.一般性错误检查，例如访问的对象是否存在、访问参数是否正确等。

2. DAC检查，即基于Linux UID/GID的安全检查。

3. SELinux检查，即基于安全上下文和安全策略的安全检查。

在用户空间中，SEAndroid包含有三个主要的模块，分别是安全上下文（Security Context）、

安全策略（SEAndroid Policy）和安全服务（Security Server）。

1.2.1安全上下文

SEAndroid是一种基于安全策略的MAC安全机制。这种安全策略又是建立在对象的安全上下文的基础上的。

这里所说的对象分为两种类型，一种称主体（Subject），一种称为客体（Object）。主体通常就是指进程，

而客观就是指进程所要访问的资源，例如文件、系统属性等。

安全上下文实际上就是一个附加在对象上的标签（Tag）。这个标签实际上就是一个字符串，它由四部

分别是SELinux用户、SELinux角色、类型、安全级别，每一个部分都通过一个冒号来分隔，格式为“user:role:type:sensitivity”。

例如,

myguard socket的安全上下文是 u:object_r: myguard_socket:s0

这表明文件myguard的SELinux用户、SELinux角色、类型和安全级别分别为u、object_r、myguard_socket和s0。

其他三个不重要,主要看SELinux类型。

资源的SELinux类型和进程的SELinux类型就像映射关系,当然并不止一一映射。

只有符合资源规定的SELinux类型的进程才可以访问资源。

例如下面这段话的意思是只有系统服务才可以读写myguard_socket类型的文件,即是读写myguard socket。

在android系统中,安全上下文的SELinux类型声明一般有2种,描述进程的是domain,描述文件的是file_type。

但是自己写的守护进程myguardservice的SELinux类型怎么是init? myguard socket怎么是myguard_socket类型?

external/sepolicy/init.te文件的init类型定义如下,

原来init还是domain类型的,就像狗是动物一样。

同样的,在device/qcom/sepolicy/common/file.te中myguard_socket也是file_type类型的。

类似于继承关系,一方面维护独立性,另一方面又维护统一性。

了解了SEAndroid安全机制的安全上下文之后，就可以继续分析Android系统中的对象的安全上下文是如何定义。

这里只讨论四种类型的对象的安全上下文，分别是系统进程、数据文件、系统文件和系统属性。

这些描述安全上下文的文件一般位于external/sepolicy目录中,当然各大厂商可能不一样。

反正就是一条,安全上下文的SELinux类型规定了资源文件只能由特定进程访问。

1.2.2.安全策略

上面分析了SEAndroid安全机制中的对象安全上下文，接下来就继续分析SEAndroid安全机制中的安全策略。

SEAndroid安全机制中的安全策略是在安全上下文的基础上进行描述的，也就是说，它通过主体和客体的安全上下文，定义主体是否有权限访问客体。

在external/sepolicy目录中(或者其他目录)，所有以.te为后缀的文件经过编译之后，就会生成一个sepolicy文件。

这个sepolicy文件会打包在ROM中，并且保存在设备上的根目录下，即它在设备上的路径为/sepolicy。

保存在这个sepolicy文件中的安全策略是不会自动加载到内核空间的SELinux LSM模块(内核空间)去的。

它需要在系统启动的过程中进行加载。

系统中第一个启动的进程是init进程。知道，Init进程在启动的过程中，执行了很多的系统初始化工作，

其中就包括加载SEAndroid安全策略的工作，init.cpp文件中的main方法有关selinux代码如下,

（编辑：52刷机网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!