Thanks George, On Sat, Jun 29, 2013 at 12:40 PM, George Shuklin <george.shuk...@gmail.com>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 > listxen-...@lists.xen.orghttp://lists.xen.org/cgi-bin/mailman/listinfo/xen-api > > > > _______________________________________________ > Xen-api mailing list > Xen-api@lists.xen.org > http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api > >
_______________________________________________ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
