仓库源文

:Authors: Kenneth Lee :Version: 1.0

安全建模问题讨论

前两天有人在我这里给我讲操作系统和芯片设计安全，自称自己是做飞机背景的，对安全有很多成功经验，要教我怎么用建模语言来做操作系统安全建模。

实话说，我对此毫无兴趣（教我东西我本身是有兴趣的，但没有干货逻辑让我实施这个东西我就没有兴趣了）。但一方面不适合在现场和人激烈对抗，另一方面当面讨论没法建复杂逻辑。所以当时我没有深入谈这个问题。现在退下来，我开始整理一下逻辑链。

首先，从架构的角度说，我是本能不接受你随便给我一个新概念，然后说可以解决我一个非常基本的问题。你可以说我这个人封闭，但如果一个架构师看到一个新概念那就深入研究它，这个架构师基本上就不可能守稳基本盘。我会学新东西，但我会根据优先级进行排队，无论如何我不会接受你告诉我一个新概念，然后就问我为什么不实施起来，你问这个问题我都觉得你肯定是个外行。

什么是安全呢？我来做一个窄一点的定义吧。我们很多时候谈安全，数据和控制安全。简单说，就是让人访问（包括修改，删除等，下同）他有权利的数据，下被授权的命令，同时保证让他不能访问他没有被授权的数据，不能下没有被授权的命令，或者让这样的命令无法实施。

攻击者可以攻击这个定义中的方方面面。比如攻击安全边界（例如利用系统调用定义上的缺陷提权），伪装身份（例如通过社交攻击骗取用户的密码），使用边际效应（比如侧信道攻击）。攻击方法是不可能被穷尽的或者彻底终止的，因为从停机问题的证明看来，我们不能证明一个系统是没有Bug的。

所以，根本没有“操作系统的安全模型”，因为安全从来都是从整个系统的角度来设计的，没有单个部件的（比如操作系统）的安全模型。我不管你是什么建模语言或者方法。

这位推崇安全建模的兄弟Argue说，只要进行合理的抽象，就可以基于这个抽象建立一个安全的定义。抱这种想法的人缺乏对软件特点的基本认识。软件是发展的。我们理解一下我们前面建立的那个安全的定义。我们的系统掌握了一些数据，你把这些数据切几刀，部分可以让这一个身份访问，另一部分可以让另一个身份访问。这时安全是什么？安全需要你定义这些数据分别属于哪个哪个域，对不对？那么现在你告诉我，从“操作系统”这个层面来抽象（看不见具体的数据的业务属性），你如何“抽象”什么数据是属于什么用户的呢？

你也许还会Argue说：“你不用管这个，只要你把隔间给出来就好了”。那我就问了，今天操作系统是不是不增加功能的？每个增加的功能是否都有要相应的隔间？对于这些新功能，我原来的抽象怎么做到Cover它？

如果你真得是完全外行，我估计你还要Argue：“有新功能就增加这个模型好了”。好嘛，每个新功能你加一个安全模型，你这还叫安全模型吗，还是抽象吗？

安全模型和功能模型是不一样的，功能模型是多一个功能，少一个功能，基本上不影响其他功能的。而安全是，多一个漏洞，整个模型就全部失败了。你说你可以抽象？

我不反对比如飞机这样的东西说不定可以有一些安全抽象，但它肯定是建立在高扇入低扇出的基础上的，说到底，你是基于功能来进行这个东西的抽象。讨论里还有人说比如加密算法是可以抽象出模型的，这同样是功能单一的强行应用的模型。但你先要搞清楚，IT业的OS和芯片可不是这样的东西。这其实再次验证了，不要拿你自己领域的成功经验，没有任何调研的情况下，随随便便引入到另一个领域中。

我过去做过一个平台，但凡他搞不定的事情，他们就把那个功能抽出来，把功能交给产品线自己去解决。然后这个平台就实现“十年网上无事故”了。然后这个平台就变得微不足道，最后被合并到产品线里面去了。在名义上冰清玉洁，独善其身的结果，通常就是这个。你解释通了而已，问题根本没有解决。你把操作系统单一化，认为它只有这个功能，你当然可以建一个模型出来，但操作系统面对的是这样一个问题吗？

前段时间我还回答过这个问题：从黑客提取内核root权限的难度来说，微内核OS是否会相对于宏内核OS更安全？。这是一样的问题，你把驱动拉到用户态去，这个系统更安全了吗？攻击一个用户态程序就完成对一个IO端口的控制了呀。这安全还是不安全？完全看你的保护要求是什么。

所以，对系统的安全进行建模，没有可以脱离业务的，根本没有什么“操作系统安全建模” ，或者“芯片安全建模”这种说法，我们只有“业务安全建模”。然后你要“建模需求落地为操作系统某个需求”，这我信。脱离业务搞操作系统本身的安全建模？你先对操作系统的安全机制有点认识再说吧，等你理解了这里的复杂度以后还敢在这个大言不惭的，我就佩服你了。

安全安全，最安全就是手上没有数据。这绝对安全，所以纸上谈兵总是可以建模的，你忽略了实际情况了么。