Image of McAfee Endpoint Encrypted Work Laptop Takes Down ZFS?

[mattlach]

Hey all, First off, this is less of a request for help, and more of a discussion because I am curious, but this seemed to be the best place for it.

I had a rather odd thing happen to me today.

I've been in crunch mode at work, and thus been doing a lot of work from home. I have some applications on my work issued laptop necessary for what I am doing, so it becomes kind of a nuisance, with a lot of work on my home workjstation that has plenty of desktop real estate, and the teeny little laptop on the side.

In a moment of frustration (and in part procrastination) I had a lightbulb moment.

Why don't I image the laptop drive, copy it to my workstation, convert it to a .vdi virtualbox image, and run it from the same machine! It would be so much more efficient, and I would get done so much faster!

The laptop has some sort of full disk encryption by McAfee which pops up a username and password dialog before the windows boot loader starts loading windows 7. I figured this wouldn't be a problem, as it would just allow me to enter the username and password when loading my VM, and it wouldn't be a security concern for IT either, because hey, the image would be just as encrypted as the hardware disk, right?


Attempt 1: (not on FreeNAS)

I grab my handy little Ubuntu bootable USB, boot up my work laptop in Ubuntu, and from there DD an image of the encrypted disk in it's entirety to a USB hard drive dock I have connected to it.

I then reconnect the hard drive dock to my workstation, and proceed to copy the image to my small two disk ZFS on Linux mirror on my workstation. Once copied, I use the vbox manage convertdd application to convert it to a virtualbox compatible .vdi.

This is when all hell breaks loose. About 26GB into the convert process my previously perfect small mirror all of a sudden has a metric ton of read errors, perfectly matched in quantity on both drives in the mirrored set. zpool status recommends I delete the image file and restore from a backup. I dutifully delete the raw dd image and then do a scrub of the disks. No problems detected, 0 repairs. I've since copied multiple gigabytes to and from the mirror with no issues at all.

Odd, I think. A little bit concerned that my setup is starting to act up, I chuck it up to some weird random read or write failure somewhere in the chain, make a mental note to keep an eye on the health of my little local mirror and decide to start over.


Attempt 2: (on FreeNAS)

I reboot the laptop up using my trusty ubuntu USB stick, and this time mount a share on my FreeNAS server (12 disks 2 RAIDz2 vdevs in one pool). Again, I proceed to DD the full encrypted disk, but this time to my FreeNAS server.

First attempt fails after 20 some GB due to some sort of timeout. Weird I think. I reboot the laptop, and try again.

This time the image completes. I go to the share on my workstation, and again, initialize the vdi conversion process. The image in total is about 167GB, but the conversion process stops without error resulting in a 75GB file. I see this and am surprised, but take it as a positive sign. Some sort of magic in the conversion process due to sparse .vdi files, I think, instead of fully populated raw images.

Ready to test how everything will load in virtualbox, I set up my machine, add the converted vdi, and nothing. Not even a boot error. I get a black blank screen in my virtualbox console, that is not responding. A little disappointed, I assume that it is some sort of protective measure to prevent booting in case the wrong people get a hold of the laptop and try to steal data from it.

Disappointed I go to continue my annoying work from home task, switching back and forth between laptop and workstation, when I notice none of my network drives to FreeNAS are responding. Not only that, the FreeNAS server is not responding at all. Not to the web interface,m and not to pings...

My FreeNAS install runs in a virtual environment (yeah, I know, not recommended, but it works due to forwarded HBA's, so I have direct read and write access to the drives) so I sign on to my ESXi server to investigate. I expect to find the FreeNAS guest running, but somehow having network issues, but instead I find it completely off. All the other guests are running, but FreeNAS is powered off.

I go to the logs, there are some cryptic unintelligible messages about a crash (and an offer for paid support from VMWare :p )

To be on the safe side I reboot the entire host, and bring all the guests back up again.

So, what do you guys think? Does McAfee Endpoint Encryption do something crazy to try to foil data thiefs, or is this the biggest coincidence of odd failures when tying to do the same thing on different systems?

Other than this one raw image file from from my work laptop, both my Workstation and my server have been rock stable since they were both built, 4 years and 1 year ago, respectively.

Thoughts?

 

[mattlach]

This may have something to do with it.

 

[gpsguy]

In a nutshell, yes. You can't create a VM from your encrypted hard disk.

Does McAfee Endpoint Encryption do something crazy to try to foil data thiefs ...

I use it at work on all our desktops and laptops. It can be a royal PITA even on a good day.

 

[mattlach]

In a nutshell, yes. You can't create a VM from your encrypted hard disk.

I use it at work on all our desktops and laptops. It can be a royal PITA even on a good day.

Good to know. Thank you. I'm not too concerned with my current application. I only did it to save myself some effort, but I ahve already spent WAY more time on it than it would have taken to just put up with the inconvenience in th efirst place... I could always just screen share it or something if it REALLY bothers me.

My concern is currently as follows though:

Have McAfee discovered a way to intentionally construct a malformed data block in such a way that it can not be stored on RAID (in general) or ZFS (in particular), and takes down the array when attempted?

If they have, and are using it, is it only a matter of time until others figure this out?

What could the implications be? Intentionally malformed data segments coupled with DRM so I can't backup my media, for instance?

Or intentional sabotage of production systems by uploading files containing this malformed data in an attempt to harm them or take them down?

 

[Robert Trevellyan]

Intentionally malformed data segments coupled with DRM so I can't backup my media, for instance?

This has been used as a copy-protection measure since the days when games came on floppy disks.

 

[gpsguy]

I don't think there was any intentional sabotage.

McAfee's Endpoint Encryption is a full disk encryption product. While there are other ways of encrypting data on a system, for example, a special partition or specific files and folders; encrypting the entire hard disk ensures that data at rest is encrypted, no matter where it resides on the device.

My guess, is that your employer wants to protect the information on the laptop. If the laptop is lost or stolen, do they want to make the national news and have regulators, stockholders, customers, clients, etc. yelling at them, because someone lost a device with 100,000+ records of client data, medical records, or .... ? Or, perhaps a competitor might glean some juicy information by reading your email.

If you wanted to move the image to a VM, you should have talked with your IT folks first. If they were agreeable (my organization wouldn't allow it), they might might give you a VM or they could decrypt your laptop, do a P2V migration, and give you a VM.

You can still backup your data, copy files, etc. But, you can't create a VM, without decrypting the drive first.

A few years ago, we replaced the SATA drives in our laptops with SSD's. For some laptops, we just deployed a fresh image and encrypted the new device. For others, we had to decrypt the existing SATA drives, clone it, drop the image on the SSD, and then encrypt it again.

If I have to work on a laptop (or desktop), I'll just do a RDP (or equivalent). I'd much rather type on my IBM Model M keyboard.

 

[cyberjock]

I don't buy the "McAfee did this" idea.

I'm guessing that the reason the FreeNAS VM was powered off is also related to the timeout you mentioned.

Hate to break it to you, but even with the PCI passthrough, it's a very fragile thing. If anything goes wonky it can take down the VM (and some people I've talked to claim it has taken down the entire ESXi host).

So I think it's more likely there is some hardware problem at work and you need to figure out what 'it' is that is going on.