Re: [Xen-users] Automating boot of Ubuntu on encrypted LVM?

[<J.Witvliet@xxxxxxxxx>]

Indeed, Rich,

Security, ease-of-use and costs form a triangle and you have to define what's 
most important.
A nice option is indeed to retrieve a luks-key from a file, and you can store 
that on a usb-stick, or even on a smartcard or Etoken. But if everybody has 
access to it, what do you gain?

In general, if you replace "what-you-know" with "what-you-have" be certain that 
not everybody can-have-that.
Secondly, take care of a (protected) backup of "what-you-knew" or 
"what-you-had" ;-)


-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxx [mailto:xen-users-bounces@xxxxxxxxxxxxx] 
On Behalf Of Paul Stimpson
Sent: Tuesday, April 09, 2013 3:57 PM
To: xen-users@xxxxxxxxxxxxx
Subject: Re: [Xen-users] Automating boot of Ubuntu on encrypted LVM?

Hi Rich,

I'm not sure I'm following your motivation and goals here. Please will 
you say what the threat(s) you are trying to defend against are? Are we 
talking remote hackers, people who might be able to obtain physical 
access to the machine or hardware thieves? Casual crackers or "more 
determined" ones? It's really important to take the time to identify 
what you are trying to defend against when planning security to avoid a 
solution that is a pain to the users but doesn't actually mitigate the 
threats properly.

If we are talking people with physical access to the hardware, it is 
impossible to guarantee security as /boot must be in the clear on the 
Dom0 for it to be bootable. It would always be possible for someone with 
physical access and sufficient motivation to introduce a trojanized 
kernel or other system binary that would record the passphrase the next 
time you booted the machine so that the attacker could collect it later. 
A possible mitigation of this would be to put your Dom0 /boot on a 
read-only medium, like a CD, and make sure the machine doesn't have a CD 
burner so it can't be modified in place.

On 08/04/13 04:07, Rich Wales wrote:
> I'm not willing to encrypt my dom0 because if the hardware does a 
> reboot while I'm away, I want/need to be able to SSH into it in order 
> to start up the domU (and, eventually, multiple domUs). That wouldn't 
> be possible if the dom0 required hands-on entry of a passphrase to 
> finish booting. 

One way you could achieve this would be to have a couple of conventional 
partitions (or a separate LVM) for the Dom0 /boot and root then have an 
LVM partition to contain all the DomU filesystems. You would then 
encrypt the DomU LVM partition. This would mean that the the Dom0 would 
boot but Xen would be unable to create the guests until you had entered 
the passphrase to unlock the encryption on the DomU LVM. It would be 
relatively easy to use "one passphrase to rule them all..." It would 
also ensure that the swap and /tmp on the guests was encrypted, 
preventing any information leakage. You also have the advantage that you 
don't need to support the encryption on the DomU as the container is 
unlocked on the Dom0. You would also gain LVM flexibility to resize the 
DomU partitions as your needs change.

Alternatively, you could encrypt the Dom0 and use an IP KVM like the 
Adder CATx 1000 or their Infinity network console extender. The box 
would start to boot and sit at the passphrase entry dialogue for the 
Dom0 root. The Adder box would convert the physical console output of 
the machine into VNC and you would VNC in and enter the password to make 
it boot.

> What I want is a way to encrypt my domU's root partition, but avoid 
> needing to type in a decryption passphrase by having said passphrase 
> supplied via a file on the dom0. I'll take care of safeguarding the 
> boot passphrase(s) by storing the file(s) in my ecryptfs-encrypted 
> home directory on the dom0. Rich Wales richw@xxxxxxxxx 
> _______________________________________________ Xen-users mailing list 
> Xen-users@xxxxxxxxxxxxx http://lists.xen.org/xen-users 

I would go with the encrypted DomU-only LVM as above.

Bests,
Paul.


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet 
de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u 
verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat 
aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband 
houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. The State accepts no 
liability for damage of any kind resulting from the risks inherent in the 
electronic transmission of messages.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users