SELinux理论基础

SELinux理论基础

SELinux：Security-Enhanced Linux，翻译过来就是 安全增强型 Linux

在 Android 系统中，SELinux 是安全架构的核心部分：

• 每个应用和系统进程都有特定的安全上下文
• 通过策略文件（.te 文件）定义访问规则
• 防止恶意应用或漏洞影响系统安全

如果没有SElinux权限，直接操作：
APK->JNI->底层驱动（app操作设备驱点,read, write），可能会遇到权限问题，打开不了，不能读，不能写等问题, 但是在以前早期的版本，可能对节点chmod a+x /dev/xxx 进行权限的设置，就能访问了。

但是：开机启动中，根据rc文件提供的启动信息， 会启动一些后台进程，可以在进程对应的rc文件中配置让进程开机启动，但是有可能跑不起来， 如果没有配置selinux相关的策略的话，这是因为app运行的时候，检测安全环境。

SELinux 背后的深层设计目标

DAC自主访问控制模型：

这种是比较粗犷的模型，称之为DAC（自主访问，通过chmod修改访问权限。）一个进程如果是超级用户root,它可以访问系统上的所有关联root的资源。

因此我们需要控制访问权限的颗粒，这就可以通过MAC机制(即SEAndroid),
因为SELinux 设计的核心是引入强制访问控制（MAC），而非依赖传统的自主访问控制（DAC）。这一点对于现代系统至关重要，因为 DAC 的设计缺陷在于它允许具有足够权限的用户自由分配访问权，这在攻击者获得管理员权限后可能会造成严重的系统危害。SELinux 则通过预定义的策略，确保即使管理员也不能轻易修改核心文件或服务的访问权限。

比喻：
传统 Linux (DAC) - 像普通的图书馆
想象一个普通的学校图书馆：

学生 = 普通用户
图书管理员 = root/管理员
借书证 = 文件权限（rwx）

工作方式（DAC）：

学生甲有借书证（有读取权限），可以借书
学生乙没有借书证（无权限），不能借书
但是：如果学生甲把自己的借书证给学生乙，学生乙就能借书了
更糟糕：如果有人偷了图书管理员的万能卡（成为root），他就能：
借走任何书
修改借阅记录
甚至删除整个图书馆系统
问题： 权限一旦获得，可以随意传递和滥用。

SELinux (MAC) - 像严格管理的军事图书馆
现在想象一个军事学校的绝密资料馆：

1. 每个房间都有严格规定（安全上下文）

📁 绝密档案室     → 标签：level_top_secret
📁 内部资料室     → 标签：level_internal  
📁 公共阅览室     → 标签：level_public

2. 每个人都有明确身份（进程域）

👨‍✈️ 将军         → 身份：domain_general
👨‍💼 情报官       → 身份：domain_intel
👨‍🎓 普通学员     → 身份：domain_student
👨‍🔧 清洁工       → 身份：domain_cleaner

3. 详细的访问规则（策略）

# SELinux 策略类似这样：
allow domain_general level_top_secret:file {read write};
allow domain_intel level_internal:file {read};
allow domain_student level_public:file {read};
deny domain_cleaner level_top_secret:file *;  # 禁止清洁工访问绝密文件

实际场景对比：
场景：清洁工想进绝密档案室
传统图书馆（DAC）：

# 清洁工拿到馆长钥匙（成为root）
sudo su  # 现在是root了！
cd /top_secret_room  # 可以进去了
cat nuclear_codes.txt  # 可以看核密码！

✅ 技术上可行 ❌ 安全灾难

军事图书馆（SELinux）：

# 即使清洁工偷了馆长钥匙
sudo su  # 身份变成root
cd /top_secret_room  # 试图进入

# SELinux 检查：
# 当前身份：domain_cleaner
# 目标房间：level_top_secret
# 策略规定：deny domain_cleaner level_top_secret:*

❌ 权限拒绝！即使你是root也不行！

为什么需要这么严格？
想象 Android 手机：

📱 你的微信（普通应用）想：

# 读取你的通讯录 → ✅ 允许（正当功能）
# 读取银行app数据 → ❌ 拒绝（隐私泄露）
# 修改系统文件 → ❌ 拒绝（系统安全）

🔧 系统更新服务 想：

# 修改系统文件 → ✅ 允许（本职工作）
# 读取你的照片 → ❌ 拒绝（越权）

没有 SELinux：一个被黑的微信可能：

提权到root
读取所有app数据
安装后门
完全控制你的手机

有 SELinux：即使微信被黑：

它还是 wechat_domain 身份
SELinux 说："wechat身份不能做这些事"
攻击被限制在微信自己的沙箱里

MAC访问控制框架模型
这里的MAC模型，是基于前面的DAC模型的，同样也拥有用户类型，uid和gid的概念。

主体：一般指的是活动的进程
客体：有普通文件，虚拟文件，属性文件，服务service和app
te文件：一般用于描述主体对客体的一套动作行为，就是一种逻辑性的行为描述。
比如：信息部的张经理，允许对员工具有分配系统的xxx权限，这类描述就是te文件中的明文规定，描述了一种主体对客体访问的规章制度。