SELinux概述

      SELinux 即Security-Enhanced Linux, 由美国国家安全局(NSA)发起, Secure Computing Corporation (SCC) 和 MITRE 直接参与开发, 以及很多研究机构(如犹他大学)一起参与的强制性安全审查机制, 在Linux Kernel 2.6 版本后, 有直接整合入SELinux, 搭建在Linux Security Module(LSM)基础上, 目前已经成为最受欢迎,使用最广泛的安全方案.

      SELinux 是典型的MAC-Mandatory Access Controls 实现, 对系统中每个对象都生成一个安全上下文(Security Context), 每一个对象访问系统的资源都要进行安全上下文审查。审查的规则包括类型强制检测(type enforcement), 多层安全审查(Multi-Level Security), 以及基于角色的访问控制(RBAC: Role Based Access Control).

由于涉及内容太多,英语好的可研究下:http://selinuxproject.org 。我根据自己理解,把认为重要的理一下,最后贴上使用的实例,方便大家理解

Linux DAC 与 MAC

为更好理解SELinux,下面简单介绍下Linux DAC 和 MAC

1. DAC 即 Discretionary Access control, 自主访问控制, 即系统只提供基本的验证, 完整的访问控制由开发者自己控制

2. MAC 即 Mandatory Access control, 强制性访问控制, 即系统针对每一项访问都进行严格的限制, 具体的限制策略由开发者给出

3. Linux DAC 采用了一种非常简单的策略, 将资源访问者分成三类, 分别是Owner, Group, Other; 资源针对这三类访问者设置不同的访问权限. 而访问权限又分成 read, write, execute. 访问者通常是进程有自己的uid/gid, 通过uid/gid 和 文件权限匹配, 来确定是否可以访问

4. Linux MAC 针对DAC 的不足, 要求系统对每一项访问, 每访问一个文件资源都需要进行针对性的验证. 而这个针对性的验证是根据已经定义好了的策略进行.

可见MAC可以明显弥补DAC 的缺陷, 一方面限制Root 权限, 即使你有root 权限, 如果无法通过MAC 验证, 那么一样的无法真正执行相关的操作. 另外对每一项权限进行了更加完整的细化, 可限制用户对资源的访问行为。

此时的访问流程如下:

1. 进程通过系统调用(System Call) 访问某个资源, 进入Kernel 后, 先会做基本的检测, 如果异常则直接返回.

2. Linux Kernel DAC 审查, 如果异常则直接返回.

3. 调用Linux Kernel Modules 的相关hooks, 对接到SELinux 的hooks, 进而进行MAC 验证, 如果异常则直接返回.

4. 访问真正的系统资源.

5. 返回用户态, 将结构反馈.

SELinux在Android的更新过程及带来的影响

更新过程

android4.4 部分开启,即针对netd, installd, zygote, vold 四个原本具有root 权限的process, 以及它们fork 出的子进程启用Enforce 模式.

androidL 版本普遍性开启SELinux Enforce mode.

带来的影响.

1. 严格限制了ROOT 权限, 以往ROOT “无法无天” 的情况将得到极大的改善.

2. 通过SELinux 保护, 降低系统关键进程受攻击的风险, 普通进程将没有权限直接连接到系统关键进程.

3. 进一步强化APP 的沙箱机制, 确保APP 难以做出异常行为或者攻击行为.

4. 将改变APP 一旦安装, 权限就已经顶死的历史, APP 权限动态调整将成为可能.

SELinux Mode

SELinux 分成两种模式, 即Permissve Mode(宽容模式), 和 Enfocing mode(强制模式).

1. Permissive Mode 只通过Audit System 记录LOG, 但不真正拦截访问.

2. Enforcing Mode 在打印LOG 的同时,还会真正的拦截访问.

SELinux Commands 和 SELinux Policy Path

Commands介绍两个基本的,其他的请查看官方文档

1. getenforce  得到当前模式

2. setenforce 0 — 设置permissive模式

3. setenforce 1 — 设置enforcing模式

以上指令在调试和跟踪问题时经常用到

SELinux Policy路径

Google Original: alps/external/sepolicy/XXX.te  (通常不建议修改)

各个平台自己一般也有个sepolicy路径

最终的Policy会用合并的方式编译在一起,修改时上面两个路径下的文件都可以参考

如何确认问题是否与selinux相关

在添加新设备或为一设备添加新权限时,有时会报错,如何确认问题是否与selinux相关

1. 将SELinux 调整到Permissive 模式测试.

将SELinux 模式调整到Permissive 模式,然后再测试确认是否与SELinux 约束相关.

ENG 版本:

adb shell setenforce 0

如果还能复现问题,则与SELinux 无关, 如果原本很容易复现, 而Permissive mode 不能再复现, 那么就可能关系比较大.

2. 查看LOG 中是否有标准的SELinux Policy Exception.

在Kernel LOG / Main Log 中查询关键字 "avc:" 看看是否有SELinux Policy Exception, 并进一步确认这个异常是否与当时的逻辑相关.

修改的一些规则

1. 维持external/sepolicy 与Google AOSP一致, 尽量不要修改. 特别是不要去除任何的neverallow 语句.

2. 严禁修改untrusted_app.te, 放开untrusted_app 的权限.

3. 系统关键进程启动长时间运行的process, 必须进行domain 切换. 比如netd, installd, vold, zygote 等.

4. Native thread 严禁使用kernel 标签,  而kernel thread 除init 外,  都应当是kernel 标签.

5. 在user build 中不能存在如su, recovery, init_shell 标签的进程.

6. 在user build 中所有的process 都必须是Enforce Mode

demo介绍

当新添加一个system service,如TestService(比如新增一设备,要用该service来管理/交互),该system service中会读写新增的节点/sys/test_properties。下面是简单的修改过程,其他负责的类似,可参考。

1. service.te中添加

type test_service,      service_manager_type;

2. service_contexts中添加

test          u:object_r:system_server_service:s0

3. 该目录下添加test.te

type exec_type, file_type;

type test ,domain;

init_daemon_domain(test)

binder_use(test)

binder_call(test, binderservicedomain)

binder_service(test)

allow test testPro:file { read write ioctl open };

allow test test_service:service_manager add;

4. file.te中添加

type testPro, file_type;

5. file_contexts中添加

/sys/test_properties u:object_r:testPro:s0

这样看下来是不是更容易理解呢。SELinux深入研究很庞大,但理解和使用是第一步。所以希望大家多多交流吧。

9 2

共收到2条回复

suihansong 644天前 #1楼

提个建议,极客学院赶紧把社区这功能优化好。上次是发布时没反应,按了几下F5结果发布了几个一样的。这次是写完点发布,提示成功并跳转,但找不到我发布的内容,费了半天劲的还得重新来,太令人崩溃了。

0 评论

suihansong 644天前 #2楼

忘了 @靠谱儿活动君 ,哈哈

0 评论

加入小组与大家一起讨论吧