Open Stack

** Changed in: ossn
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1322766

Title:
  Cinder wipe/shred fails open

Status in Cinder:
  New
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  Previously, lvm_type=default signified a volume should be zero'd or
  wiped when deleting the volume. Zeroization could be avoided with
  lvm_type=thin. At
  https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20,
  the following was added:

      volume_clear = none, zero, shred
      volume_clear_size = size_in_MiB

  Looking at the code from the commit, the default behavior of wiping
  was changed, and the change resulted in a "fail open". That is, no
  wipe occurs on configuration errors or typos:

  +        LOG.info(_("Performing secure delete on volume: %s") % volume['id'])
  +
  +        if FLAGS.volume_clear == 'zero':
  +            if size_in_m == 0:
  +                return self._copy_volume('/dev/zero', vol_path, size_in_g)
  +            else:
  +                clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m]
  +        elif FLAGS.volume_clear == 'shred':
  +            clear_cmd = ['shred', '-n3']
  +            if size_in_m:
  +                clear_cmd.append('-s%dMiB' % size_in_m)
  +        else:
  +            LOG.error(_("Error unrecognized volume_clear option: %s"),
  +                      FLAGS.volume_clear)
  +            return

  Perhaps previous behavior should be restored:

      * default = one pass of 0's
      * a valid config changes the behavior
      * an invalid config still uses default behavior

  I think it s important to ensure cinder serves zero'ized block among
  tenants in the common case to ensure no data leaks of sensitive or
  highly sensitive data. Its going to be an important safeguard,
  especially in industries like US Financial and US Federal.

  Operators that don't handle sensitive or highly sensitive data can
  'volume_clear = none'.

  And the unexpected case of a configuration error or typo ensures the
  system fails safe. In fact, specifying 'volume_clear = 1' or
  'volume_clear = true' or 'volume_clear = yes' should trigger the
  unexpected fail open.

  From the low hanging fruit department.... Feel free to release it at
  any time. The "security vulnerability" was checked to ensure the
  security folks had an opportunity to provide feedback.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1322766/+subscriptions