@dyk
2016-04-29T03:09:05.000000Z
字数 8492
阅读 333
ReadingNote
CCS'12
现代的云计算架构都是使用虚拟机监控器（VMM），这些VMM 都有一个大且复杂的有高权限的管理域来监控其它的客户虚拟机的状态。面向管理域的攻击或者对于管理域的错误的使用可以破坏用户虚拟机的安全与隐私。并且传统的VMM限制用户对于自身虚拟机的权限，例如用户只能依赖云系统提供商来部署一些入侵检测系统以及基于自省的安全工具。
文章介绍了一个新型Self-service Cloud Computing模式，SSC模式克服了上文中提到的两个缺点**（1）特权域容易被攻击。(2）用户不能自定义自己的虚拟机。**SSC将管理员的管线分离为一个系统范围的管理域Sdom0和每个用户独有的管理域Udom0。每一个用户对于他自身的虚拟机有最高的权限，因此用户能够自由的组件自己的虚拟机。Sdom0不能获得用户虚拟机的任意信息（代码，数据，计算信息）。因此保护了用户虚拟机的隐私与安全。SSC允许用户和云系统提供者都能设置可信的监控服务。作者通过修改Xen虚拟机监控器实现了SSC，并且通过许多的例子证明了SSC的实用性。
其中提出的SD（service domain）由用户好设定与work VM之间的dependency，然后赋予特殊的功能例如introspect SD，system call monitor SD， checkpoint SD。
不算是小的hypervisor还是没有hypervisor的虚拟机化技术他们都精简的一些功能，而这些功能却是云计算十分需要的功能。
Details
SoCC'14
Self-Service cloud Platform，SSC是最近提出的一个模型，这个模型能够提升公共个云平台用户数据的安全性以及隐私性。它能让用户灵活的部署安全服务，例如用户自己部署自省虚拟机来监控用户的工作虚拟机，并且禁止云操作者监听和修改客户虚拟机。SSC通过修改hypervisor的权限模型来达到以上的需求。
本文主要提出了基于SSC云平台的控制面板的设计，控制面板作为接口存在于在租户与云之间以及云主机之间。文章中介绍了SSC控制面板的新型的特性，例如指定虚拟机之间的依赖关系（A虚拟机能够dumpB虚拟机的内存）， 快速部署网络的middlebox，以及新的VM迁移协议。文章中介绍了SSC控制面板的设计以及实现。
在SSC系统上面，每一个用户的VM必须有一个对应的Udom0，Udom0是所有的特权的来源，他负责管理和保护所有的客户虚拟机的安全。（一个用户对应一个Udom0，一个Udom0对应多个UdomU或者SD）例如,Udom0有I/O后端，能够产生SD，并且保存有用户的SSL私钥。
由于传统的控制面板并没有SSC的抽象概念，因此对待Udom0就和一个普通的用户虚拟机实例是一样的。如果简单的使用这样的软件来创建一个基于SSC的云平台的控制面板，云基础设施提供商将会很容易受到恶意客户机的攻击。这些恶意的客户虚拟机能够使用策略创建多个虚拟机，强迫云将这些虚拟机放到不同的物理节点上面（例如，这些虚拟机要求大量的资源）。
通过这个方式他们能够
然而SSC的控制面板能够处理这样的云特权模型的管理抽象概念。SSC的控制面板能够给客户端一个单独的控制的接口。这些接口就像是服务的前端把控制命令转发给单独的Udom0实例，然而并不会把这些Udom0暴露给用户。同时SSC管理面板让管理VM的放置，迁移以及客户虚拟机之间的通信对用户都是透明的。
由于虚拟机之间的依赖关系，例如虚拟机A作为虚拟机B的网络后端处理网络请求。这样的依赖关系就带来了云系统中的虚拟机的放置的限制。虚拟机A和B必须存在同一个物理节点上面。这样的限制可能会被恶意的用户利用发动probe-respone attack，通过不停的发送GRANT_PRIVILEGE命令要求多个虚拟机。当达到物理机器的上限的时候云管理将会拒绝请求，这样暴露了物理机器的配置（解决方案，事先定义一个Cluster）。
Tags: ReadingNote CloudComputing
SoCC'14
介绍了self-service cloud computing SSC，它能让用户灵活的部署安全服务，例如虚拟机自省工具在他们自己的VM上面，并且禁止云操作者监听和修改客户虚拟机。
SSC通过修改hypervisor的特权模型。
本文主要介绍基于SSC云平台的控制面板的部分，控制面板作为接口存在于在租户与云之间以及云主机之间。
文章中介绍了SSC控制面板的新型的特性，例如快速部署网络的middlebox，以及新的VM迁移协议。
本文的主要的关注点是像Amazon EC2以及Mocrosoft Azure之类的公共云设施。尽管他们表面上十分流行，但是很多企业还是应为安全问题并没有把企业服务迁移到公共云平台上面。
企业担心的原因有两点:
文章提出的解决方案叫做self-service cloud computing，修改hypervisor的权限管理模型。
传统上的hypervisror的是实现给了管理与不加控制的权限自由。相比之下SSC的hypervisor通过权限隔离来提供两种管理虚拟机:
这个策略组织了云管理员窃听用户虚拟机以及修改用户状态，并且允许用户灵活的控制他们的虚拟机。
对于云租户本文的主要贡献在于：
SSC的控制面板实现了一个成熟的云基础框架.
在SSC中云提供者认为是Amazon，微软等，他们被认为是可信的。并且硬件都是装备TPM的，而且有IOMMU单元来提供I/O虚拟化。
SSC的TCB包括...
云操作员在文章的威胁模型中是不可信的。另外我们所有的来源与dom0的信息（不管是dom0发起的或者是经过dom0传输的）都是不可信的。SSC保护用户的虚拟机来抵御来自不可信的dom0的攻击。
SSC的组件
特权的分离将原有的dom0分离成为两个全新的域：
尽管hypervisor允许Sdom0挂起和运行客户虚拟机，读取他们的只读状态（vCPU的数量或者RAM的分配），管理他们的虚拟I/O操作。
但是hypervisor并不允许Sdom0对任意客户虚拟机内存以及vCPU寄存器的映射。
在物理平台上面的用户虚拟机称为UdomU，每一个用户的Udom0相对于他的所有UdomU来说有管理员的权限。
Udom0能够映射Udom0的内存，能够在Udom0里面实验内存的检测工具。Udom0也能运行I/O后端，截取UdomU的I/O数据，能够实现入侵检测。
尽管Udom0能实现以上提及的特权任务，但是SSC的设计要求保持Udom0无状态。因此SSC也支持service domains，SD能够实现客户虚拟机上面的管理任务。Udom0能够创建一个SD并且分配好相应的权限完成类似与对UdomU的入侵检测之类的任务。
最后的SSC组件是全平台区域的domain builder（domB），DomB相应用户虚拟机的请求，帮助建立虚拟机将虚拟内存以及CPU寄存器映射到物理内存上面。并且这样的工作不能由Sdom0做，DomB是TCB的一个部分，DomB同时也能与TPM进行交互，以及运行vTPM的代码。
一个用户的创建虚拟机实例的过程从创建Udom0实例的请求开始。Udom0能够由现有的OS发行版创建。
传统云环境的控制面板的作用在于监控资源的使用，动态的迁移虚拟机来达到负载平衡，部署用户选择的云基础设备提供的服务（例如入侵检测系统）。
SSC的功能
SSC的SD概念能够对于某些UdomU有被指定的权限（dump内存的权限，映射寄存器的权限），同样的UdomU也依赖SD来获得某些服务。控制面板必须允许用户来制定这样的一些依赖关系。而这些依赖关系将影响这些虚拟机的安置位置（例如一个SD映射了UdomU的内存，那么他们必须在同一个物理机器上面）。
传统的控制面板一样也支持middlebox，但是不同的是传统上面的middlebox是由云基础服务提供商提供的，但是用户自己定义的middlebox和特权的SD是SSC的概念。
在SSC系统上面，每一个用户的VM必须有一个对应的Udom0，Udom0是所有的特权的来源，他负责管理和保护所有的客户虚拟机的安全。（一个用户对应一个Udom0，一个Udom0对应多个UdomU或者SD）例如,Udom0有I/O后端，能够产生SD，并且保存有用户的SSL私钥。
由于传统的控制面板并没有SSC的抽象概念，因此对待Udom0就和一个普通的用户虚拟机实例是一样的。
如果简单的使用这样的软件来创建一个基于SSC的云平台的控制面板，云基础设施提供商将会很容易受到恶意客户机的攻击。
这些恶意的客户虚拟机能够使用策略创建多个虚拟机，强迫云将这些虚拟机放到不同的物理节点上面（例如，这些虚拟机要求大量的资源）。
通过这个方式他们能够
然而SSC的控制面板能够处理这样的云特权模型的管理抽象概念。SSC的控制面板能够给客户端一个单独的控制的接口。
这些接口就像是服务的前端把控制命令转发给单独的Udom0实例，然而并不会把这些Udom0暴露给用户。同时SSSC管理面板让管理VM的放置，迁移以及客户虚拟机之间的通信对用户都是透明的。
传统上面控制面板有3个关键的组件
SSC的控制面板在功能上面是上面3个组件的加强，并且引入了新的组件交互的协议。SSC的控制面板还引入了新的以用户为中心的特性，例如用户能够在VM之间指定依赖关系，并且放置middlebox。
云控制器，SSC允许租户自己定义虚拟机之间的依赖关系（例如，虚拟机A能截获虚拟机B的I/O流），这样的依赖关系可能要求两个虚拟机必须在同样的物理节点上面。云控制器也允许租户自己定义虚拟机的I/O流（例如，必须经过某个虚拟机，就像作为驱动后端的SD必须处理UdomU的输入输出流）。 节点控制器，一个节点控制器就像一个平台的Sdom0一样的一个守护进程，节点控制器能够节点资源的使用，以及使用的虚拟机的调度，但是并不能创建用户虚拟机，也不能读取或者修改用户的虚拟机。 Dashboard,在SSC，dashboard服务是建立租户与云之间的一个接口，dashboard有两个责任： dashboard前端是给用户的一个界面，通过它租户能够启动一个虚拟机镜像，定义虚拟机之间的依赖关系。dashboard将要把这些用户的请求传递给云管理器。
但是虚拟机镜像的信息不会被传送给云管理器，dashboard直接将镜像传送到目的的节点通过SSLchannel。
dashboard后端调节所有的云平台组件的通信作为 租户的代理。后端接受云控制器产生的虚拟机调度决定，将虚拟机镜像调度到目的节点。
由于dashboard处理敏感的数据（客户虚拟机的镜像），dashboard是TCB的一部分，我们将dashboard实现为一个在SSC hypervisor上面运行的一个虚拟机。我们假设云服务提供商将为dashboard提供多个物理的主机，每一个新的用户将会得到一个在SSC作为Udom0运行的dashboard虚拟机实例。
租户通过请求dashboard虚拟机实例来开启与SSC平台的交互。在虚拟机的创建时间里，租户通过SSL与虚拟机进行交互，给dashboard提供虚拟机镜像，之后dashboard帮助租户在物理的节点上面启动这个镜像。
Dashboard的创建以及操作
租户能够通过下图创建一个dashboard虚拟机实例。
引用的[10-14,23]提出几种针对特权域的攻击。学术界也渐渐开始支持将特权域分离。
[9,33,47]都采用了将特权域的toolstack分离的策略。
[50,51]也提倡提供给用户更加灵活的权限控制，虽然能够做到提供给用户较为灵活的权限，但是并没有保护好用户的隐私。
作者下一步准备将驱动分解[28]，以及将XenStore融入用户域[9]。扩展SD的功能
相关工作将要介绍一个hypervisor-free的设计，由于SSC的设计将hypervisor放入了TCB所以需要一个轻量级的CFI的保护技术。
全部都是基于目前的商用虚拟化层软件太复杂而发展的研究。
CCS'11
考虑到虚拟化软件是一个十分复杂的并且有很多的attack surface，所以透过有漏洞的hypervisor攻击用户虚拟机并不是难事，这个是客户将服务迁移到云上面的一大阻力。基于先前关于hardening或者minimizing虚拟层的研究，作者通过让多个用户虚拟机都能并行的跑在物理的机器上面的技术消除了hypervisor层面的攻击。
S&P'10
商用虚拟化软件过于庞大的复杂，而且最近针对hypervisor层面的攻击也很多（eg., VM escape）。
作者提出了一个轻量级的保护手段能够让Type-I行的虚拟机提供自我保护的能力在提供整个生命周期的CFI。
作者首先设计了non-bypassable memory lockdown，能在有buffer overflow漏洞利用的情况下一样能够保护hypervisor的代码和静态数据。保护了hypervisor的代码完整性。其次，restricted pointrer indexing。介绍了一个间接将控制数据转化为指针索引的layer。由于指针的索引是被限制的，所以对应的调用与返回都会严格的依照hypervisor的控制流图。由此保护了控制流的完整性。
Shakeel Butt
H. Andrés Lagar-Cavilla
Abhinav Srivastava
Vinod Ganapathy
SoCC'15
来自云的各种的虚拟机设备（virtual appliances）被吹捧为各种软件为何，移动，向后兼容，安全挑战的强有力的解决方案。在文章中作者探索创建一个虚拟机设备的云来移动网络的流动的相互交流的用户经验。作者希望能够支持一个内容的可执行的类YouTube的流服务，例如游戏，交互式阅读，研究工件等等。用户能够很快的通过这些可执行的内容（executable content）快速的post，和browse而且没有产生很大的中断。只管上面该决这样的是不可能的。作者展示了vTube。
第一篇第二篇文章都是防御恶意的云操作者，以及不安全的特权域，将特权域的特权划分，将其中的一部分划分给了用户，用户对他他们自己的虚拟机有了更加大的权利。
如果添加了回滚策略会发生什么事呢？回滚又谁来控制呢？SD是绝对安全吗？