Xen users - Apr 2013 - Automating boot of Ubuntu on encrypted LVM?

I''m running Xen 4.1.3 on an Ubuntu 12.10 server; currently using
the "xl" toolstack.

I have an Ubuntu 12.04.2 domU with an encrypted LVM root partition.
Whenever I launch this machine, I currently need to attach to the
domU''s console (via vncviewer) and manually type in the passphrase
to unlock the encrypted partition and allow the domU to boot.

If possible, I would like to put the passphrase in a file on the
dom0, and configure the domU to read the passphrase from this file
when it boots.

I am using ecryptfs for my dom0 home directory, and I would put
the passphrase file there, and set up Xen so that it would check
for the existence of the passphrase file (i.e., wait till I had
logged in to my account on the dom0) before starting up the domU.

Is this possible?  If so, how would I set it up?

Rich Wales
richw@richw.org

If it would solve your problem: You could use one encrypted partition, 
holding a VG, holding an LV for each of the dom0 & domU roots.  The dom0 
/boot sits in a normal partition.  The passphrase is requested once on 
boot of the dom0.  It seems like the security would be equivalent.
> I have an Ubuntu 12.04.2 domU with an encrypted LVM root partition. 
> Whenever I launch this machine, I currently need to attach to the 
> domU''s console (via vncviewer) and manually type in the passphrase
to
> unlock the encrypted partition and allow the domU to boot.
> 
> If possible, I would like to put the passphrase in a file on the dom0, 
> and configure the domU to read the passphrase from this file when it 
> boots.
> 
> I am using ecryptfs for my dom0 home directory, and I would put the 
> passphrase file there, and set up Xen so that it would check for the 
> existence of the passphrase file (i.e., wait till I had logged in to 
> my account on the dom0) before starting up the domU.

> If it would solve your problem: You could use one encrypted partition, 
> holding a VG, holding an LV for each of the dom0 & domU roots.  The
dom0
> /boot sits in a normal partition.  The passphrase is requested once on 
> boot of the dom0.  It seems like the security would be equivalent.
What you''re describing is, in fact, the way my domU is currently set
up.

But what I''m trying to do here is to find a way for the boot process of
the domU to get the passphrase from a file, instead of my needing to type
it to the domU''s console.

Rich Wales
richw@richw.org

>> use one encrypted partition, holding a VG, holding an LV for each of 
>> the dom0 & domU roots.  The dom0 /boot sits in a normal partition.
>> The passphrase is requested once on boot of the dom0.
> 
> What you''re describing is, in fact, the way my domU is currently
set
> up.
It must not be, because if I set up a system as I described, I''m 
prompted for the passphrase only once.  No need to enter the (same) 
passphrase again when the domU boots.

This requires booting the domU with the domU''s initrd, not
dom0''s.  I
know Debian, but I don''t know how Ubuntu sets that up.
> But what I''m trying to do here is to find a way for the boot
process
> of the domU to get the passphrase from a file, instead of my needing 
> to type it to the domU''s console.
If it''s the same passphrase for the same dm_crypt device that dom0
uses,
you shouldn''t need to enter it again.

>>> use one encrypted partition, holding a VG, holding an LV for each
of
>>> the dom0 & domU roots.  The dom0 /boot sits in a normal
partition.
>>> The passphrase is requested once on boot of the dom0.
>>
>> What you''re describing is, in fact, the way my domU is
currently set
>> up.
> 
> It must not be, because if I set up a system as I described, I''m 
> prompted for the passphrase only once.  No need to enter the (same) 
> passphrase again when the domU boots.
Oh, wait a minute, I think I see what you''re saying -- and it
isn''t what
I''m doing after all.  Sorry I was confused earlier when I first read
your message.

In my setup, the dom0 is unencrypted and boots normally, without requiring
any password.  It''s the domU that requires a password to complete the
boot
process.

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.

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@richw.org

On Mon, Apr 8, 2013 at 10:07 AM, Rich Wales <richw@richw.org> wrote:
> 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.
Have you considered a simpler method?

For example, if you just want to have dom0 boot normally while domU
boot requires some kind of password, then Mike''s suggestion should
work. You encrypt everything that domU uses (domU''s config file and
disk), but leave everything that only dom0 use unencrypted. One easy
way to do this is by having a separate VG:
- dom0 -> VG_1 -> PV on unencrypted disk/partition
- domU -> VG_2 -> PV on encrypted disk/partition (e.g. luks)

During boot, dom0 boot just fine, but then you log in to unencrypt the
luks partition and manually run the commands to start all domUs.

-- 
Fajar

Hello.

El 07/04/13 23:07, Fajar A. Nugraha escribió:
> For example, if you just want to have dom0 boot normally while domU
> boot requires some kind of password, then Mike''s suggestion should
> work. You encrypt everything that domU uses (domU''s config file
and
> disk), but leave everything that only dom0 use unencrypted. One easy
> way to do this is by having a separate VG:
> - dom0 -> VG_1 -> PV on unencrypted disk/partition
> - domU -> VG_2 -> PV on encrypted disk/partition (e.g. luks)
>
> During boot, dom0 boot just fine, but then you log in to unencrypt the
> luks partition and manually run the commands to start all domUs.
I wish to confirm, it is a very working setup. I use something very 
similar myself. An alternative would be to provide DomU with a initrd 
with embedded key, which is more complex to set up and maintain.

In both cases, it''s assumed that DomU trusts Dom0, so it''s
perfectly
legal to leave the encryption to Dom0 and reduce complexity in DomU.

In case Dom0 is administrated by someone else, it''s another story.

In my case, Dom0 is also encrypted, but is uses a separate Physical 
Volume and Volume Group, so it''s a completely independent mechanics. 
Dom0 asks passphrase from console or can read it form USB drive, if 
somebody authorized, who is near, inserts it before booting (and remove 
it once booted). Little bit tricky, if I where to setup something like 
this again, I would give a chance to a initrd with embedded minimalistic 
ssh server, so the key might be provided remotely.

Greetings.

-- 
Alexandre Kouznetsov

Would this help
https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS#Storing_the_Key_File


On Mon, Apr 8, 2013 at 11:42 AM, Alexandre Kouznetsov
<alk@ondore.com>wrote:
> Hello.
>
> El 07/04/13 23:07, Fajar A. Nugraha escribió:
>
>  For example, if you just want to have dom0 boot normally while domU
>> boot requires some kind of password, then Mike''s suggestion
should
>> work. You encrypt everything that domU uses (domU''s config
file and
>> disk), but leave everything that only dom0 use unencrypted. One easy
>> way to do this is by having a separate VG:
>> - dom0 -> VG_1 -> PV on unencrypted disk/partition
>> - domU -> VG_2 -> PV on encrypted disk/partition (e.g. luks)
>>
>> During boot, dom0 boot just fine, but then you log in to unencrypt the
>> luks partition and manually run the commands to start all domUs.
>>
>
> I wish to confirm, it is a very working setup. I use something very
> similar myself. An alternative would be to provide DomU with a initrd with
> embedded key, which is more complex to set up and maintain.
>
> In both cases, it''s assumed that DomU trusts Dom0, so
it''s perfectly legal
> to leave the encryption to Dom0 and reduce complexity in DomU.
>
> In case Dom0 is administrated by someone else, it''s another story.
>
> In my case, Dom0 is also encrypted, but is uses a separate Physical Volume
> and Volume Group, so it''s a completely independent mechanics. Dom0
asks
> passphrase from console or can read it form USB drive, if somebody
> authorized, who is near, inserts it before booting (and remove it once
> booted). Little bit tricky, if I where to setup something like this again,
> I would give a chance to a initrd with embedded minimalistic ssh server, so
> the key might be provided remotely.
>
> Greetings.
>
> --
> Alexandre Kouznetsov
>
>
>
> ______________________________**_________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>

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

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@richw.org 
> _______________________________________________ Xen-users mailing list 
> Xen-users@lists.xen.org http://lists.xen.org/xen-users 
I would go with the encrypted DomU-only LVM as above.

Bests,
Paul.

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@lists.xen.org [mailto:xen-users-bounces@lists.xen.org]
On Behalf Of Paul Stimpson
Sent: Tuesday, April 09, 2013 3:57 PM
To: xen-users@lists.xen.org
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@richw.org 
> _______________________________________________ Xen-users mailing list 
> Xen-users@lists.xen.org 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@lists.xen.org
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.

Sorry for the delay in getting back to people on this.

My main security worry is the possibility that the server (in my home)
might be stolen by thieves.  I''m taking measures to secure the box
physically, of course, but in the event someone manages to make off
with the hardware, I want to make it very difficult for even a skilled
hacker to get at my data.

My original idea (automatic decryption of a domU''s main partition via a
key file passed to the domU at creation time) should be doable by making
changes to the domU''s /etc/crypttab file (then doing update-initramfs
on
the domU).  The key file would reside in my home directory on the dom0,
which is encrypted using ecryptfs; thus, no one would be able to start
the domU or make any sense of the data in its LVM partition unless I
had first logged in to my account on the dom0 -- but once I had logged
in, I could create the domU and it would launch without further manual
intervention.

The following article may be helpful for inspiration (though it doesn''t
talk specifically about using Xen):

http://askubuntu.com/questions/59487/how-to-configure-lvm-luks-to-autodecrypt-partition

Since it would be very easy to mess things up badly by making a mistake
here, I''m going to wait until I have a lot of spare time to do this; in
the meantime, I''ll continue to type a passphrase by hand whenever the
domU is started or restarted.

Rich Wales
richw@richw.org