SElinux 学习笔记--例子实现

最新推荐文章于 2025-11-13 09:51:54 发布

原创最新推荐文章于 2025-11-13 09:51:54 发布 · 1.2k 阅读

1 ·

本内容遵循CC 4.0 BY-SA版权协议

SElinux 专栏收录该内容

2 篇文章

订阅专栏

本文介绍了在Fedora系统中学习和应用SElinux的实践经验，特别是关于TE（Type Enforcement）控制的实践。文章讨论了SELinux的DAC、MAC、MLS和RBAC等访问控制机制，并通过一个基于角色的收银控制的例子，展示了如何使用SElinux进行权限管理。在实践中遇到的问题，如角色转换时的权限错误和类型找不到，以及安装后用户登录和角色使用的问题，也进行了探讨。

目前工作进度总结

测试环境介绍

操作系统：Fedora 22 MATE /Fedora 21

环境搭建：
```
root# yum install -y policycoreutils-python policycoreutils-devel selinux-policy-devel setools hddtemp git vim ctags --nogpgcheck 
```
参考：

PDF：https://mgrepl.fedorapeople.org/PolicyCourse/writingSELinuxpolicy_MUNI.pdf

代码：https://mgrepl.fedorapeople.org/PolicyCourse/

一小型教程，主要介绍SElinux policy language的基本编写规则
附加概念介绍

SElinux 其实最主要的控制方式是TE（Type Enforcement）控制，即基于Type对主客体之间的权限关系进行设置，而角色以及用户，更多的起到的是对不同类的Type进行分类标记的作用
DAC (Discretionary Access Control )自主访问控制机制:
- Linux自身的访问控制模型
- 采用较为宽松的管理形式，所有者拥有一切权限，但是一旦程序本身出现问题，所有者的权限可能会被滥用，即不受信用户可能以此来破坏计算机的稳定
MAC (Mandatory Access Control)强制访问控制机制：
- 这种访问控制模型主要用来保护机密数据，即完全由安全策略来控制对于客体的访问，而不是由所有者来决定，因此可以不受个别程序缺陷的影响
MLS (Multilevel security)多层安全模型：
- 一种常见的用来实现MAC的模型，主要基于Bell-LaPadula(BLP) 模型
- 主要特点是禁止下读上，上写下，即低层级主体无法读取高层级客体，高层级主体无法写入低层级主体，这种模型十分严格，主要限制了数据信息的流通，主要用途是保证数据的机密性，但是大部分的应用场景不需要应用这种特别严格的控制模型
RBAC (Role-based Access Control)基于角色的访问控制机制：
- 基于角色关系对主体及客体进行安全策略设置
- SElinux中提供的RBAC是基于对不同角色之间的type类进行安全策略的编写来实现对不同角色的权限区分的
测试代码

参考：http://www.ibm.com/developerworks/cn/linux/l-rbac-selinux/

代码主要实现基于角色的收银控制：

其主要访问逻辑判断基于register.py以及用户运行register.py时的安全上下文
判断是否是mgr_r进行不同操作
主要的权限还是在于register.py 文件本身的type权限以及运行是register.py的域控制

按照教程进行make安装，会出现如下问题：
- 提示某种类型无法找到：
  - r_file_perms 改正为read_file_perms (.if以及.te文件)
  - _tty_device_t 以及 _devps_t
    - 这两种类型暂时无法解决，查阅后得知_tty_device_t主要是用于启用TTY界面即不同用户登录使用
    - _devps_t还暂时不知道，如果采用定义，即使用type对这两种类型定义，将出现安装后无法使用的结果，原因暂时不清楚。
- 安装后出现的问题：
  - 设定用户无法登录：
    - 原因大概是使用定义的用户所拥有的type无法启动shell，但具体缺少什么不清楚，曾尝试添加例如corecmd_exec_bin() 类的方法，仍无法使用，不清楚是因为权限不够，还是由于本条语句的使用出现问题
  - 设定角色无法使用：
    - 原因是角色所拥有的类型无法启用shell，报出permission denied之类的错误，使用newrole类的命令也得带了permission denied类的错误，证明确实是切换后的权限不够？（能力不够？）
参考：
[https://mgrepl.fedorapeople.org/PolicyCourse/writingSELinuxpolicy_MUNI.pdf]

使用本例子进行测试时，参考了其生成的selinuxrun这个shell进行使用时发现或许可以使用runcon以及chcon这两个命令去实现角色装换的目标：
- runcon：改变运行时的安全上下文，需要拥有切换角色或者类型的权限
- chcon：改变某一文件的安全上下文，需要拥有改文件的修改权限
这两个命令的使用总是出错，在对系统本身的权限进行处理时没有什么问题，但是对于上一个例子中的角色和类型进行切换时，会遇到很多permission denied，不知道是使用不正确还是权限设置不对，总之对于整个SElinux的了解还不够深，不清楚这其中的区别还有具体的实现，例如大多数的程序都是通过initrc_t这种类型进行引导的，如何在这种引导后对进程的type进行重定义还不知道。
下一步
- 完全理解SElinux的安全控制方式
- 了解大部分的系统默认安全策略，对系统本身自带的安全策略建立起结构模型(targeted)
- 尝试实现一个能被使用type模型
- 尝试实现一个能够登录的SElinux用户（使用自建的角色以及类型控制）