工作的前奏—关于目录保护与安全级别

单点安全策略单向安全策略是最安全的，安全监测点越多越容易造成漏洞，linux的策略很好，但是如果你将那个所谓的单点给突破了，那么不要试 图补救，如果补救，看似负责任，实际上往往会把问题越搞越乱，单点监控被突破只能说明一个问题，就是这个单点监控点设置的不好，既然出问题了，那就到此为止吧。
     linux中的root权限控制就是一个很好的例子，/sbin下的命令都是一般用户所不能使用的，这些命令往往都是服务性质的而不是用户任务相关的，比 如格式化磁盘等等，在linux中，一旦root权限被黑客拿到了，那就不要指望任何保护机制起作用了。我认为linux的这种方式十分安全，有人认为它 很不安全，因为root的权力过大或者以为root太容易得到，可是不能这样就说系统不安全。linux对root的控制还是很到位的，所以一般不要随意 用root直接登录，如果需要执行root才能执行的命令，请使用sudo，这样一个额外的sudo输入会减少你很多的误操作。中国的古代之所以比西欧要 稳定就是因为中央集权，皇帝权力很大，因此他的臣民才不敢乱来，因此也就有了中国人天生的奴性，西欧社会一直都很松散，灵活多变的同时，社会的不稳定因素也很多。linux的安全模型很简单，基本从unix继承而来，很多非unix的系统，比如windows，设置了复杂的安全限制模型，即使一个失败了，下一个还是会尽其所能努力拦截恶意攻击，即使是管理员帐户也不能进行某些操作，比如删除正在使用的文件，windows的文件打开参数过于复杂。越复杂的东西就越容易多问题，这是一个真理，亘古不变的真理，在别的方面可能复杂的东西拥有其特殊的卖点，但是对于安全而言，千万不要指望复杂可以提高安全性，往 往会在相反的方向走的很远很远。
今天看到一个我们竞争对手的产品，我好好研究了一下这个产品，它是linux下的一个网页防篡改的产品，起初我以为它们会使用内核模块的方式在内核做文 章，但是它们不是这么做的，它们允许用户设置被保护的目录，然后这个目录就不允许被修改了，具体使用一个妇孺皆知的chattr -i命令做到的，然而我的疑问就是root用户可以用chattr -i来取消这种更改，因此这种方式根本起不到保护目录的目的，然而当我用root登入系统，用chattr -i来取消这种保护的时候，得到的却是一句很莫名其妙的结果，中文意译就是“你没有这个权力这么做”，好酷啊，难道linux也有像BSD系统中的 securitylevel那么神奇的单向安全流机制吗？我想linux中应该没有这种机制的，BSD的安全等级机制确实很好，不仅实现了root的权限 限制这种静态的安全管理机制，而且实现了动态的安全等级设置管理机制，一旦安全等级被抬高就不能再降低，linux中没有这种机制，将一切都交给了 root，因此root权限本身的保护就显得格外重要。好了回到刚才的那个话题，他们的程序怎么做到禁止chattr -i的呢？答案就是他们的软件在安装的时候替换了系统的chattr命令，好酷，我不得不再说一次，真的好酷！但是我不得不说的是，他们的这种方式十分的不适合linux，如果将那个被保护的目录设置成只读，然后坚决不给任何用户root权限，一切保护就很简单的实现了，然而那家公司可能在windows 平台上中毒太深以至于不可自拔，最终采用了这种很障眼术，试想我怎么不容易发觉系统命令被替换，当我遇到那个莫名其妙的提示的时候，我就下意识的感觉到该程序替换了系统命令，然后我从别的系统拷过来一个原本的命令，一切不攻自破，试问一旦黑客知道了系统命令被替换，这种方式提供的保护还有一丁点作用吗？还 是花大力气保护和管理root帐号吧！再者说了，系统命令被替换了，其它程序的兼容性受到了影响，我开始做文件变化监控的时候，曾经用过inotify， 但是会有遗漏，原因我的另一篇文章已经说了，我当时想过修改内核源代码，将sys_open中create完目录以后，先将该新目录加入到 inotify_watch之后再返回，这样就不会有将该目录加入到watch和在该目录内创建新的目录或者文件之间的空隙了，但是我最终还是放弃了这个 方案，为了我们自己一个服务，在内核中大开方便之门实在不应该啊，内核会因此而多走很多判断的路径，很耗费时间和空间的，万恶之源，看来一些官僚们真的因该反思一下了。关于改内核以适应inotify还有一点要说，就是将新目录加入watch是一个策略而用户不一定需要这种策略，可能他只想监控一个文件或者不递归的监控一个目录，内核不应该有任何默认的用户策略，这样的话同样会引入额外的判断路径，至于说inotify中存在的那个遗漏问题，可以通过用户空间解决，比如重新编写cp，tar等命令，在inotify递归监控的情况下，严格和inotify同步，就是说在新目录加入watch之后再开始新的 拷贝或者XX，另外一种方式就是补救措施，就是采取二次遍历的方式，先是由inotify以中断的方式监控到文件系统变化，然后马上采取轮询的方式主动遍 历文件系统，这第二次中将第一次遗漏的文件变化信息弥补回来，总之完全可以通过用户空间完成。