在Varnish中,安全问题是一项非常重要的设计驱动力,当你意识到”他为什么 _那样_ 做呢?”,就需要使用安全角度来寻找答案。
Varnish安全模型基于一些粗糙但是易于理解的障碍实现,障碍存在于各个组件之间:
.-->- provides ->---------------------------------------.
| | |
(ADMIN)--+-->- runs ----->---. | |
| | | |
|-->- cli_req -->---| v v
'--<- cli_resp -<---| VCL MODULE
| | |
(OPER) | |reads |
| | | |
|runs | | |
| .-<- create -<-. | .->- fork ->-. v |
v |->- check -->-|-- MGR --| |-- VCC <- loads -|
VSM |-<- write --<-' | '-<- wait -<-' | |
TOOLS | | | |
^ | .-------------' | |
| | | |writes |
|reads | |->- fork ----->-. | |
| | |->- cli_req -->-| | |
VSM ----' |-<- cli_resp -<-| v |
| '-<- wait -----<-| VCL.SO |
| | | |
| | | |
|---->----- inherit --->------|--<-- loads -------' |
|---->----- reads ---->------| |
'----<----- writes ----<------|--<-- loads --------------------'
|
|
|
.--->-- http_req --->--. | .-->-- http_req --->--.
(ANON) --| |-- CLD --| |-- (BACKEND)
'---<-- http_resp --<--' '--<-- http_resp --<--'
(ASCII-ART rules!)
在Varnish中进程管理是一个关键角色,”MGR”是进程的管理员”(ADMIN)”,MGR启动在Varnish成为web缓存服务时。
以为我自己的经历来说,我不觉得”在凌晨3点起床重启一个dead进程又酷又重要”,事实上,我认为那是一个带有愚蠢思维的表示:假如我们没有电脑重启进程,那么我们为什么还要这么做?
“管理进程”的任务不是做网站内容缓存的,而是确保”CLD(子程序)”去做缓存内容的事情。
Varnish中现有的主要障碍是:所有的管理工作在一项进程中,所有实际流量操作在另一个中,并且管理进程完全不信任子进程。
子进程完全处于不被保护的区域:网络上任何电脑都可以连接子进程并请求网站缓存信息。
John D. Criminal如果想利用Varnish安全漏洞进行入侵,那他就需要干掉子进程,假如他要进行DoS工具,那么他就需要把子进程打下来。
所以在实际中,管理进程会以非常低权限启动子进程,我们关闭了这些子进程可以访问的所有范围脚本。
存在三种与管理进程后台通信的渠道:一类是退出代码,一类是CLI响应,还有用于统计和记录写入共享内存中的”VSM”文件,上面这三种都是靠”管理进程”来定义的。
在图的左上角,你可以看到Varnish操作分为”ADMIN”和”Operator”角色。
管理员做的操作包括处理事情和修改某些等操作。操作员的做用是确保这些事情就是他们应该做的。
操作员通常是些脚本和数据收集工具,没有任何理由把他们假设成bugfree,所以Varnish不信任操作员这个角色,他们之间是一种纯粹的单向关系。
(小贴士:若子进程以”nobody”用户运行,让可信任人做访问’nobody’用户(例如使用.ssh/authorized_keys2),那么管理进程就会杀死这些子进程,并以相同的参数和设置重启。)
操作是管理员说了算,当然管理员可以决定再何种情况下将这一权力共享。
毫无疑问,如果varnish运行在一个不安全系统上,管理员的控制垄断就会受到危害。
在图中,还有很多障碍,这些障碍与”政治性的”相比,更近乎”技术性”,一般情况下,这些障碍更倾于妥协,与程序的漏洞而言。
例如在VCC编译里面运行一个独立子进程,为了确保内存缺陷和其他缺陷,不在管理进程里面不会堆积更多问题,
希望这个解释能有助理解为什么Varnish相对其他程序来说不是一个独立进程。
Poul-Henning, 2010-06-28