Open Stack

On 11/02/2013 02:56 AM, Jeffrey Walton wrote:
> On Fri, Nov 1, 2013 at 10:06 PM, David Hill <david.hill at ubisoft.com> wrote:
>> Hello Jeff,
>>
>>         I understand that but does that mean it HAS to be done right away?
>> I mean, performances for the rest of the VMs are sacrificed over security concern
>> (which are legitimate) but still have an impact over the remainder of the EBS
>> volumes being attached to other VMs.   There're no better ways that could
>> be implemented to deal with that?  Or maybe some faster ways ?   What
>> if the LVM would be kept for a bit longer and be deleted slowly but surely?
> The folks on openstack-security are probably in a better position to
> comment than me. Shooting from the hip, I think there are a couple of
> ways to handle it.
> 
> The easiest would probably be to encrypt the cinder blocks, and then
> securely wipe the key upon deletion of the VM. That would only take
> one write of 32 bytes, and its surely less than a single disk sector.
> The remaining [encrypted] data should be indistinguishable from random
> because the ciphers possess the Pseudorandom Permutation (PRP) notion
> of security [0]. Here, the ciphers would be (1) AES/CBC (and other
> similar modes) are properly "chained" or (2) AES/CTR (and other modes
> that generate a keystream and use XOR).

That's the main reason for the current volume_clear_size[=0] option.

Also note the volume_clear={none,shred,zero(default)} setting,
which can be used to completely disable volume clearing with 'none'
or be even more paranoid with 'shred' which currently will write
random data to the disk 3 times.

# Size in MiB to wipe at start of old volumes. 0 => all
# (integer value)
#volume_clear_size=0

There was some discussion when implementing this about
whether to wipe, on deletion or creation or async in between.
Synchronously on deletion was chosen as it was the most deterministic.

thanks,
Pádraig.