SELinux 是什么?

一、SELinux的历史

SELinux全称是Security Enhanced Linux,由美国国家安全部(National Security Agency)领导开发的GPL项目,它拥有一个灵活而强制性的访问控制结构,旨在提高Linux系统的安全性,提供强健的安全保证,可防御未知攻击,相当于B1级的军事安全性能。比MS NT的C2等高得多。

SELinux起源于自1980开始的微内核和操作系统安全的研究,这两条研究线路最后形成了一个叫做的分布式信任计算机(Distribute Trusted Mach (DTMach))的项目,它融合了早期研究项目的成果(LOCK【锁】,它包含一组安全内核类型强制;Trusted Mach【信任计算机】,它将多层安全控制合并到计算机微内核中)。美国国家安全局的研究组织参加了DTMach项目,付出了巨大努力,并且继续参与了大量的后续安全微内核项目。最终,这些工作和努力导致了一个新的项目产生,那就是Flask,它支持更丰富的动态类型的强制机制。

由于不同平台对这这项技术没有广泛使用,NAS认为需要在大量的社团中展示这个技术,以说明它的持久生命力,并收集广泛的使用支持意见。在1999年夏天,NSA开始在Linux内核中实现Flask安全架构,在2000年十二月,NSA发布了这项研究的第一个公共版本,叫做安全增强的Linux。因为是在主流的操作系统中实现的,所以SELinux开始受到Linux社区的注意,SELinux最迟是在2.2.x内核中以一套内核补丁的形式发布的。

随着2001年Linux内核高级会议在加拿大渥太华顺利召开,Linux安全模型(LSM[7])项目开始为Linux内核创建灵活的框架,允许不同的安全扩展添加到Linux中。NSA和SELinux社区是SELinux的主要贡献者,SELinux帮助LSM实现了大量的需求,为了与LSM一起工作,NSA开始修改SELinux使用LSM框架。2002年八月LSM核心特性被集成到Linux内核主线,同时被合并到Linux 2.6内核。2003年八月,NSA在开源社区的帮助下,完成了SELinux到LSM框架的迁移,至此,SELinux进入Linux 2.6内核主线,SELinux已经成为一种全功能的LSM模块,包括在核心Linux代码集中。

 数个Linux发行版开始在2.6内核中不同程度使用SELinux特性,但最主要是靠Red Hat发起的Fedora Core项目才使SELinux具备企业级应用能力,NSA和Red Hat开始联合集成SELinux,将其作为Fedora Core Linux发行版的一部分。在Red Hat参与之前,SELinux总是作为一个附加的软件包,需要专家级任务才能进行集成。Red Hat开始采取行动让SELinux成为主流发行版的一部分,完成了用户空间工具和服务的修改,默认开启增强的安全保护。从Fedora Core 2开始,SELinux和它的支持基础架构以及工具得到改进。在2005年早些时候,Red Hat发布了它的Enterprise Linux 4(REL 4),在这个版本中,SELinux默认就是完全开启的,SELinux和强制访问控制已经进入了主流操作系统和市场。

SELinux仍然是一个相对较新和复杂的技术,重要的研究和开发在继续不断地改进它的功能。

应用SELinux后,可以减轻恶意攻击或恶意软件带来的灾难,并提供对机密性和完整性有很高要求的信息很高的安全保障。普通Linux安全和传统Unix系统一样,基于自主存取控制方法,即DAC,只要符合规定的权限,如规定的所有者和文件属性等,就可存取资源。在传统的安全机制下,一些通过setuid/setgid的程序就产生了严重安全隐患,甚至一些错误的配置就可引发巨大的漏洞,被轻易攻击。

而SELinux则基于强制存取控制方法,即MAC,透过强制性的安全策略,应用程序或用户必须同时符合DAC及对应SELinux的MAC才能进行正常操作,否则都将遭到拒绝或失败,而这些问题将不会影响其他正常运作的程序和应用,并保持它们的安全系统结构。

二、SELinux 的作用及权限管理机制

2.1 SELinux 的作用

SELinux 主要作用就是最大限度地减小系统中服务进程可访问的资源(最小权限原则)。

2.2 DAC

在没有使用 SELinux 的操作系统中,决定一个资源是否能被访问的因素是:某个资源是否拥有对应用户的权限(读、写、执行)。

只要访问这个资源的进程符合以上的条件就可以被访问。

而最致命问题是,root 用户不受任何管制,系统上任何资源都可以无限制地访问。

这种权限管理机制的主体是用户,也称为自主访问控制(DAC);

2.3 MAC

在使用了 SELinux 的操作系统中,决定一个资源是否能被访问的因素除了上述因素之外,还需要判断每一类进程是否拥有对某一类资源的访问权限。

这样一来,即使进程是以 root 身份运行的,也需要判断这个进程的类型以及允许访问的资源类型才能决定是否允许访问某个资源。进程的活动空间也可以被压缩到最小。

即使是以 root 身份运行的服务进程,一般也只能访问到它所需要的资源。即使程序出了漏洞,影响范围也只有在其允许访问的资源范围内。安全性大大增加。

这种权限管理机制的主体是进程,也称为强制访问控制(MAC)。

而 MAC 又细分为了两种方式,一种叫类别安全(MCS)模式,另一种叫多级安全(MLS)模式。

三、SELinux 基本概念

3.1 主体(Subject)

可以完全等同于进程。

3.2 对象(Object)

被主体访问的资源。可以是文件、目录、端口、设备等。

3.3 政策和规则(Policy & Rule)

 一套政策里面有多个规则。部分规则可以按照需求启用或禁用(以下把该类型的规则称为布尔型规则)。

3.4 安全上下文(Security Context)

安全上下文是 SELinux 的核心。

安全上下文我自己把它分为「进程安全上下文」和「文件安全上下文」。

一个「进程安全上下文」一般对应多个「文件安全上下文」。只有两者的安全上下文对应上了,进程才能访问文件。它们的对应关系由政策中的规则决定。

3.5 SELinux 的工作模式

SELinux 有三种工作模式,分别是:

1. enforcing:强制模式。违反 SELinux 规则的行为将被阻止并记录到日志中。

2. permissive:宽容模式。违反 SELinux 规则的行为只会记录到日志中。一般为调试用。

3. disabled:关闭 SELinux。

3.6 SELinux 工作流程

这里引用一张图片,不必过多解释。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏架构师小秘圈

出行领域架构设计

作者:王小雪。滴滴出行架构师,原快的打车架构师。 来源:程序员杂志 某知名打车平台从随着业务的发展,系统访问量迅速膨胀,很多复杂的问题要在短时间内解决,且不能影...

3974
来自专栏张善友的专栏

从APM角度上看:NoSQL和关系数据库并无不同

Michael Kopp拥有十年以上C++、Java/JEE的架构及开发经验,现Compuware技术策略师,专攻大规模产品部署的架构和性能。 以下为译文: 传...

2338
来自专栏cloudskyme

hbase实战——(1.1 nosql介绍)

什么是nosql NoSQL(NoSQL = Not Only SQL),意思是不仅仅是SQL的扩展,一般指的是非关系型的数据库。 随着互联网web2.0网站的...

3698
来自专栏小樱的经验随笔

Python爬虫笔记(一):爬虫基本入门

最近在做一个项目,这个项目需要使用网络爬虫从特定网站上爬取数据,于是乎,我打算写一个爬虫系列的文章,与大家分享如何编写一个爬虫。这是这个项目的第一篇文章,这次就...

3776
来自专栏YG小书屋

logstash 重复消费kafka问题

前两天业务方突然找到我说当天索引ES查询很慢,原来毫秒级的查询现在竟然要20s,让我处理下。我看了下索引大小,原来是1分片6g左右,今天突然就变成了1分片32g...

2653
来自专栏即时通讯技术

知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路

知乎存储平台团队基于开源Redis 组件打造的知乎 Redis 平台,经过不断的研发迭代,目前已经形成了一整套完整自动化运维服务体系,提供很多强大的功能。本文作...

4642
来自专栏企鹅号快讯

实用的国产优秀开源中间件

在系统软件之中,操作系统、数据库、中间件的三驾马车,中间件是最神秘的,而且是一个专业化非常强的细分产业。中间件技术主要用来支撑分布式软件的开发,在大型分布式软件...

25410
来自专栏FreeBuf

HTTP2.0协议被曝4个高危漏洞,可致服务器崩溃

如果你认为HTTP2.0协议比标准HTTP(超文本传输协议)更安全,那你就错了。有研究人员花费4个月的时间在HTTP2.0协议中发现4个漏洞! 去年2月,谷歌把...

2548
来自专栏CSDN技术头条

创建一个分布式网络爬虫的故事

编者按:作者通过创建和扩展自己的分布式爬虫,介绍了一系列工具和架构, 包括分布式体系结构、扩展、爬虫礼仪、安全、调试工具、Python 中的多任务处理等。以下为...

2348
来自专栏大数据架构师专家

从运维角度看中大型网站架构的演变之路

网上有很多文章类似于我今天要分享的课程,有架构师写的,有运维写的,还有开发些的,偏重点都不同,今天我以咱们运维角度全面讲解。

1373

扫码关注云+社区