PaaSSandbox实现原理分析.pptVIP

PaaS Sandbox 实现原理分析 一、 云计算很火，各种云的实现方式也分为很多个流派。但是无论怎么变，基本类型是有的，主要分为SaaS,PaaS,IaaS。而平时大家接触较多的PaaS（也就是GAE，SAE等类似在线开发平台），是一般开发人员、安全人员第一能接触到的。而大家也对于其支持各种语言sandbox实现方式却并不了解，只是模糊的知道，需要修改语言源代码来做限制。至于怎么去限制，是不是只修改这些就够了，大家都不太清楚。所以无论是做沙盒突破，还是在PaaS上编写自己的程序，经常因为一些莫名其妙的限制而绕了大半钟头却不知所以然。于是本文的目的就是为了将这些看起来比较神秘的内容根据笔者的经验给大家做个介绍，权当科普。 本文介绍的所有PaaS环境搭建在Linux或者类似系统上。Win平台暂不涉及（也没见过用win搭建PaaS的吧？） 二、 首先需要明确，对于一个PaaS，什么是需要做限制的。这一点我在之前的《AppEngine安全测试思路》中做过介绍。云平台既然卖的就是资源，因此对于资源使用率和使用方式是非常敏感的。任何计算、存储、网络资源都是一个好的Sandbox需要关注的。除此之外，作为云平台，有很多不同程序的代码托管在之上。因此sandbox也许要保证这些托管代码不会对平台自身、以及其他不同的代码造成危害。因此总结下来sandbox就有两个任务： 1、资源限制 2、边界控制（或者叫安全控制，whatever） 明白了这一点，我们再来看看这两者需要如何实现。 PaaS搭建的是一个包含操作系统、网络环境、Webserver、CGI脚本解析器的整体环境，其结构大致如下： [CGI语言]-[Webserver]-[POSIX 环境]-[系统内核]-[网络]-[其他资源（数据库等）] 可以看到，这基本是一层套一层的。因此其实在任何一层做好资源控制都可（到系统内核这一层为止。后续的两个只能控制自身有关的资源），但是大多数情况下多数PaaS的sandbox限制是做在CGI脚本语言这一层的。原因有二，一个是目标明确，如果你在其他底层做限制，可能会误伤到其他进程，牵扯太广。另一个是在语言层面实现的细粒度更全，出现疏漏，定位容易也更安全。毕竟是和用户交互的第一层。 但是如果将sandbox做在这一层，为了做资源限制，很多时候会改变CGI语言原本的api。例如用php可能需要disable一些function，用python可能取消去掉某些使用多线程的模块（实际上还是很多的）。这些会大大影响一些用户的使用习惯，某些开源程序也因此无法使用。 所以也有不少云提供商使用另一种sandbox模型。将大部分控制都做在POSIX环境以及系统内核这一层上。目前主要是国外的一些云厂商是这么做的，例如appfog，zend云等（都架构在亚马逊的IaaS上）。做在这一层的特点是学习成本少，不需要改用户习惯。但是坏处也很明显：因为将安全控制退居二线到操作系统层，因此他的每个app的边界也就扩大了，经常只能一个虚拟机只能跑一个app，否则就可能互相影响。因此这带来的成本就会很大（一个app一个虚拟机，或许还会更多） 在第二种模型下，我更觉得像是IaaS而不是PaaS。因此本文既然探讨PaaS的沙盒实现，则重点主要讨论第一种实现方式。也是国内目前众多云厂商所采用的方式。 三、 既然知道是修改CGI脚本语言这一层做的实现，那么，又是如何实现的呢？ 这个基本就是要拼你对语言本身的理解和熟悉程度了。有的语言本身就考虑到了类似场景，例如php的disable_function和safe_mode，例如Java的securityManager，例如bash的-r等等。有的语言则需要你亲自动手去阉割一些内容。例如python。当然，合理并用应用两者才是比较好的实现方式。 这些语言实现看起来繁多，其实还是有一定脉络可寻的。一般的脚本语言源代码，通常分为三大部分：? 一个是语言本体的语法解析，内存结构 一个是语言自身内部底层api 另一个则是语言自身携带的编程标准库。 拿php源码做例子，zend目录下主要都是语言结构等部分，main目录下是一些内部api，而ext目录下则是PHP自带标准库的内容；Python源代码中，Grammar、Parser和Objects分别是语法解析和内存结构，Python目录下是内部api，Modules和Lib分别是C和Py写的标准库。 而通常情况下所有和资源相关的操作，都不可能存在于语言结构和语法解析部分。而集中于标准库的内容中。而标准库通常在底层又集中调用语言内部api。所以通常来说，只需要修改内部api，就可以达到控制资源访问的目的。 不过由于开源软件可能有些不太规范，标准库还是可能自行去读写文件、操作资源的。而如果你的资源比较特定