Security

之前和 A core 聊过这个问题。整理一下发出来。

这个话说的可能比较绝对，有人说，缺少信任的社会是可悲的—-而我想说的是，现今，被过度滥用的信任则是可怕的。通过各式各样的社交网站，如 Facebook、LinkedIn、开心网、天际网等等（我想有人会提到 豆瓣，但是我个人认为豆瓣算是一个比较另类的社交网站，因为上面的人很少使用真名），很多人之间的联系被轻易地挖掘和利用。

我这次不铁口直断了，估计明年见了，如果这周能够RC2的话，最终RELEASE估计要到明年的1月5日左右。

这次FreeBSD 7.1在软件工程角度是相当失败的案例，我想我们应该从里面总结一些教训出来。

首先，我们的目标是什么？

我想，用户对于一个发行版本的期待是：一个经过了大量测试的、阶段性的稳定版本。而开发人员对于发行版本的期待则是尽可能地将可用的功能交付给用户。作为OS，我认为这应该包括自动化的回归测试、性能改进、更新的驱动程序、文档的修订，以及更新的第三方软件等等。

FreeBSD目前的开发模式，是将分别开发的三大模块，即内核与基本系统(src/)、文档(doc/)、第三方软件(ports/)的人在一定的时候聚集在一起，通过代码冻结的方法来使他们从增加新功能转移到集中去修bug，最后发布一个版本。这个模式在过去运转的相当好，以至于我们没有发现其中存在的问题。

这次FreeBSD 7.1暴露出来了这个模式存在的很多问题。例如，由于安全小组发现了很多安全漏洞，而另一方面，安全小组的人手不够，限制了修正这些问题的速度。我本人撰写的一个安全公告等了一个月才在今天最终公之于众，而另一方面，安全小组对于发行版本拥有一票否决的绝对权力，导致6.4和7.1的发布都一再推迟。

而作为非常快节奏的开发的 ports/ 维护者，则对不断的推迟感到相当不满。FreeBSD目前只维护 ports/ 的 -HEAD，也就是说，在正式发行 -RELEASE 之前，ports/ 不能进行大量的、破坏性的修改。例如，我本人维护的 OpenLDAP 现在就必须等待 -RELEASE 之后才可以进行升级。不断地推迟新的发行版本，会导致 ports/ 的开发继续延迟。

在Hotmail里面收到了很多假开心网的邀请信。点开一看，恶心的来了：填好了MSN地址，然后让你填密码。

这家公司真恶心。

Bruce Schneier大师说，DNS漏洞的细节还是被提前披露了，人们开始撰写利用这一漏洞的攻击程序，等等。这里摘录一些比较精彩的内容，推荐您阅读原文。

然而，因此而对 Kaminsky 展开口诛笔伐显然是不对的。在圈外人士看来，也许如果他在这个事情上缄口不语，我们便不会有这许多的麻烦。这显然是不对的， Kaminsky 偶然发现了这个问题，他没有理由相信自己是第一个，更没有理由相信自己是最后一个发现这些问题的。问题出在 DNS 协议本身，而不是 Kaminsky。

最近炒的比较火的一个漏洞是 DNS 协议本身发现的一个严重问题（CERT VU#800113）。国内媒体对此的报道多数都语焉不详，因此我想有必要说说这个漏洞到底是怎么回事。

一段鲜为人知的历史。

据考证，世界上公认的第一封垃圾电邮，是1978年5月3日由 DEC 公司的销售代表 Gary Thuerk 发出的，两个行业随后相继诞生。

今天在 车东 的 blog 上看到一篇说 关于邮件安全的文章，这里也说说我对这个问题的看法。

基于邮件的 XSS 问题其实是困扰 Webmail 供应商的一个很严重的问题。其实，未必是 XSS，有时可能是更简单的内存泄露问题。比较简单的是我 1999 年左右在某国内邮件服务提供商提供的邮件服务发现的一个问题，即，一方面我可以发脚本，获得 cookie；另一方面，我可以用 HTML 去构造一个特殊的 GET 请求（通过 IMG tag）来把这些cookie拿到。

接下来的故事就很简单了，攻击者通过在本地种这些 cookie，便可以访问收到并打开邮件的用户的邮件。严格地说，这甚至算不上一个跨站脚本攻击。解决方法也很简单，在服务器端的session中保存用户的登录 IP 地址。

然而，新一代的攻击变得越来越复杂了。一种典型的攻击是，发送垃圾邮件的人通过各种方法令你访问某个特定的 URL，并借此确认你的邮件地址有效。

Finally found some time to do this, upgraded to 4.1, perhaps this will be faster?

This version is a security update. Is 4.1 production-ready? Who knows…

FreeBSD 从 4.0 版本开始提供了非常强大的虚拟化工具—-jail。对于许多应用来说，jail能够在确保应用程序之间的有效隔离的前提下，最大限度地发挥硬件性能（每个jail不会单独运行自己的内核），而在 jail 内部看来，则基本上与真正的服务器无异，且性能损失很小；通过内核提供的 ABI 模拟，jail能够提供 FreeBSD 早期版本，以及 Linux 2.4.x 或 2.6.x 的兼容能力。

许多传统的 Unix 应用程序假定系统中存在一个可用的 MTA。FreeBSD 中内建了 sendmail，但在 jail 中配置 sendmail 会遇到一个比较麻烦的问题，即在 jail 中，127.0.0.1 指代的是 jail 的 IP 地址而不是本地 loopback 设备。换言之，原本监听本地 socket 的 MTA 变成了监听 jail 对外的 IP，这会是一个安全隐患。

虽然不做邮件很久了，不过自己有在维护一些社区的邮件列表系统，所以对这方面也比较关注。

以前一直没有仔细研究过Mailman关于退信的处理，最近遇到了一些问题，也看了一些 RFC，这里面提到了一个问题，即，与所有其他的电子邮件类似，退信也是可以伪造的。而对于邮件列表而言，出于建设和谐社会的考虑，往往希望对于经常退信的订户自动采取暂停订阅甚至退订的动作，以减少双方不必要的邮件投递流量。