SELinux 相关链接

今年的主要成果就算是对SELinux的一点研究了,没搞到内核源代码的级别去,不过至少对它的使用、配置、troubleshooting以及策略编写是熟悉了。

FAQ里面算是总结的一些对SELinux使用常见的一些问题了,后面还有些实用链接,不过真的要学习SELinux的话,光这些是远远不够的。

1.  FAQ

1.1. 是否应该开启SELinux

Q: 系统安装完之后,SELinux 默认是开启的,但是它导致了我部署的非常多的应用无法正常运行,所以我把它关闭了。但是现在又有很多人提倡不要关闭SELinux,甚至还专门为此建立了一个网站——http://stopdisablingselinux.com/ ,请问关闭SELinux 真的会使得系统不安全吗?我到底是该关闭它还是不关闭呢?

A:

简短版:

如果您对是否应该开启SELinux 有点犹豫,那么您应该关闭它。

详细版:

关闭SELinux 并不一定是等于降低系统安全,系统的安全最重要的是取决于运行在上面的程序本身,SELinux 只是一个防护机制,它也并不能从根本上消除程序里面的bug。相反,如果用户并不熟悉使用SELinux 的话,他会在使用过程中遇到许多有SELinux 导致的“未知原因”故障,在不知情的时候,用户往往会采取其它的比如:关闭防火墙,关闭程序自身的保护措施来排查问题,这反而是导致了其它安全防护措施的去除,并且也严重影响了这些用户对系统的正常使用。

许多人提倡保留开启SELinux 的原因是现在的发行版自带策略已经可以使得用户基本无法感受到SELinux 的存在,但这并不是绝对的,在运行httpd,ftpd,samba 等服务的时候还是很容易遇到被SELinux 策略阻止而导致的访问拒绝。而发行版自带的策略包里面还会有bug,导致一些难以排查的错误。用户如果要学习SELinux 也并不容易,SELinux 非常复杂。

所以,如果您运行的系统上面没有关键的应用或者数据,或者没有足够的排查、解决SELinux 问题的能力以及比较多的耐心和时间来学习SELinux 的话,建议从实际出发,把它关掉。

1.2. 开启和配置SELinux

Q: 怎样开启和配置SELinux

A建议首先将/etc/selinux/config 文件中的配置修改为Permissive 模式后重启,在Permissive 模式下所有的AVC 访问拒绝都会被记录,但并不会真的拒绝。重启系统后,请您使用aureport -a 命令查看在启动过程中有哪些AVC产生,直到将所有的AVC都消除后,再将配置由Permissive 模式改为Enforcing 。

1.3. 设置SELinux为Enforcing模式后系统无法启动

Q: 我将它设置为Enforcing 模式重启后,系统都起不来了!连单用户模式都无法进入,只能再用光盘进行修复了吗?

A: 不需要。在grub 的kernel 行加上selinux=0 的参数即可禁用SELinux 进入系统。

1.4. 如何正确修改文件安全上下文

Q: 我的网站文件放在/web 目录下,但是SELinux 导致网站无法正常运行起来,我把/web目录的context 改成了httpd_sys_content_t 等类型后可以正常运行网站了,但是重启系统后就又变回原来的default_t 了,有什么办法可以使对/web 路径的context 修改永久生效吗?

A: 这种情况下正确的做法是手动为您使用的非系统默认路径创建默认context 规则,使用semanage fcontext 命令:

semanage fcontext -a -t httpd_sys_content_t “/web(/.*)?”

然后执行

restorecon -Rv /web

应用对/web 目录添加的策略规则。

1.5. 能否只针对某一个服务关闭SELinux

Q: 既然系统默认的targeted 策略是针对各个服务而编写的,那么我可以只针对Apache httpd 服务或者vsftpd 关闭SELinux 吗?

A: 可以。永久关闭httpd 策略:

setsebool -P httpd_disable_trans on

另外还有,永久关闭vsftpd 策略:

setsebool -P ftpd_disable_trans on

提示:使用getsebool -a | grep disable_trans 命令可以找到其它更多的关闭某一项服务策略的布尔值。

1.6. 确认某一个路径的文件context 规则

Q: 如何确认某一个路径的文件context 规则?

A: 简单检查某个路径的安全上下文可以使用matchpathcon命令,比如:

matchpathcon /var/www

但是matchpathcon并不能查看是哪一条规则决定了/var/www 路径的安全上下文,这需要semanage fcontext -l命令查看。

1.7. 遇到AVC 的时候怎么办

Q: 遇到AVC 的时候怎么办?

A: 如果您确实需要保持SELinux 开启的话,请采用以下步骤解决AVC:

1、首先应该使用getsebool -a命令查看是否有某个布尔值决定了您程序的访问被拒绝;

2、留意您的文件是否被贴上了正确的安全上下文

3、如果以上都不符合。使用audit2allow 工具创建新的模块,并且加载

1.8. 域和类型的区别是什么

Q: 域和类型的区别是什么?

A: 域和类型之间没有区别,虽然有时候域是用于指代进程的类型。域的这种用法是出于域-类型强制模型(DTE),这个模型里面的域和类型是分离的。

2.  参考资料

目前SELinux的使用还并不是非常的广泛,因此能找的相关配置和原理等文档也比较少。这些是我目前所找到的一些很有用的资料,但不是全部。

http://danwalsh.livejournal.com/

一个资深红帽SELinux专家的博客,里面有非常多的实用信息。

SELinux from the inside out

Google 安全人员对SELinux 的一些引导研究,稍微涉及到了内核代码

http://selinuxproject.org/page/Main_Page

SELinux项目的官方wiki

http://www.crypt.gen.nz/selinux/faq.html

https://docs.fedoraproject.org/en-US/Fedora/13/html/SELinux_FAQ/

Fedora SELinux FAQ

启用IPv6

今天才记起来所用的这个vps提供商其实是支持IPv6的,所以把它启用了

在现在的主要服务——web,email 等上面的配置都并不复杂,稍微再花了一点时间在改ip6tables脚本上面了。

UEFI安装及卸载Linux

在启用了secure boot的笔记本上面装了一下Kubuntu 13.10,体验还是比较差,于是把它又卸掉了,安心的用Windows 算了,以后要是还能搞个台式机再跑Linux 吧。这里记一下整个安装及卸载过程。

其实安装引导的过程没有想象的复杂,用unetbootin 做个u盘启动就行了,开机按Esc 可以自动识别出U盘,加载也没有问题,因为(K)ubuntu 新的版本已经兼容secure boot。但后面的东西比较让人不爽,先是进入安装界面都会被nouveau 驱动把内核搞挂(加nomodeset 启动参数解决),而安装上去后,即使安装了Nvidia 官方驱动,图形界面性能还是太差。而另外的问题还有plasma-nm 记不住WiFi 密码,DPI 放大后整个桌面太不和谐(不放大更不能用,太小)等问题。

于是在用了一天后,我决定卸载它。先是在Windows 里面把几个Linux 分区干掉了,然后使用管理员权限执行cmd,运行

bcdboot c:\windows /l zh-cn

就修复了启动管理器。或者用bcdedit 去编辑也行。。。

如果还和我一样,对于系统EFI 分区底下还有个没用的ubuntu 文件夹存在而不自在的话,可以以管理员身份进入命令提示符,用diskpart 给EFI 分区分配盘符,然后cd 进去直接rd /s /q ubuntu 就行。

Farewell Google Reader!

Google Reader 已经关掉好几天了,貌似我才反应过来,想为自己给这个用了很久的一个因特网服务写点东西。
我大约在2009 年才开始使用Google Reader ,之所以说“才”,是因为我的那个Google 帐号是07 年就注册了的,但是却一直没有开通Reader 这个服务。尽管那时候早就听说过Google Reader ,但是因为在09 年之前我一直不明白这个东西能有个啥现实意义,就一直连试都没试过使用它。当时我就一直在想——“这玩意儿听起来挺傻的,RSS 本来就是由各个网站提供了的,要去看有什么更新了,我会直接打开那个网站看。实在是想“追”,我可以用浏览器的RSS 订阅功能添加它”,我不明白把其它网站的更新放到一起在另外一个网站上面又有什么意义,我还是得要用浏览器去打开网站。但是后来有个事情改变了我的看法,因为当时对一个博客比较感兴趣,但那个博客被GFW 给屏蔽了,不使用VPN 等打不开。但后来我听说使用Google Reader 可以直接订阅那个博客的RSS(博主设置了全文输出),于是开着https://www.google.com/reader (这里粗体的s,常用Reader 的人应该都知道它的重要性吧)。于是自此从一开始傻乎乎的到处乱订阅,搞得整天“1000+”,到后来逐渐筛选,每天的未读条目不会超过100.

这里我想说下,一开始我的确是把Reader 给用错了的,整天“1000+”绝对不是一个好现象,这说明资讯远远过剩了。而这是因为一开始的时候我把它当作新闻获取来源了,但实际上,Google Reader 不应该充当这个角色。为什么?因为一般的新闻你真的不需要专门再去订阅某个网站去知道它的了,这类信息早就已经是过剩了的,你可以随便从某个常访问的网站获取到它,甚至从朋友、同事的口中知道。再后来一点,我觉得Reader 最好是作为一个订阅一些有用的博客的工具使用了。我把订阅源减少到了不到200 个,其中大部分都是一些朋友的、或者我自己觉得有趣、有用的个人博客,更新量较少。我不同意是诸如Twitter、facebook 这类的社交网站杀死了Google Reader ,我还认为Google Reader 这样的RSS 聚合阅读工具是它们无法替代的。实际上不是什么东西都需要有“社交”元素的,而且从实用性来讲,我根本就没法从社交网站上面去追踪原来订阅的那么多博客的更新。因为不是谁都会把自己今天写了什么高调的唯恐有人不知道一样的同步到社交网络中去,而浏览器的RSS 订阅工具显然也无法满足这么多个博客一起订阅的需求,并且,那还得由你本地开了浏览器之后,它才帮你搜索RSS 更新。

所以我觉得Google 非要把Reader 关掉实在是有点不厚道,因为Google+ 永远也替代不了Google Reader,更别提现在Google+ 自身就不咋的。
本来我是打算等Google Reader 关掉后,我干脆直接抛弃掉那200来个订阅源了。毕竟,如果真的需要,我最终还是会去搜索引擎找信息的,所以我就想——干脆换个网上的生活方式吧。但是既然还有Digg Reader、feely 这样的不错的新生工具出现,我觉得其实我的生活也没啥变化的了。

Back to Firefox!

最近打开Chrome 流浪网页是越来越吃力了,于是重新把默认浏览器设置回味Firefox 了。(现在的Firefox 也还是可以用了的,而且毕竟在Windows 上面,它的字体渲染比Chrome 好太多)

好吧,我这电脑的配置确实不如现在的一个高端一点的智能手机强了…

C:\Users\xxx>systeminfo

Host Name:                 xxx-PC
OS Name:                   Microsoft Windows 7 Ultimate
OS Version:                6.1.7601 Service Pack 1 Build 7601
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free
Registered Owner:          xxx
Registered Organization:
Product ID:                xxxxxxxxxxxxxxxxxxxxxxxx
Original Install Date:     6/27/2010, 3:22:11 AM
System Boot Time:          7/7/2013, 11:33:10 AM
System Manufacturer:       NVIDIA
System Model:              AWRDACPI
System Type:               X86-based PC
Processor(s):              1 Processor(s) Installed.
[01]: x64 Family 15 Model 107 Stepping 1 AuthenticAMD ~2096 Mhz
BIOS Version:              Phoenix Technologies, LTD 6.00 PG, 12/4/2007
Windows Directory:         C:\Windows
System Directory:          C:\Windows\system32
Boot Device:               \Device\HarddiskVolume9
System Locale:             zh-cn;Chinese (China)
Input Locale:              en-us;English (United States)
Time Zone:                 (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi
Total Physical Memory:     2,046 MB
Available Physical Memory: 117 MB
Virtual Memory: Max Size:  4,093 MB
Virtual Memory: Available: 1,509 MB
Virtual Memory: In Use:    2,584 MB
Page File Location(s):     D:\pagefile.sys

bash: $RANDOM 不够randomly?

为了小小的测试一个东西,写了一个小脚本,想将ftp取下来的文件随机命名(file.32489, file.324, file.xxxx这样)。

本来用file.$RANDOM 这样的方式生成文件名(在我看来,使用这个内置的bash 变量来达到目的会是个很简单的方法),但结果却不尽如人意:1000次循环跑下来,“取”下来的文件却只有981个,这不是取文件时失败了,而是有重名,导致文件被覆盖了。$RANDOM 的范围是0~32767(bash(1)),循环一千遍就出现19次重复了。。。

于是又费神写了一个复杂点的随机字符生成函数。哈,终于没有重复了!

但后来再一想,有点不对劲,脑子似乎不太灵光。一个$RANDOM 不够随机,两个、三个活着更多不就完了?

file.$RANDOM$RANDOM$RANDOM….

缩略网址的乱用

缩略网址(Short URL)其实是完全只适合用在象微博客这样“惜字如金”的地方的,但现在很多时候都被滥用、乱用了。

为什么要用缩略网址?因为很多像twitter 这样的微博服务只让用户发表最多140字的信息,若在内容里插入了一个很长的URL,则用户可能无法再有足够多的字数来表达对URL 内容的描述。于是像bitly、tinyurl 这样的缩略网址服务应运而生。除了省略字数之外,缩略网址带来了以下优点:

  • 可以将复杂的URL 简单化,易记。比如:bit.ly/opera_permissions
  • 利用缩略网址进行简单点击数统计。goo.gl 即提供了这个功能,生成缩略网址的用户可以方便的查看此网址通过缩略网址被查看了多少次。

但是缩略网址的缺点相对于有点却更加多,这使得它在极少数情况之外下根本就不应该被使用。

维基百科对它的缺点有总结。而对于我个人来说,厌恶缩略网址的原因则是它的“隐藏性”。通常我们所见到的缩略网址都是随机的几个数字加字母如(http://wp.me/p1szw2-1F),这的确使得它很短,但它不具可读性。这种做法将读者与原始的URL 完全隔开了。

来看看这张图吧,你能知道点击了缩略网址后你到底将会被定向到哪个地方么?

再来看看twitter 的做法吧:

实际上它是个短网址(见图片左下角的URL),但为了用户的可读性,它将其解析为原始URL 呈现在了读者面前,这样即省略了字数,而读者也不会被缩略网址欺骗、迷惑。twitter 的做法才是正确的。