Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

XPDS13: SecureServe - A Multi-level Secure Server Virtualization Platform on Xen - Jason Sonnek, Adventium Labs

2,266 views

Published on

Due to the rapid shift toward cloud computing, virtual desktop infrastructure (VDI) and thin client computing, many organizations in the government desire a high assurance, multi-level secure server virtualization platform that is low-cost, open and enterprise ready. In this presentation, Jason Sonnek will present SecureServe, a recently launched effort to develop such a platform by building on the open-source Citrix XenServer. The SecureServe project will draw upon research in a number of areas, including dom0 disaggregation, Xen Security Modules mandatory access controls and static/dynamic attestation. In this presentation, Jason will describe the project objectives and requirements, the project's relation to Citrix XenClient XT and XenServer Windsor, current development status and plans for moving forward.

Published in: Technology
  • Be the first to comment

XPDS13: SecureServe - A Multi-level Secure Server Virtualization Platform on Xen - Jason Sonnek, Adventium Labs

  1. 1. Secure  Server  Project   Xen  Project  Developer  Summit  2013   Adven9um  Labs   Jason  Sonnek   10/16/13   ©  Adven9um  Labs  2013   1  
  2. 2. Outline   I.  Mo9va9on,  Objec9ves   II.  Threat  Landscape   III.  Design   IV.  Status   V.  Roadmap   10/16/13   ©  Adven9um  Labs  2013   2  
  3. 3. Mo9va9on   •  In  a  nutshell:  “Secure  Server  Mul9plexing”   –  In  a  cloud  environment   –  Mul9ple  tenants   •  Goals:   –  Ensure  data  and  processing  are  safe  from  co-­‐tenants   –  Ensure  controls  on  informa9on  separa9on  and  flow  are  sa9sfied   •  Today:   –  Xen  hypervisor,  hardware-­‐assisted  virtualiza9on  provide  tools  necessary  to   isolate  hardware   –  Problem:  many  shared  components  in  dom0,  insufficient  isola9on   –  The  easy  way  out:   •  Dedicated  hardware  for  each  tenant   •  Imprac9cal  when  there  are  a  large  number  of  tenants,  rela9onships  are  evolving   10/16/13   ©  Adven9um  Labs  2013   3  
  4. 4. Objec9ve   Cloud   Management   Green   Orange   SecureServe   Xen   •  SecureServe  ideal   –  –  –  –  –  10/16/13   Enables  mul9ple  tenants  to  share  a  single  pla[orm  securely   High-­‐assurance,  isolated  so]ware  par99ons   Enables  controlled  informa9on  sharing  between  tenants   Supports  enterprise-­‐ready  management   Low  cost   ©  Adven9um  Labs  2013   4  
  5. 5. Current  State   Green   QEMU   xapi   XenStore   Orange   dom0   netback   blktap   nic   disk   Xen   •  Weakest  guest  is  the  weakest  link  in  the  system   –  Guest  aaack  vector:  many  shared  components  in  dom0   •  Device  emula9on,  virtual  devices,  toolstack,  XenStore   •  Cross-­‐VM  side  channel  aaacks   •  Cloud  management  provides  an  addi9onal  aaack  vector   –  Users  must  be  able  to  manage  and  configure  their  VMs.   –  XAPI:     •  Complex  (130K  LOC)   •  Interfaces  with  many  other  components.   10/16/13   ©  Adven9um  Labs  2013   5  
  6. 6. Current  State   Green   QEMU   xapi   Orange   Compliance   XenStore   dom0   netback   blktap   nic   disk   Xen   •  Desire  controlled  informa9on  sharing  between  tenants   •  Inter-­‐VM  networking   –  Can  define  “separate”  networks  in  dom0   –  Separa9on  in  dom0  is  weaker  than  separa9on  provided  by  hypervisor   •  Goal:  enable  high-­‐assurance  private  networks   10/16/13   ©  Adven9um  Labs  2013   6  
  7. 7. Threat  Landscape   •  Recent  (2012-­‐13)  Xen-­‐tagged  CVE  vulnerabili9es  (tag  cloud  below)   •  73  vulnerabili9es  represented,  some  with  mul9ple  poten9al  effects   –  –  –  –  –  –  65  "guest",    e.g.  "allows  local  guest  administrators  to"     8  TMEM  (transcendental  memory)   4  "overflow"     4  QEMU     3  "drivers"  (all  in  reference  to  backends)     2  xenstore     10/16/13   ©  Adven9um  Labs  2013   7  
  8. 8. Threat  Landscape   •  Aaackers  target  toolstack,  hypervisor,  management  so]ware,  …   with  varying  goals:   –  Denial  of  Service   –  Escala9on  of  Privilege   –  Acquisi9on  of  Informa9on   •  Vulnerability  types  on  the  radar:     –  –  –  –  –  –  –  API  -­‐-­‐  arguments  not  adequately  sanity  checked   Aspects  of  Intel/AMD  instruc9on  set  that  emulator  handles  incorrectly   Failure  to  completely  and  correctly  check  permissions     Weakness  in  recovering  from  error  condi9ons     Exploitable  PCI  pass-­‐through  devices,  especially  bus  mastering  capable  ones     Logic  errors  that  can  be  triggered  by  unusual  condi9ons     Memory  leaks  or  similar  unbounded  resource  sinks     10/16/13   ©  Adven9um  Labs  2013   8  
  9. 9. Near-­‐Term  Project  Objec9ves   •  Improve  security  posture  of  dom0   –  –  –  –  Isolate  the  network  stack   Isolate  the  storage  stack   Isolate  the  device  model  (QEMU)   Adapt  the  toolstack  as  necessary  to  support  this  configura9on   •  Apply  well-­‐known  security  principles   –  Secure  the  weak  links,  separate  privileges,  do  not  share  mechanisms   (disaggrega9on)   –  Grant  (and  enforce)  least  privilege  (hypervisor  MAC)   –  Defense-­‐in-­‐depth  (aaesta9on)   •  Establish  a  baseline  for  future  research  and  development   10/16/13   ©  Adven9um  Labs  2013   9  
  10. 10. Requirements   •  Defined  a  set  of  high-­‐level  requirements  based  on  NIST  800.53  and   CNSSI  1253:   –  Categories:  Confiden9ality,  Integrity,  Access  Control,  Accountability,  Usability   •  Examples:   –  Informa7on  in  Shared  Resources:  The  system  must  prevent  unauthorized  and   unintended  informa9on  transfers  via  shared  objects..     –  MAC  Policies:  The  system  must  use  mandatory  access  control  policies  to   control  the  flow  of  informa9on  among  processing  domains.   –  SoAware,  Firmware,  and  Hardware  Integrity:  The  system  should  support   integrity  verifica9on  tools  to  detect  unauthorized  changes  to  selected   so]ware,  firmware  and  hardware.     10/16/13   ©  Adven9um  Labs  2013   10  
  11. 11. Dom0  Disaggrega9on   nic   disk   xapi   QEMU   netbk   blktap   nic   XenStore   Storage   QEMU QEMU   Network   Storage   blktap   QEMU Network   netbk       Orange       Green   disk   dom0   Xen   Secure  weak  links,  separate  mechanisms  /  privileges   10/16/13   ©  Adven9um  Labs  2013   11  
  12. 12. Hypervisor  Mandatory  Access  Controls   nic   disk   xapi   XSM   QEMU   netbk   blktap   nic   XenStore   Storage   QEMU QEMU   Network   Storage   blktap   QEMU Network   netbk       Orange       Green   disk   dom0   Xen   Grant  and  enforce  least  privilege   10/16/13   ©  Adven9um  Labs  2013   12  
  13. 13. Isn’t  that  overkill?   Green   QEMU   xapi   Orange   dom0   XenStore   netback   blktap   nic   disk   Xen   Proposal:  Encrypt  orange  and  green  traffic       10/16/13   ©  Adven9um  Labs  2013   13  
  14. 14. Isn’t  that  overkill?   Green   QEMU   xapi   Orange   dom0   XenStore   netback   blktap   nic   disk   Xen   Compromise  of  dom0  via  malicious  tenant  provides   unfePered  access  to  memory!       10/16/13   ©  Adven9um  Labs  2013   14  
  15. 15. Isola9ng  the  Weak(est)  Links   nic   disk   xapi   XSM   QEMU   netbk   blktap   nic   XenStore   Storage   QEMU QEMU   Network   Storage   blktap   QEMU Network   netbk       Orange       Green   disk   dom0   Xen   If  one  tenant  on  Secure  Server  is  compromised  ...   10/16/13   ©  Adven9um  Labs  2013   15  
  16. 16. Isola9ng  the  Weak(est)  Links   nic   disk   xapi   XSM   QEMU   netbk   blktap   nic   XenStore   Storage   QEMU QEMU   Network   Storage   blktap   QEMU Network   netbk       Orange       Green   disk   dom0   Xen   …  the  aPack  is  contained  because  the  compromised  tenant   lacks  privileges  necessary  to  access  co-­‐tenant  resources.   10/16/13   ©  Adven9um  Labs  2013   16  
  17. 17. Isola9ng  the  Weak(est)  Links   nic   disk   xapi   XSM   QEMU   netbk   blktap   nic   XenStore   Storage   QEMU QEMU   Network   Storage   blktap   QEMU Network   netbk       Orange       Green   disk   dom0   Xen   Provides  stronger  data  confiden7ality  assurance  as  well   10/16/13   ©  Adven9um  Labs  2013   17  
  18. 18. Dynamic  Mandatory  Access  Controls   Purple   Green   QEMU   xapi   XenStore   Orange   dom0   netback   blktap   nic   disk   Xen   •  Can  easily  define  a  sta9c  policy  for  mul9-­‐tenant  environments   •  Not  good  enough   –  Tenants  come  and  go   –  Rela9onships  evolve   •  How  can  we  support  a  dynamic  XSM  policy?   10/16/13   ©  Adven9um  Labs  2013   18  
  19. 19. TCB:  Trust,  but  verify   •  Un9l  now,  assumed  a  trusted  compu9ng  base  that  includes  Xen   and  the  hardware   •  Don’t  really  intend  to  trust  these  things:   –  Use  measured  launch  to  check  integrity   –  Use  dynamic  aaesta9on  to  verify  run9me  integrity   •  Especially  important  on  servers   10/16/13   ©  Adven9um  Labs  2013   19  
  20. 20. Knowledge   (trust)   Knowledge   (trust)   SRTM,  DRTM  and  Dynamic  Aaesta9on   Core   Root   Trust   Sta9c  Root  of  Trust   Entropy  leads  to  decay  of   • Hardware?   knowledge  of  system  state:  • Firmware?     • Configura9on?   • Drivers?   9me   Core   Root   Trust   Gap   Dynamic   Launch   Entry   Dynamically   Launched   Measured   Environment   (e.g.,  tboot)   Dynamic  Root  of  Trust   9me   AAer  ini7al  boot,  knowledge  of  system   state  decays  with  7me   10/16/13   ©  Adven9um  Labs  2013   20  
  21. 21. Current  Status   •  Started  with  XenServer  6.2  appliance   –  Built  network  driver  domain  (working)   •  openvswitch  or  bridged  networking   –  Built  storage  driver  domain  (working)     •  iSCSI  and  SATA  controller  backend   –  Developing  QEMU  stub  domain   –  Defined  MAC  policy  for  a  specific  use  case;  verified,  validated   •  Built  tools  for  genera9ng  sta9c  policies  based  on  high-­‐level  specifica9on   •  Challenges   –  Deducing  rela9onship  between  XAPI  and  Xen  constructs   –  Adap9ng  toolstack  to  support  disaggregated  opera9on   10/16/13   ©  Adven9um  Labs  2013   21  
  22. 22. Roadmap   •  Secure  inter-­‐VMcommunica9on   –  Survey:  more  than  a  dozen  published  mechanisms   •  More  fine-­‐grained  disaggrega9on   –  XenAPI,  XenStore,  domain  builder   –  Informed  by  prior  work:  Windsor,  Xoar,  Murray  et  al.,  Qubes,  …   •  Service  VM  model   –  Reduce  footprint,  maintain  generality   •  Assess  scalability   –  Per  tenant  sharing   •  Iden9fy  future  R&D  challenges   –  Migra9on   –  Server  longevity   –  High  availability  configura9ons   10/16/13   ©  Adven9um  Labs  2013   22  
  23. 23. Conclusion   •  Secure  Server  Mul9plexing   –  Ensure  data  and  processing  are  safe  from  co-­‐tenants   –  Ensure  controls  on  informa9on  separa9on  and  flow  are  sa9sfied   •  Building  a  baseline  prototype     –  By  drawing  on  past  dom0  disaggrega9on,  MAC  and  aaesta9on  R&D   –  Targe9ng  EOY  2013  release   •  Prototype  can  be  used  as  a  founda9on  for  future  R&D   –  Phase  2:  iden9fy  outstanding  challenges  and  long-­‐term  R&D  roadmap   •  Call  for  Par9cipa9on   –  Collabora9ng  via  xs-­‐devel  mailing  list   –  Feedback  welcome   10/16/13   ©  Adven9um  Labs  2013   23  

×