[colug-432] Red Hat in May

[R P Herrold]

On Fri, 19 Apr 2013, Jim Wildman wrote:

> It speaks to the hypervisors (VMWare, RHEV and Hyper-V (rudimentally))
> via the hypervisor's API.  This includes the ability to read the
> filesystems of powered off VM's (assuming they have not been encrypted).
> <insert Russ's security comments here>

That 'aside' may have been a bit cryptic to some.  Jim Prior, 
Rick Troth and others in COLUG have seen the 'pmman' 
virtualization control interface in action in various aspects.

Over the last few years, I've migrated my development efforts 
in to short lived VM's (longer lived as needed for production 
purposes).  Lots of benefits for developers to this -- ease of 
deployment, ease of 'snapshotting' backups (hot and 
quiescent), ease of replicating a mis-behaving reproducer 
instance and handing it off to a (potentially remote) 
co-developer to 'run down the fault', ease of doing diagnostic 
partitioning to find a fault

I've sold the service of the system to a major chip 
manufacturer's developers to build custom 'small machine' 
embedded distribution; to a US military's contractor's 
developers to build appliances for milspec environments; to a 
major FOSS distribution's main build-slaves; for development 
in 'z' space of a full line private label distribution, and so 
forth

But back to the 'powered off' / 'scratched' VM privacy 
issue

In poking around threat vectors, backup copies, and discarded 
VM images use LVM snapshotting in part of the process of their 
generation.  It became clear that subsequent images might be 
assigned space in a new LVM that had information from a prior 
usage of that drive space that might be readable with the 
prior data still present, outside of conventional filesystem 
reading techniques -- functionally, DD'ing the device and then 
running 'strings' on the copied image, looking for interesting 
leftover data

A couple years ago, I had spoken with Ted T'so and then Rich 
Jones (libguestfs developer) about the need to 'wipe' space 
down, and an option, but not a mandatory default due to 
performance reasons, now exists to 'zero' previously 
un-written to space, as to file-system provided access.  But 
the 'out of band' data access problem persisted

I had provided a 'review copy' of our design approach to 
'wiping down' old LVM space to Jim W earlier this week for 
review -- see:
 	man shred
which will work just fine on raw LVM COW images, and he had 
been kind enough to look it over with a critical eye

Thanks, Jim

-- Russ herrold