Jump to: navigation, search

Difference between revisions of "Bare-metal-trust"

(How this work)
(How to pass OAT-Server URL)
Line 44: Line 44:
 
This can be done via boot instance with user-data, here is a sample about the user-data:
 
This can be done via boot instance with user-data, here is a sample about the user-data:
  
#!/bin/bash -v
+
  #!/bin/bash -v
modprobe tpm_tis
+
  modprobe tpm_tis
modprobe tpm
+
  modprobe tpm
 +
  #OAT-Sever's info
 +
  OAT_SERVER_IP=10.239.48.127
 +
  OAT_SERVER_USER=admin
 +
  OAT_SERVER_PASSWD=p2
  
DEV=eth1
+
  #Node's IP
dhclient $DEV
+
  DEV=eth1
OAT_SERVER_IP=10.239.48.127
+
  dhclient $DEV
OAT_SERVER_USER=admin
+
  OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)
OAT_SERVER_PASSWD=p2
+
  OAT_CLIENT_HOST=$OAT_CLIENT_IP
  
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)
+
  #Node's info
OAT_CLIENT_HOST=$OAT_CLIENT_IP
+
  bios=NewMLE1
 +
  bios_ver=v123
 +
  oem_manu=OEM1
 +
  vmm=NewMLE2
 +
  vmm_ver=v123
 +
  os=OS1
 +
  os_ver=v1
  
bios=NewMLE1
+
  #Init OAT-Client
bios_ver=v123
+
  iptables -A INPUT -p tcp --dport 8181 -j ACCEPT
oem_manu=OEM1
+
  iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
vmm=NewMLE2
+
  iptables -A INPUT -p tcp --dport 9999 -j ACCEPT
vmm_ver=v123
+
  iptables -A INPUT -p tcp --dport 9998 -j ACCEPT
os=OS1
+
  /usr/bin/tagent setup <<EOF
os_ver=v1
+
  $OAT_SERVER_IP \
 +
 +
  $OAT_SERVER_USER
 +
  $OAT_SERVER_PASSWD
 +
  EOF
  
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT
+
  #register a new host
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
+
  oat_cert -h $OAT_SERVER_IP
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT
+
  oat_host -a -h $OAT_SERVER_IP "
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT
+
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"
/usr/bin/tagent setup <<EOF
 
$OAT_SERVER_IP
 
 
 
$OAT_SERVER_USER
 
$OAT_SERVER_PASSWD
 
EOF
 
 
 
#register a new host
 
oat_cert -h $OAT_SERVER_IP
 
oat_host -a -h $OAT_SERVER_IP "{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"
 
  
 
==Limitations and Future Work==
 
==Limitations and Future Work==

Revision as of 10:55, 3 August 2015

Problem description

While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead incurred by virtualization. But how can the cloud provider determine that a user released BM node is free of malware, after all a BM user has full access to the machine and could have introduced rootkits and other malware.

Proposed solution

Our solution essentially mimics how one may download software and compute its SHA-256 hash and compare against its advertised SHA-256 hash to determine its legitimacy. It involves using Intel TXT, which is composed of hardware, software, and firmware. The hardware, attached to the platform, called the Trusted Platform Module (TPM)[5], provides the hardware root of trust. Firmware on the TPM is used to compute secure hashes and save the secure hashes to a set of registers called Platform Configuration Registers (PCRs), with different registers containing different measurements. Other components are Intel virtualization technology, signed code modules, and a trusted boot loader called TBOOT[1]. Essentially the BIOS, option ROM, and kernel/Ramdisk are all measured in the various PCRs. From a bare metal trust standpoint, we are interested in PCRs 0-7(BIOS, option ROM). The kernel/Ramdisk measurements would depend on the image the tenant seeks to launch on their bare metal instance. PCR value testing is provided by an Open Attestation service, OAT[2]. Additional details in references.

We integrate Ironic with Intel TXT to enable detection on boot of any changes in the BIOS, PCIe device firmware, and/or kernel/Ramdisk from expected values. The bare metal is trusted only when there is an exact match. On a legitimate update, for example BIOS firmware upgrade, it is necessary to update the whitelist to include the new expected measurements. For increased cloud security, it is good practice to maintain the whitelist, clearing out old values after all machines are upgraded/updated.

Result:

An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying the trust status of a bare metal node on boot. An administrator on introducing new hardware into the cloud can confirm whether they need to update the whitelist if on boot the machine fails attestation. This could happen for one of many reasons, such as new hardware distinct from existing machines in the data center/enterprise, BIOS upgrade, new PCIe device attachments etc.

Work flow

Note BIOS re-flash and automatic enable TXT will not be available soon.

1. Manual work to prepare trusted boot

           (enable TXT, VT-x, VT-d, take ownership of the TPM)

2. Enable trusted boot for Ironic

           http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image

3. Deploy a trusted boot node

           (Boot a customized image with OAT-Client using trusted boot)
           (Passing the OAT server URL for attestation)

4. Attestation

           (Polls the result from the OAT-Server)
           If trusted:
           Nodes are available and Jump to 5

5. Deploying

           Boot guest image using trusted boot

6. Tenant releases node

7. Jump to 3

How to pass OAT-Server URL

This can be done via boot instance with user-data, here is a sample about the user-data:

 #!/bin/bash -v
 modprobe tpm_tis
 modprobe tpm
 #OAT-Sever's info
 OAT_SERVER_IP=10.239.48.127
 OAT_SERVER_USER=admin
 OAT_SERVER_PASSWD=p2
 #Node's IP
 DEV=eth1
 dhclient $DEV
 OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)
 OAT_CLIENT_HOST=$OAT_CLIENT_IP
 #Node's info
 bios=NewMLE1
 bios_ver=v123
 oem_manu=OEM1
 vmm=NewMLE2
 vmm_ver=v123
 os=OS1
 os_ver=v1
 #Init OAT-Client
 iptables -A INPUT -p tcp --dport 8181 -j ACCEPT
 iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
 iptables -A INPUT -p tcp --dport 9999 -j ACCEPT
 iptables -A INPUT -p tcp --dport 9998 -j ACCEPT
 /usr/bin/tagent setup <<EOF
 $OAT_SERVER_IP \

 $OAT_SERVER_USER
 $OAT_SERVER_PASSWD
 EOF
 #register a new host
 oat_cert -h $OAT_SERVER_IP
 oat_host -a -h $OAT_SERVER_IP "
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"

Limitations and Future Work

1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is necessary to obtain fresh measurements and re-attestation.

2) On detecting that a bare metal instance does not meet trust measurements, we shall log it. In the future, we shall introduce a Ceilometer alert event to be consumed by the cloud administrator, perhaps needing follow-up with the prior tenant. Additionally there is a cleaning step that will address reflashing BIOS and Option ROMS. Until reflashed, the untrusted bare metal node will not be allocated to any tenant.

3) Blue Pill When the hardware virtualization support is enabled without a hypervisor running, the machine is open to launch a Blue Pill style attack. Unfortunately OEM vendors do not provide the capability to disable Intel TXT or its equivalents and those that tried to support the same insisted on establishing physical presence. The reasoning here is the dynamic control feature itself could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect because we are concerned strictly with establishing that a machine prior to hand-off to a tenant is clean, free of rootkits and malware. Should the tenant seek to install a rootkit, that is in their purview. Once the machine is released back to the cloud, our workflow will detect and erase the same.

This said, no claims of trust or re-attestation of a bare metal machine are possible post boot time. In the Horizon dashboard re-attest action will not be provided. Node boot time and trust status at boot time will be displayed.