我是靠谱客的博主 开心绿茶,最近开发中收集的这篇文章主要介绍Linux内核学习笔记——SELinux介绍(SELinux Policy是什么?)一、SELinux Overview二 、SELinux 基础原理三、 SELinux Policy,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

目录

  • 一、SELinux Overview
    • 1.1 SELinux 来源
    • 1.2 SELinux 基本架构与原理
    • 1.3 SELinux and SEAndroid
    • 1.4 SELinux 在Android 上的更新历史
    • 1.5 SELinux 给Android 带来的影响
  • 二 、SELinux 基础原理
    • 2.1 DAC and MAC
    • 2.2 Linux DAC
    • 2.3 Linux MAC
    • 2.4 Core SELinux Components
    • 2.5 Security Context
    • 2.6 SELinux supports two forms of MAC
    • 2.7 Type Enforcement Access Control
    • 2.8 Rule of Type Enforcement
    • 2.9 Domain Transitions
    • 2.10 Target Transitions
    • 2.11 SELinux File System
    • 2.12 SELinux Lib
    • 2.13 SELinux Java API
    • 2.14 SELinux Commands
  • 三、 SELinux Policy
    • 3.1 SELinux Policy Path
    • 3.2 SELinux Files in Phone
    • 3.3 SELinux Update in O overview
    • 3.4 sepolicy 分离

本文主要描述了SELinux的原理,以及在android中的使用。第一部分首先介绍了SELinux的基础框架;第二部分介绍了SELinux的基础理论;第三部分简单介绍了SELinux Policy。

本文主要基于android系统的SELinux讲解,水平有限,如果有错误,敬请指正。

一、SELinux Overview


1.1 SELinux 来源

SELinux 即Security-Enhanced Linux,由美国国家安全局(NSA)发起,Secure Computing Corporation (SCC) 和 MITRE 直接参与开发,以及很多研究机构(如犹他大学)一起参与的强制性安全审查机制,该系统最初是作为一款通用访问软件,发布于 2000 年 12 月(代码采用 GPL 许可发布)。并在Linux Kernel 2.6 版本后,有直接整合进入SELinux,搭建在Linux Security Module(LSM)基础上,目前已经成为最受欢迎,使用最广泛的安全方案。


1.2 SELinux 基本架构与原理

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

SELinux 搭建在Linux Security Module(LSM)基础上,关于 LSM 架构的详细描述请参见文章 “Linux Security Modules: General Security Support for the Linux Kernel”,该文章在 2002 年的 USENIX Security 会议上发表。有完整的实现LSM 的所有hook function。

SELinux 的整体结构如下图所示:
图1 - 整体流程图
SELinux 包含五个基本组成:

  • 用于处理文件系统的辅助模块, 即SELinuxFS;

  • 集成Linux Security Modules 的hooks sets;

  • Security Policy Database;

  • Security Label 验证模块;

  • Access Vector Cache (AVC),访问向量缓存,以便提高验证速度。

基本的访问流程如下图所示:
图2 -访问流程图

流程如下:

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

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

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

4、访问真正的系统资源;

5、返回用户态,将结果反馈。


1.3 SELinux and SEAndroid

Android 是建立在标准的Linux Kernel 基础上,自然也可以开启SELinux,通常在通用移动平台上,很少开启这样的安全服务,Google 为了进一步增强Android 的安全性,经过长期的准备,目前已经在Android 5.0(L) 之后有完整的开启SELinux,并对SELinux 进行深入整合形成了SEAndroid。


1.4 SELinux 在Android 上的更新历史

如下图所描述:
图3 - SELinux 在Android 的更新过程图

1、 KK 4.4 针对netd、installd、zygote、vold 四个原本具有root 权限的process,以及它们fork 出的子进程启用Enforce 模式;

2、L 版本开始普遍性开启SELinux Enforce mode;

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

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

  • Enforcing Mode 在记录LOG 的同时,还会真正的拦截访问

图4 - SELinux 在Android 启动模式变化图
从Android N 版本的后续版本Google都会要求强制性开启SELinux,以保证手机安全。

从Android O 版本后,Google大幅度的增强了selinux的限制,特别是限制System/Vendor 之间的交叉使用,如VNDK 的权限控制就主要由selinux来控制。

总体来说, Selinux 在android上的使用过程是一个从具体启用,到整体启用,从粗粒度限制,到精细控制的过程。

1.5 SELinux 给Android 带来的影响

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

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

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

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

二 、SELinux 基础原理

2.1 DAC and MAC

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

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

2.2 Linux DAC

Linux DAC 采用了一种非常简单的策略,将资源访问者分成三类,分别是Owner、Group、Other。资源针对这三类访问者设置不同的访问权限。而访问权限又分成 read、write、execute。

访问者通常是进程,有自己的uid/gid,通过uid/gid和文件权限匹配,来确定是否可以访问。

将Root权限根据不同的应用场景划分成许多的Root Capabilities,其中如果有CAP_DAC_OVERRIDE 这项的话,可以直接绕过Linux DAC 限制。

Linux DAC 有明显的不足,其中一个重要点就是Root 权限 “无法无天”,几乎可以做任意事情,一旦入侵者拿到root 权限,即已经完全掌控了系统。另外,每一个进程默认都拿到对应这个用户的所有权限,可以改动/删除这个用户的所有文件资源。很明显,这个难以防止恶意软件。

2.3 Linux MAC

Linux MAC 针对DAC 的不足,要求系统对每一项访问进行检查,每访问一个文件资源都需要进行针对性的验证。而这个针对性的验证是根据已经定义好了的策略进行的。在Linux Kernel,所有的MAC机制都是搭建在Linux Security Modules (LSM) 基础上,包括有:SELinux、Apparmor、Smack 和 TOMOYO Linux等。目前SELinux已经成了事实上的行业标准。

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

2.4 Core SELinux Components

SELinux 的核心组件可以参考下面的图:
图5 - SELinux 核心组件图

  • Subject 通常是指触发访问行为的对象,在Linux 里面通常是一个进程(Process);

  • Object Manager 即是对象访问管理器,即可以知道Subject 需要访问哪些资源,并且触发验证机制;

  • Security Server 即安全服务器,用来验证某个Subject 是否可以真正的访问某个Object,而这个验证机制是基于定义好的Security Policy;

  • Security Policy 是一种描述SELinux Policy 的语言;

  • Access Vector Cache (AVC) 是访问缓存,用来记录以往的访问验证情况,以便提高效率,快速处理。

2.5 Security Context

SELinux 给Linux 的所有对象都分配一个安全上下文(Security Context),描述成一个标准的字符串。

两种类型:

  • Subject 主体,linux通常以进程为单位

  • Object 访问对象,linux 通常以文件为单位

标准格式:user:role:type[:range]

  • User:用户,非Linux UID;

  • Role:角色,一个user可以属于多个role,不同的role具有不同的权限。它是SELinux中一种比较高层次,更方便的权限管理思路,即Role Based Access Control(基于角色的访问控制,简称为RBAC,SELinux 不推荐使用);

  • Type:Subject或者Object的类型。MAC的基础管理思路其实不是针对上面的RBAC,而是所谓的Type Enforcement Access Control(简称TEAC,一般用TE表示)。对进程来说,Type就是Domain。

  • Range:Multi-Level Security(MLS)的级别。MLS将系统的进程和文件进行了分级,不同级别的资源需要对应级别的进程才能访问。

图6 -对象类型和权限项关系图

每一个对象都有一个Class,比如一个文件,它是File Class 类型,每个Class 类型都会根据实际情况定义权限类型项,如:read、write、exec、ioctl、append 等等。

Subject 即前面提到的主体,它能够产生访问行为,Linux 里面通常是一个process,但process 本身也可能是一个Object,比如另外一个进程对它发送Signal,去对它进行Ptrace 操作。

2.6 SELinux supports two forms of MAC

(1) Type Enforcement (TE)

顾名思义,Type Enforcement 是根据Security Label 中的 type 进行权限审查,审查 subject type 对 object type 的某个class 类型中某种permission 是否具有访问权限,是目前使用最为广泛的MAC 审查机制,简单易用。

(2) Multi-Level Security (MLS)

多层安全机制,是基于Bell-La Padula (BLP) 模型,将Subject 和 Object 定义成多层次的安全等级,不同安全等级之间有相关的访问约束,常见的访问约束是 “no write down” 和 “no read up”。它是根据Security Label 里面的最后一个字段label 进行确认的。

目前在Android 中,重点启用了Type Enforcement 机制,Multi-Level Security (MLS) 虽然有定义,但没有深入使用,这里暂时略过。

2.7 Type Enforcement Access Control

控制语句格式:rule_name source_type target_type:class perm_set;

rule:控制类型,分成两方面 allow 以及 audit。

source_type:也叫subject,通常是domain。

Target_type:代表请求的资源的类型。

class perm_set:代表对资源访问的操作。

2.8 Rule of Type Enforcement

如下表所示:
图7 - TEAC-Rule图
allow:赋予某项权限。

auditallow:audit含义就是记录某项操作。默认SELinux只记录那些权限检查失败的操作。auditallow则使得权限检查成功的操作也被记录。注意,allowaudit只是允许记录,它和赋予权限没关系。赋予权限必须且只能使用allow语句。

dontaudit:对那些权限检查失败的操作不做记录。

neverallow:前面讲过,用来检查安全策略文件中是否有违反该项规则的allow语句。

2.9 Domain Transitions

在SELinux 中,我们通常称一个进程是一个domain,一个进程fork 另外一个进程并执行(exec) 一个执行档时,我们往往会涉及到domain 的切换。比如init 进程,SELinux 给予了它很大的权限,而它拉起的服务,我们要限制这个服务的权限,于是就涉及到从一个domain 切换到另外一个domain,不然默认就使用init 进程的domain。

在SELinux 里面有专门的一条语法:type_transition statement。

在准备切换前我们先要确保有相关的权限操作:

The source domain has permission to transition into the target domain.

源domain 必须有权限切换到这个目标domain;

The application binary file needs to be executable in the source domain.

源doamin 必须要有执行这个执行档的权限;

The application binary file needs an entry point into the target domain.

这个执行档必须是目标domain 的入口(Entry Point)。

如下面的demo,init 拉起apache 并且切换到 apache 的domain。

  • 首先,你得让init_t域中的进程能够执行typeapache_exec_t的文件

c allow init_t apache_exec_t : file {read getattr execute};

  • 然后,你还得告诉SELinux,允许init_t做DT切换以进入apache_t

c allow init_t apache_t : process transition;

  • 最后,你还得告诉SELinux,切换入口(对应为entrypoint权限)为执行apache_exec_t类型 的文件

c allow apache_t apache_exec_t : file entrypoint;

  • Domain Transition

c type_transition init_t apache_exec_t : process apache_t;

Google 为了方便操作, 定义了专门的 transition 宏, 方便大家操作, 可以参考如:

system/sepolicy/public/te_macros 文件。

2.10 Target Transitions

一个进程在一个目录下创建文件时,默认是沿用父目录的Security Context,如果要设置成特定的Label,就必须进行Object Transitions。

同样是使用type_transition statement。

对应的必须有两个前提条件:

1)The source domain needs permission to add file entries into the directory

这个process 必须有在这个目录下添加文件的权限。

2)The source domain needs permission to create file entries

这个process 必须有在这个目录下创建以这个Security Context 为Label 的文件权限。

下面是一个demo,ext_gateway_t 这个domain 在类型为in_queue_t 的目录下,创建类型为 in_file_t 的文件。

  1. 首先,你得让ext_gateway_tin_queue_t 目录具备访问权限

c allow ext_gateway_t in_queue_t : dir { write search add_name };

  1. 然后,你还得告诉SELinux,允许ext_gateway_t 访问in_file_t的文件

c allow ext_gateway_t in_file_t : file { write create getattr };

  1. Object Transition

c type_transition ext_gateway_t in_queue_t : file in_file_t;

同样Google 也为此定义了专门的target transition 宏,以方便大家。参考system/sepolicy/public/te_macros 文件。

2.11 SELinux File System

SELinux 在Kernel 中实现,统一对外的接口都集中在SELinux File System 当中,即通过读写相关文件的方式来达成。

SELinux File System 在比较新的Linux Kernel 中被mount 在/sys/fs/selinux。老的版本就直接是/selinuxfs。

具体每一只文件的说明,请参考:The SELinux Notebook: 2.19.2.3 SELinux Filesystem

2.12 SELinux Lib

所有SELinux Lib 几乎都是对selinuxfs 的封装,具体的API 可以参考:The SELinux Notebook: 9. APPENDIX B - LIBSELINUX LIBRARY FUNCTIONS

在android 上,Google 有进一步对这些API 进行封装,具体都在/external/libselinux 下面。(参考: http://selinuxproject.org/page/NB_SEforAndroid_1)

2.13 SELinux Java API

Google 进一步将部分重要的SELinxu API 包装成了Java API。

对应的代码是:

Java API:frameworks/base/core/java/android/os/SELinux.java

JNI Code:frameworks/base/core/jni/android_os_SELinux.cpp

对应的API 描述 (参考: http://selinuxproject.org/page/NB_SEforAndroid_1)。

2.14 SELinux Commands

SELinux Commands可以参考(http://selinuxproject.org/page/NB_SEforAndroid_1)。

三、 SELinux Policy

3.1 SELinux Policy Path

路径:Google Original,android/external/sepolicy/XXX.te (通常不建议修改)

所有的Policy 最终采用Union(合并) 的方式编译在一起。

3.2 SELinux Files in Phone

SELinux Policy 手机上关键性的配置文件包括:

/sepolicy:所有SELinux Policy 编译后的sepolicy 文件

/file_contexts:系统文件以及device 所对应的security context

/seapp_contexts:zygote 设置app 的security context 的配置项

/service_contexts:service 所绑定的security context

/property_contexts:property 所绑定的security context

/system/etc/security/mac_permissions.xml:定义app 的security context 类型

/selinux_version:对应system property: ro.build.fingerprint

/selinux_network.sh:设置selinux 对网络端的访问

临时性设置/data/security/current/

KK 上SELinux 是实验性质的,相关如file_contexts, seapp_contexts 等都优选/data/security/current 下面的特别文件。

L 版本上,在android.c 中使用了特别的判定函数 set_policy_index用来比较

 /selinux_version

 /data/security/current/selinux_version

当两只文件都存在,并且完全一致,才会使用/data/security/current 下面的文件,其它情况下都会使用根目录的配置文件。

selinux_version 中存储的是build 的BUILD_FINGERPRINTsystem property: ro.build.fingerprint

3.3 SELinux Update in O overview

Google android O 8.0 开始,对android 架构进行大幅度的更新,一个最为重要的方面是切割Google/SoC Vendor/ODM 三者的复杂关联性,让android 单独升级成为可能。
图8 – android O img调整关系图
注: Google: Android O LKM feature is disabled due to ODM partition OTA not ready. Expect to ready in P. 所以实际odm.img 还和vendor.img 结合。

而为了防止System.img / Vendor.img 中数据、服务、应用等相互的依赖、调用、引用。Google 大幅度的更新了selinux policy,进行严格的限制。
图9 – android O System / Vendor访问限制示意图

比如严格限制了system image 和 vendor image 之间的socket,binder 通讯。只能通过HIDL,HwBinder 进行交互。下面我们详细的讲到具体的更新变化。

3.4 sepolicy 分离

伴随着system image 和 vendor image 的分离,自然也会伴随着sepolicy 的分离,从以往集中放在bootimage,到分离存放到system image 以及 vendor image。原则上与system 相关的sepolicy 就存放system image,与SoC vendor 相关的sepolicy 就存放在vendor image。

对应sepolicy,Google 也设定了不同的存放目录,以便进行分离,以Google 默认的sepolicy 为例:/system/sepolicy

  • Public:android 和 vendor 共享的sepolicy 定义,通常情况下,意味着vendor 开发者可能为此新增一些权限。一般system/vendor 共用的一些类型和属性的定义,neverallow 限制等会存放于此。

  • Private:通常意义上的仅限于system image 内部的使用,不对vendor 开放。这个只会编译到system image 中。

  • Vendor:它仅仅能引用public 目录下的相关定义,这个只会编译到vendor image 中。但它依旧可以对system image 里面的module 设定sepolicy(对应module 需要在public 下进行声明);在很大程度上绕过了Google GTS 约束测试。

  • Mapping:为兼容老版本的sepolicy 而导入,只有在system image version > vendor version 的时候,才可能被用到。即包括两方面,新版本增加的type,新版本移除的type,以及老版本public,新版本private 等变化的设定。以兼容老版本。

对应Google 的描述, 可以参考: /system/sepolicy/android.mk

最后对于手机来说生成的selinux policy 位于:

System android sepolicy:  system/etc/selinux

Vendor ODM sepolicy:  vendor/etc/selinux

注意没有如以往一样直接编译成sepolicy binary,而是使用selinux CIL 描述。具体可以参考:https://github.com/SELinuxProject/cil

参考文献:

  1. https://source.android.google.cn/security/selinux?hl=zh-cn
  2. http://selinuxproject.org/page/NB_SEforAndroid_1
  3. https://github.com/SELinuxProject/cil
  4. https://blog.csdn.net/feelabclihu/article/details/117576092

最后

以上就是开心绿茶为你收集整理的Linux内核学习笔记——SELinux介绍(SELinux Policy是什么?)一、SELinux Overview二 、SELinux 基础原理三、 SELinux Policy的全部内容,希望文章能够帮你解决Linux内核学习笔记——SELinux介绍(SELinux Policy是什么?)一、SELinux Overview二 、SELinux 基础原理三、 SELinux Policy所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(55)

评论列表共有 0 条评论

立即
投稿
返回
顶部