分类 极客漫画 下的文章

 title=

今年是我们一起庆祝 SELinux 纪念日的第十个年头了(LCTT 译者注:本文发表于 2013 年)。真是太难以置信了!SELinux 最初在 Fedora Core 3 中被引入,随后加入了红帽企业版 Linux 4。从来没有使用过 SELinux 的家伙,你可要好好儿找个理由了……

SElinux 是一个标签型系统。每一个进程都有一个标签。操作系统中的每一个文件/目录 客体 object 也都有一个标签。甚至连网络端口、设备,乃至潜在的主机名都被分配了标签。我们把控制访问进程的标签的规则写入一个类似文件的客体标签中,这些规则我们称之为 策略 policy 。内核强制实施了这些规则。有时候这种“强制”被称为 强制访问控制体系 Mandatory Access Control (MAC)。

一个客体的拥有者对客体的安全属性并没有自主权。标准 Linux 访问控制体系,拥有者/分组 + 权限标志如 rwx,常常被称作 自主访问控制 Discretionary Access Control (DAC)。SELinux 没有文件 UID 或拥有权的概念。一切都被标签控制,这意味着在没有至高无上的 root 权限进程时,也可以设置 SELinux 系统。

注意: SELinux 不允许你摒弃 DAC 控制。SELinux 是一个并行的强制模型。一个应用必须同时支持 SELinux 和 DAC 来完成特定的行为。这可能会导致管理员迷惑为什么进程被拒绝访问。管理员被拒绝访问是因为在 DAC 中有些问题,而不是在 SELinux 标签。

类型强制

让我们更深入的研究下标签。SELinux 最主要的“模型”或“强制”叫做 类型强制 type enforcement 。基本上这意味着我们根据进程的类型来定义其标签,以及根据文件系统客体的类型来定义其标签。

打个比方

想象一下在一个系统里定义客体的类型为猫和狗。猫(CAT)和狗(DOG)都是 进程类型 process type

Image showing a cartoon of a cat and dog.

我们有一类希望能与之交互的客体,我们称之为食物。而我希望能够为食物增加类型:cat_food (猫的食物)和 dog_food(狗的食物)。

Cartoon Cat eating Cat Food and Dog eating Dog Food

作为一个策略制定者,我可以说一只狗有权限去吃狗粮(dog_chow),而一只猫有权限去吃猫粮(cat_chow)。在 SELinux 中我可以将这条规则写入策略中。

 title=

allow cat cat_chow:food eat;

允许 猫 猫粮:食物 吃;

allow dog dog_chow:food eat;

允许 狗 狗粮:食物 吃;

有了这些规则,内核会允许猫进程去吃打上猫粮标签 cat_chow 的食物,允许狗去吃打上狗粮标签 dog_chow 的食物。

Cartoon Cat eating Cat Food and Dog eating Dog Food

此外,在 SELinux 系统中,由于禁止是默认规则,这意味着,如果狗进程想要去吃猫粮 cat_chow,内核会阻止它。

同理,猫也不允许去接触狗粮。

 title=

现实例子

我们将 Apache 进程标为 httpd_t,将 Apache 上下文标为 httpd_sys_content_thttpdsys_content_rw_t。假设我们把信用卡数据存储在 MySQL 数据库中,其标签为 msyqld_data_t。如果一个 Apache 进程被劫持,黑客可以获得 httpd_t 进程的控制权,从而能够去读取 httpd_sys_content_t 文件并向 httpd_sys_content_rw_t 文件执行写操作。但是黑客却不允许去读信用卡数据(mysqld_data_t),即使 Apache 进程是在 root 下运行。在这种情况下 SELinux 减轻了这次闯入的后果。

多类别安全强制

打个比方

上面我们定义了狗进程和猫进程,但是如果你有多个狗进程:Fido 和 Spot,而你想要阻止 Fido 去吃 Spot 的狗粮 dog_chow 怎么办呢?

 title=

一个解决方式是创建大量的新类型,如 Fido_dogFido_dog_chow。但是这很快会变得难以驾驭因为所有的狗都有差不多相同的权限。

为了解决这个问题我们发明了一种新的强制形式,叫做 多类别安全 Multi Category Security (MCS)。在 MCS 中,我们在狗进程和狗粮的标签上增加了另外一部分标签。现在我们将狗进程标记为 dog:random1(Fido)dog:random2(Spot)

Cartoon of two dogs fido and spot

我们将狗粮标记为 dog_chow:random1(Fido)dog_chow:random2(Spot)

 title=

MCS 规则声明如果类型强制规则被遵守而且该 MCS 随机标签正确匹配,则访问是允许的,否则就会被拒绝。

Fido (dog:random1) 尝试去吃 cat_chow:food 被类型强制拒绝了。

Cartoon of Kernel (Penquin) holding leash to prevent Fido from eating cat food.

Fido (dog:random1) 允许去吃 dog_chow:random1

Cartoon Fido happily eating his dog food

Fido (dog:random1) 去吃 spot(dog_chow:random2)的食物被拒绝。

Cartoon of Kernel (Penquin) holding leash to prevent Fido from eating spots dog food.

现实例子

在计算机系统中我们经常有很多具有同样访问权限的进程,但是我们又希望它们各自独立。有时我们称之为 多租户环境 multi-tenant environment 。最好的例子就是虚拟机。如果我有一个运行很多虚拟机的服务器,而其中一个被劫持,我希望能够阻止它去攻击其它虚拟机和虚拟机镜像。但是在一个类型强制系统中 KVM 虚拟机被标记为 svirt_t 而镜像被标记为 svirt_image_t。 我们允许 svirt_t 可以读/写/删除标记为 svirt_image_t 的上下文。通过使用 libvirt 我们不仅实现了类型强制隔离,而且实现了 MCS 隔离。当 libvirt 将要启动一个虚拟机时,它会挑选出一个 MCS 随机标签如 s0:c1,c2,接着它会将 svirt_image_t:s0:c1,c2 标签分发给虚拟机需要去操作的所有上下文。最终,虚拟机以 svirt_t:s0:c1,c2 为标签启动。因此,SELinux 内核控制 svirt_t:s0:c1,c2 不允许写向 svirt_image_t:s0:c3,c4,即使虚拟机被一个黑客劫持并接管,即使它是运行在 root 下。

我们在 OpenShift 中使用类似的隔离策略。每一个 gear(user/app process)都有相同的 SELinux 类型(openshift_t)(LCTT 译注:gear 为 OpenShift 的计量单位)。策略定义的规则控制着 gear 类型的访问权限,而一个独一无二的 MCS 标签确保了一个 gear 不能影响其他 gear。

请观看下面的视频来看 OpenShift gear 切换到 root 会发生什么。

多级别安全强制

另外一种不经常使用的 SELinux 强制形式叫做 多级别安全 Multi Level Security (MLS);它开发于上世纪 60 年代,并且主要使用在受信操作系统上如 Trusted Solaris。

其核心观点就是通过进程使用的数据等级来控制进程。一个 secret 进程不能读取 top secret 数据。

MLS 很像 MCS,除了它在强制策略中增加了支配的概念。MCS 标签必须完全匹配,但一个 MLS 标签可以支配另一个 MLS 标签并且获得访问。

打个比方

不讨论不同名字的狗,我们现在来看不同种类。我们现在有一只格雷伊猎犬和一只吉娃娃。

Cartoon of a Greyhound and a Chihuahua

我们可能想要允许格雷伊猎犬去吃任何狗粮,但是吉娃娃如果尝试去吃格雷伊猎犬的狗粮可能会被呛到。

我们把格雷伊猎犬标记为 dog:Greyhound,把它的狗粮标记为 dog_chow:Greyhound,把吉娃娃标记为 dog:Chihuahua,把它的狗粮标记为 dog_chow:Chihuahua

Cartoon of a Greyhound dog food and a Chihuahua dog food.

使用 MLS 策略,我们可以使 MLS 格雷伊猎犬标签支配吉娃娃标签。这意味着 dog:Greyhound 允许去吃 dog_chow:Greyhounddog_chow:Chihuahua

 title=

但是 dog:Chihuahua 不允许去吃 dog_chow:Greyhound

Cartoon of Kernel (Penquin) stopping the Chihahua from eating the greyhound food.  Telling him it would be a big too beefy for him.

当然,由于类型强制, dog:Greyhounddog:Chihuahua 仍然不允许去吃 cat_chow:Siamese,即使 MLS 类型 GreyHound 支配 Siamese。

Cartoon of Kernel (Penquin) holding leash to prevent both dogs from eating cat food.

现实例子

有两个 Apache 服务器:一个以 httpd_t:TopSecret 运行,一个以 httpd_t:Secret 运行。如果 Apache 进程 httpd_t:Secret 被劫持,黑客可以读取 httpd_sys_content_t:Secret 但会被禁止读取 httpd_sys_content_t:TopSecret

但是如果运行 httpd_t:TopSecret 的 Apache 进程被劫持,它可以读取 httpd_sys_content_t:Secret 数据和 httpd_sys_content_t:TopSecret 数据。

我们在军事系统上使用 MLS,一个用户可能被允许读取 secret 数据,但是另一个用户在同一个系统上可以读取 top secret 数据。

结论

SELinux 是一个功能强大的标签系统,控制着内核授予每个进程的访问权限。最主要的特性是类型强制,策略规则定义的进程访问权限基于进程被标记的类型和客体被标记的类型。也引入了另外两个控制手段,分离有着同样类型进程的叫做 MCS,而 MLS,则允许进程间存在支配等级。

*所有的漫画都来自 Máirín Duffy


作者简介:

Daniel J Walsh - Daniel Walsh 已经在计算机安全领域工作了将近 30 年。Daniel 于 2001 年 8 月加入红帽。


via: https://opensource.com/business/13/11/selinux-policy-guide

作者:Daniel J Walsh 译者:xiaow6 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

消沉的程序员 1

depressed-developer

很有意思吧,很多看到这样的漫画对话的程序员,应该感觉似曾相识吧。Bug 出现了?

消沉的程序员 2

depressed-developer

有点疑惑,有好像有点眉目,好像是感觉到哪里错了,是不是要重构。

消沉的程序员 3

depressed-developer

哎,终于发现错误了,感觉有点可笑,自己居然犯这样的错误,原来是那次急于提交代码造成的。

消沉的程序员 4

depressed-developer

是啊,在编程里一生戎马,代码编写无数,各种平台、规范等等,到头来也是满身的错误啊。该是技术不行吧!

消沉的程序员 5

depressed-developer

呀,快要消除错误了,可是,不对。相信事后的 Bug 和 Debug 会是程序员生活中的一个部分。

消沉的程序员 6

depressed-developer

每个新建的工程都是有美好的设想吧,可后来为什么总是渐行渐远?大多时候的自言自语,总是有人认为是在和代码对话吧?可没有身在其中,别人又怎么懂得!

消沉的程序员 7

depressed-developer

好吧,产品的上线,总是要经过无数次的创建分支,Bug 和 Debug 总还是程序员的永恒话题。其中,有些东西总免不了自己推翻自己,感觉要从头再来一样。

消沉的程序员 10

depressed-developer

为了某项专门的研究,学习一门相关的语言,不知道是不是值得?是不是先要思考其必要性呢?最后发现自己并不喜欢这门语言,导致怀疑自己的专业技能,这样大概不好吧!

消沉的程序员 11

depressed-developer

其实,本来是愉快的蹲个坑,却不自觉的陷入编码的思考。想想,不仅是程序员,很多人有都有类似此景的情况吧,明明在做着某事,却想着另外一件事。

后记

看至此处,各位朋友是不是感觉少了系列的第 8 和第 9 篇?起初,译者也这么想,后来问了作者 Daniel Stori 之后,才恍然,原来序号采用了八进制,按照作者说的,一个隐式的玩笑。明白了吗,朋友们?

大伙儿都习惯了日常的十进制。当常态处于优先级的时候,日常一些非常态就如同细枝末节,也就往往容易被人们忽略。大概就是这样吧。


译者简介:

GHLandy —— 生活中所有欢乐与苦闷都应藏在心中,有些事儿注定无人知晓,自己也无从说起。


via:

作者:Daniel Stori 译者:GHLandy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

著名的 turnoff.us 有很多有趣的漫画,比如这一副《二叉树》。

在孩子的眼中,世界是另外一种样子。可能在我们大人看来,司空见惯的一些事物,已经掩盖了我们的想象力,但是童稚未去的孩子们往往能观察到我们所忽视的一面,所以,多陪陪孩子吧(首先,你得有个……)。

比如上图中,我们看到的是一颗“普普通通”的树,而孩子看到的是“二进制的树”(二叉树)。(LCTT 译注:此处 Binary Tree 做一语双关状,孩子眼中是“二进制树”,而在搞计算机的老爸听来却是“二叉树”)

嗨,大家好,今天我们来聊聊 80 端口之战。著名的技术漫画站 turnoff.us 有这样的一副漫画,生动的描绘了固守 80 端口的 Apache 和新生代的 Nginx 之间的战争。你知道,80 端口是 Web 端口,就是这个端口构成了我们现在大部分的互联网。

作为新生代的 Nginx 对已经 22 岁之老的 Apache 说,“一边去,老头,这 80 口不用你看着了,你得给新人腾腾地方了!”

头顶羽毛(Apache 的 Logo 形象),身上的写着名字的牌子都是补上去的(a patch,即 Apache 这个词的出处)一脸懵逼,对小毛头 Nginx 说,“放尊重点,你觉得你已经能取代像我这样的老同志了吗?!”

“哈?C10K 你解决了吗?事件驱动呢?这些你行吗?”Nginx 说。(C10K 指并发上万连接,由于服务器和网络性能的提升,现在的服务程序面临着处理更大并发的请求,而一些老旧的应用面对这种大量请求显然有点力不从心)

“嗯,我可以给你一个‘小小’的列表,这都是我支持的模块……” Apache 顾左右而言它。

“这些都过时了!我猜它们根本就没人用过!” Nginx 看着那“小小”的列表,一脸嫌弃的反驳。(讲真,Apache 的很多模块你可能从未用过,尤其是那些内置的模块,而另外一些年久失修的第三方模块,甚至你都不知道能不能用了)

一看这么多模块唬不住 Nginx,Apache 又把 PHP、MySQL 等小弟叫出来助阵,“这些都是我的铁杆兄弟!”

“嘿,谁怕谁啊,谁没兄弟啊,我也有啊” Nginx 拽出来焕发了第二春的 Postgres 数据库和曾经的明日之星 Ruby,不过感觉这些兄弟们有点不太给力 :-d 。

那么你猜猜谁会赢?买定离手啊~

今天,我来为大家解读一幅来自 TurnOff.us 的漫画 “InSide The Linux Kernel” 。 TurnOff.us 是一个极客漫画网站,作者Daniel Stori 画了一些非常有趣的关于编程语言、Web、云计算、Linux 相关的漫画。今天解读的便是其中的一篇。

在开始,我们先来看看这幅漫画的全貌!

这幅漫画是以一个房子的侧方刨面图来绘画的。使用这样的一个房子来代表 Linux 内核。

地基

作为一个房子,最重要的莫过于其地基,在这个图片里,我们也从最下面的地基开始看起:

地基

地基(底层)由一排排的文件柜组成,井然有序,文件柜里放置着“文件”——电脑中的文件。左上角,有一只胸前挂着 421 号牌的小企鹅,它表示着 PID( 进程 ID Process ID ) 为 421 的进程,它正在查看文件柜中的文件,这代表系统中正有一个进程在访问文件系统。在右下角有一只小狗,它是 看门狗 watchdog ,这代表对文件系统的监控。

一层(地面层)

一层(地面层)

看完了地基,接下来我们来看地基上面的一层,都有哪些东西。

进程表

在这一层,最引人瞩目的莫过于中间的一块垫子,众多小企鹅在围着着桌子坐着。这个垫子的区域代表进程表。

左上角有一个小企鹅,站着,仿佛在说些什么这显然是一位家长式的人物,不过看起来周围坐的那些小企鹅不是很听话——你看有好多走神、自顾自聊天的——“喂喂,说你呢,哇塞娃(171),转过身来”。它代表着 Linux 内核中的初始化(init)进程,也就是我们常说的 PID 为 1 的进程。桌子上坐的小企鹅都在 等待状态 wait 中,等待工作任务。

看门狗

瞧瞧,垫子(进程表)两旁有两只小狗,它会监控小企鹅的状态(监控进程),当小企鹅们不听话时,它就会汪汪地叫喊起来。

http 进程

在这层的左侧,有一只号牌为 1341 的小企鹅,守在门口,门上写着 80,说明这个 PID 为 1341 的小企鹅负责接待 80 端口,也就是我们常说的 HTTP (网站)的端口。小企鹅头上有一片羽毛,这片羽毛大有来历,它是著名的 HTTP 服务器 Apache 的 Logo。喏,就是这只:

apache logo

向右看,我们可以看到这里仍有一扇门,门上写着 21,但是,看起来这扇门似乎年久失修,上面的门牌号都歪了,门口也没人守着。看起来这个 21 端口的 FTP 协议有点老旧了,目前用的人也比以前少了,以至于这里都没人接待了。

无人看守的 FTP 进程

而在最右侧的一个门牌号 22 的们的待遇就大为不同,居然有一只带着墨镜的小企鹅在守着,看起来好酷啊,它是黑衣人叔叔吗?为什么要这么酷的一个企鹅呢,因为 22 端口是 SSH 端口,是一个非常重要的远程连接端口,通常通过这个端口进行远程管理,所以对这个端口进来的人要仔细审查。

SSH 守护进程

它的身上写着 52,说明它是第 52 个小企鹅。

到达文件系统

在图片的左上角,有一个向下台阶。这个台阶是底层(地基)的文件系统中的,进程们可以通过这个台阶,到文件系统中去读取文件,进行操作。

Cron 任务

在这一层中,有一个身上写着 217 的小企鹅,他正满头大汗地看着自己的手表。这只小企鹅就是定时任务(Crontab),他会时刻关注时间,查看是否要去做某个工作。

管道

在图片的中部,有两个小企鹅扛着管道(PipeLine)在行走,一只小企鹅可以把自己手上的东西通过这个管道,传递给后面的小企鹅。不过怎么看起来前面这种(男?)企鹅累得满头大汗,而后面那只(女?)企鹅似乎游刃有余——喂喂,前面那个,裤子快掉了~

Wine

在这一层还有另外的一个小企鹅,它手上拿着一杯红酒,身上写着 411,看起来有点不胜酒力。它就是红酒(Wine)小企鹅,它可以干(执行)一些来自 Windows 的任务。

跃层

在一层之上,还有一个跃层,这里有很多不同的屏幕,每个屏幕上写着 TTY(这就是对外的终端)。比如说最左边 tty4 上输入了“fre”——这是想输入“freshmeat...”么 :d ;它旁边的 tty2 和 tty3 就正常多了,看起来是比较正常的命令;tty7 显示的图形界面嗳,对,图形界面(X Window)一般就在 7 号终端;tty5 和 tty6 是空的,这表示这两个终端没人用。等等,tty1 呢?

跃层

tty(终端)是对外沟通的渠道之一,但是,不是每一个进程都需要 tty,某些进程可以直接通过其他途径(比如端口)来和外部进行通信,对外提供服务的,所以,这一层不是完整的一层,只是个跃层。

好了,我们有落下什么吗?

小丑?

这小丑是谁啊?

啊哈,我也不知道,或许是病毒?你说呢?