Android(安卓)SELinux
架构
从上层到驱动层的调用流程,但是我们重点关注sContext:
注:
-
file_contexts //系统中所有file_contexts安全上下文
-
seapp_contexts //app安全上下文
-
property_contexts //属性的安全上下文
-
service_contexts //service文件安全上下文
-
genfs_contexts //虚拟文件系统安全上下文
以上文件system/sepolicy中都有对应的内容,例如:通过adb shell ls –Z
指令查看文本的sContext,通过adb shell ps -Z
指令可以查看进程的sContext
背景
在 SELinux 出现之前,Linux 上的安全模型叫 DAC,全称是 Discretionary Access Control,翻译为自主访问控制。
DAC 的核心思想很简单,就是:进程理论上所拥有的权限与执行它的用户的权限相同。比如,以 root 用户启动 Browser,那么 Browser 就有 root 用户的权限,在 Linux 系统上能干任何事情。
显然,DAD 管理太过宽松,只要想办法在 Android 系统上获取到 root 权限就可以了。那么 SELinux 是怎么解决这个问题呢?在 DAC 之外,它设计了一种新的安全模型,叫 MAC(Mandatory Access Control),翻译为强制访问控制。
MAC 的理论也很简单,任何进程想在 SELinux 系统上干任何事情,都必须在《安全策略文件》中赋予权限,凡是没有出现在安全策略文件中的权限,就不行。
关于 DAC 和 MAC,可以总结几个知识点:
-
Linux 系统先做 DAC 检查。如果没有通过 DAC 权限检查,则操作直接失败。通过 DAC 检查之后,再做 MAC 权限检查。
-
SELinux 有自己的一套规则来编写安全策略文件,这套规则被称之为 SELinux Policy 语言。
介绍
-
SELinux则是由美国NSA(国安局)和一些公司(RedHat、Tresys)设计的一个针对Linux的安全加强系统
-
SELinux 按照默认拒绝的原则运行:任何未经明确允许的行为都会被拒绝
-
SELinux的两种模式
-
宽容模式:权限拒绝事件会被记录下来,但不会被强制执行。
-
强制模式:权限拒绝事件会被记录下来并强制执行。
-
作用
提高Android安全性。非法操作会被阻止,并且尝试进行的所有违规行为都会被内核记录到 dmesg 和 logcat 中。例如,app访问文件:/proc/sys/kernel/printk,app设置属性:persist.sys.log.level等
SEPolicy语言
Linux中有两种东西,一种死的(Inactive),一种活的(Active)。死的东西就是文件(Linux哲学,万物皆文件。注意,万不可狭义解释为File),而活的东西就是进程。此处的 死 和 活 是一种比喻,映射到软件层面的意思是:进程能发起动作,例如它能打开文件并操作它。而文件只能被进程操作。
根据 SELinux 规范,完整的 Secure Context 字符串为:user:role:type[:range]
相关设置
关闭 SELinux
-
临时关闭:setenforce
$ setenforce 0
setenforce命令修改的是 /sys/fs/selinux/enforce 节点的值,是 kernel 意义上的修改 selinux 的策略。断电之后,节点值会复位。
-
永久关闭
-
kernel关闭selinux:SECURITY_SELINUX设置为false,重新编译kernel
-
设置
ro.boot.selinux=permissive
属性,并且修改在system/core/init/Android.mk 中设置用于user版本下selinux模式为permissive
-
avc-denied问题解决
目前所有的 SELinux 权限检测失败,在 Kernel Log 或者 Android Log 中都有对应的 avc-denied log 与之对应。反过来,有 avc-denied log,并非就会直接失败,还需要确认当时 SELinux 的模式是 Enforcing 还是 Permissve。
如果是 Enforcing 模式,就要检测对应的进程访问权限资源是否正常?是否有必要添加? 如果有必要添加,可以按照下面的方式生成需要的 sepolicy 规则并添加到对应 te 文件。
-
从 logcat 或串口中提取相应的 avc-denied log,下面的语句为提取所有的 avc- denied log
$ adb shell "cat /proc/kmsg | grep avc" > avc_log.txt
-
使用 audit2allow 工具生成对应的 policy 规则
audio2allow 使用必须先 source build/envsetup.sh,导入环境变量
$ audit2allow -i avc_log.txt -p $OUT/vendor/etc/selinux/precompiled_sepolicy
-
将对应的policy 添加到 te 文件中
一般添加在 /device//common/sepolicy 或者 /device//$DEVICE/sepolicy 目录下:
BOARD_SEPOLICY_DIRS += device/$SoC/common/sepolicy //通过这个命令添加厂家自定义的 sepolicy 规则
怎么抓取SELinux Log
-
adb shell dmesg----抓kernel log
(特别说明:adb shell “cat /proc/kmsg | grep avc” > avc_log.txt 可以直接提出avc的log)
-
adb logcat –b events
关键字:avc: denied
SEAndroid 安全机制框架
SELinux 系统比起通常的 Linux 系统来,安全性能要高的多,它通过对于用户,进程权限的最小化,即使受到攻击,进程或者用户权限被夺去,也不会对整个系统造成重大影响。
我们知道,Android 系统是基于 Linux 内核实现,针对 Linux 系统,NSA 开发了一套安全机制 SELinux,用来加强安全性。然而,由于 Android 系统有着独特的用户空间运行时,因此 SELinux 不能完全适用于 Android 系统。为此,NSA 针对 Android 系统,在 SELinux 基础上开发了 SEAndroid。
SEAndroid 安全机制所要保护的对象是系统中的资源,这些资源分布在各个子系统中,例如我们经常接触的文件就是分布文件子系统中的。实际上,系统中需要保护的资源非常多,除了前面说的文件之外,还有进程、socket 和 IPC 等等。对于 Android 系统来说,由于使用了与传统 Linux 系统不一样的用户空间运行时,即应用程序运行时框架,因此它在用户空间有一些特有的资源是需要特别保护的,例如系统属性的设置等。
以 SELinux 文件系统接口问边界,SEAndroid 安全机制包含内核空间和用户空间两部分支持。
这些内核空间模块与用户空间模块空间的作用及交互有:
-
内核空间的 SELinux LSM 模块负责内核资源的安全访问控制
-
用户空间的 SEAndroid Policy 描述的是资源安全访问策略。
系统在启动的时候,用户空间的 Security Server 需要将这些安全访问策略加载内核空间的 SELinux LSM 模块中去,这是通过SELinux文件系统接口实现的。
-
用户空间的 Security Context 描述的是资源安全上下文。
SEAndroid 的安全访问策略就是在资源的安全上下文基础上实现的。
-
用户空间的 Security Server 一方面需要到用户空间的 Security Context 去检索对象的安全上下文,另一方面也需要到内核空间去操作对象的安全上下文。
-
用户空间的 libselinux 库封装了对 SELinux 文件系统接口的读写操作。
用户空间的 Security Server 访问内核空间的 SELinux LSM 模块时,都是间接地通过 libselinux进行的。这样可以将对 SELinux 文件系统接口的读写操作封装成更有意义的函数调用。
-
用户空间的 Security Server 到用户空间的 Security Context 去检索对象的安全上下文时,同样也是通过 selinux 库来进行的。
更多相关文章
- Nginx系列教程(六)| 手把手教你搭建 LNMP 架构并部署天空网络电影
- 【Android】 字体适配——不跟随系统字体大小、动态设置字体大小
- android 8.1 Not allowed to start service Intent 无法后台开启
- Android(安卓)PopupWindow 弹框布局要显示在某个空间下面位置
- android 基于BroadcastReceiver广播 完全退出应用的实现代码 亲
- Pixel修改kernel内核调试
- android关于获取摄像头帧数据转成图片
- Activity学习(一):生命周期
- Android7.1修改系统默认多媒体音量大小