- 31
- Aug
Ubuntu Tweak 0.4.9要跳票啰！
因为一个重要的安全隐患没有解决，可能会阻碍Ubuntu Tweak进入Ubuntu 9.10，所以就跳票了，但愿只跳一週吧。
自从Ubuntu Tweak引入了PolicyKit功能以后，这个安全隐患就一直存在了，只是我一直没注意。直到两个多月前，Ubuntu Tweak 0.4.7.2发布，J.Z指出了这个问题，参见：http://linuxdesktop.cn/2009/06/21/ubuntu-tweak-0-4-7-2.html#comment-10833
原来此前我一直没有真正用好PolicyKit，以为用PolicyKit调用个验证窗口就了事，还开着个系统级的，谁都可以调用的dbus服务。于是成了安全隐患。
那么，究竟怎样设计才安全呢？我研究了一下Ubuntu系统的其他组件，发现应该是这样的：
- 一个dbus服务，做一些真正的系统级方法和调用，只允许root调用和拥有，不允许其他用户调用（这样就保证了普通用户不能随便调用）；
- 一个policykit服务（基于dbus服务，可以与上面重叠），root用户拥有，允许普通用户调用，用于验证，验证通过后，可以将其作代理来调用上述真正的dbus服务，也就是说，用户真正打交道的是它；
之前，我却做了下面错误的设计：
- 一个dbus服务，允许root调用和拥有，也允许其他用户调用（这么一来，任何人都可以写一个script，来调用我在代码中定义的危险的dbus方法了）；
- 一个policykit服务，用户只调用来作无意义的验证而已；
明白了这些后，我发现仅用Python无法实现一个足够安全的验证机制，因为根本没有Policykit for Python的API，只能用Python来通过dbus调用Policykit进行验证而已。
所以，我将在Ubuntu Tweak用C代码实现一个纯代理的daemon来实现这个安全的机制。
现在关于这个新的验证机制在real-policykit分支中已经开始实现了，但愿很快就可以完成。
不知这个逻辑..祝早日解决问题～哈哈
就是说让policykit做代理 授权用户 运行dbus的系统服务
可以参考设计模式的 代理模式
呵呵。没有完全看懂，可是直到这个应该是一个严重的安全隐患吧。不然怎么会跳票呢..
而且现在的 Ubuntu-tweak 没有使用 policykit 的记住认证功能，而是使用 gconf 记录，这也是个小漏洞吧……毕竟普通用户就可以修改 gconf 了……