[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] Xenserver/XCP encrypted disk



The second solution is not a hack.

Whole xen development community is moving from single dom0 to multiple service domains, each performing single set of tasks (storage domain, supplemental domain for HVM and so on).

If you want to load dom0 with encryption too, let me ask: how you want to manage CPU time for that? One domain may perform lot of IO and other want more CPU. If you put encryption to dom0 you can not give most of CPU to 'cpu-hungry' task, because you should never limit dom0 in cpu usage. If encryption is happens within specialized domU, you can limit it CPU usage (while limiting IO to it SR, of cause) an so on.

Main issue is 'how to make it looking not like hack, but as legitimate solution?'. If you have guts and will, you can create new SR, which will bring specialized VM online during pbd-plug operation.

SM stuff is written in python and somehow simple to debug (easier than xapi ocaml code). You can even supply some data to VM via PV-agrs.

30.06.2013 04:46, Grant McWilliams ÐÐÑÐÑ:
Thanks George,

On Sat, Jun 29, 2013 at 12:40 PM, George Shuklin <george.shuklin@xxxxxxxxx> wrote:
You want to protect dom0 data or domU? If domU, there is two solution without putting too much burden on dom0.

1) Encrypt data in domU. dom0 store and serve already encrypted data without special efforts.
2) Put all data on single VM, which store encrypted data and provide unencrypted SR to dom0 (via NFS or LVMoISCS).
Â
Â
I've pondered both of these. For the first solution - my thoughts were that the DomU's are logged into and used by various people and they're also maintained by various other people. My idea behind encrypting the Dom0's SR is that the DomU's would be encrypted and the Dom0 wouldn't boot without having the appropriate key. This way we're limiting the chances that one of the DomU's would have been configured improperly and sensitive data would be accessible.

Getting block encryption support in the Dom0 has become such a pain that encrypting the DomU's may be the best option.Â


Your Âsecond solution I'd thought about but discounted it as a hack. Yes, it would work but I'm not sure it's a great idea. A similar solution to this is to have an NFS or iSCSI SR accessible through the VPN back in the data center so all sensitive data would be stored off the device. If the device can't connect to the VPN without the external key then the data would be reasonably secure etc..

Still pondering. I'd be interested to hear from anyone who may have gotten Dom0 block encryption to work.Â


28.06.2013 23:39, Grant McWilliams ÐÐÑÐÑ:
We have a project where all data on DomU's will be sensitive. There will be multiple DomU's spawned depending on needs. It would seem the best way to ensure all sensitive data ie. DomU disks are encrypted we've been trying to use LUKS/Truecrypt on the Control Domain disks. The XCP hosts are mobile and if one was to go missing we'd like to know that the data isn't going to be available. We were thinking of a hardware key or a keystore.Â

The problem is that the XCP/Xenserver 6.2 kernel doesn't seem to have enough crypto support for encrypting the disks.Â

------
Luks refuses to encrypt.. I've tried multiple ciphers listed in /proc/crypto to no avail.
Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/sda2 contains at least 133 sectors.

------
Truecrypt encrypts (as long as I use IT'S encryption and not the kernel) but I get a device-mapper ioctl error when trying to mount it.

echo 4 | truecrypt -t -c --volume-type=normal -m=nokernelcrypto --encryption=AES --hash=SHA-512 -p "" --keyfiles="/root/secure.key" --random-source=/dev/urandom --quick /dev/sda2

Done: 100.000% ÂSpeed: Â5.5 GB/s ÂLeft: 0 sÂ

Error: device-mapper: reload ioctl failed: Invalid argument
Command failed


Has anyone encrypted any local directories on Xenserver/XCP successfully? Or do you have other suggestions.Â

Grant McWilliams
http://grantmcwilliams.com/


_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api


_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api



_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.