Mailing List Archive

Hello,

On Wed, Jul 01, 2020 at 10:59:41AM +0200, Christoph wrote:
> I have some crypted (LUKS) devices which I use in some domU's.
> It is better to passthrough a crypted devices and open it in domU or
> passthrough an already opened plain device to a domU?

I open them inside the domU because not all domUs require encrypted
storage. Also some of them are managed by the guest administrators and I
don't know the key material - it's not stored in the dom0 storage at all.

I would have thought that opening it in dom0 would be slightly less
secure as anyone who is root in dom0 can read the block device as if
it was not encrypted. Obviously anyone with root in a privileged
domain can read the memory of a guest and get the key material out
of that anyway, but that would require a bit of motivation at least.

Cheers,
Andy

what about the rw performance? I think it should be a little bit
performant if I open it in dom0 already? cryptsetup/LUKS uses AFAIK the
AES extensions of cpu... does it use it in a domU to?

---
------
Greetz

Am 01.07.2020 12:36, schrieb Andy Smith:
> Hello,
>
> On Wed, Jul 01, 2020 at 10:59:41AM +0200, Christoph wrote:
>> I have some crypted (LUKS) devices which I use in some domU's.
>> It is better to passthrough a crypted devices and open it in domU or
>> passthrough an already opened plain device to a domU?
>
> I open them inside the domU because not all domUs require encrypted
> storage. Also some of them are managed by the guest administrators and
> I
> don't know the key material - it's not stored in the dom0 storage at
> all.
>
> I would have thought that opening it in dom0 would be slightly less
> secure as anyone who is root in dom0 can read the block device as if
> it was not encrypted. Obviously anyone with root in a privileged
> domain can read the memory of a guest and get the key material out
> of that anyway, but that would require a bit of motivation at least.
>
> Cheers,
> Andy

The root user of dom0 might / should be different from the root user of the domU.



From: "Andy Smith" <andy@strugglers.net<mailto:andy@strugglers.net>>
Date: Wednesday, 1 July 2020 at 12:46:32
To: "xen-users@lists.xenproject.org" <xen-users@lists.xenproject.org<mailto:xen-users@lists.xenproject.org>>
Subject: Re: Crypted devices... where open them?

Hello,

On Wed, Jul 01, 2020 at 10:59:41AM +0200, Christoph wrote:
> I have some crypted (LUKS) devices which I use in some domU's.
> It is better to passthrough a crypted devices and open it in domU or
> passthrough an already opened plain device to a domU?

I open them inside the domU because not all domUs require encrypted
storage. Also some of them are managed by the guest administrators and I
don't know the key material - it's not stored in the dom0 storage at all.

I would have thought that opening it in dom0 would be slightly less
secure as anyone who is root in dom0 can read the block device as if
it was not encrypted. Obviously anyone with root in a privileged
domain can read the memory of a guest and get the key material out
of that anyway, but that would require a bit of motivation at least.

Cheers,
Andy


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 elektronisch 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.

On Wednesday, July 1, 2020 10:59:41 AM CEST Christoph wrote:
> Hi
>
> I have some crypted (LUKS) devices which I use in some domU's.
> It is better to passthrough a crypted devices and open it in domU or
> passthrough an already opened plain device to a domU?
>
> --
> ------
> Greetz

I would suggest it depends on who "owns" the domUs.

If the domU is not owned by the same person as who owns dom0, then the
decryption should be handled in the domU as dom0 should not have access to the
decription keys.

If you own both dom0 and domU, you can decide where to use the decryption
keys.
In this case, I would decrypt it on the dom0. The reason being:

1) the dom0 should have less exposure, which means it will be more difficult
to break into and grab the keys

2) the data will be accessible anyway as long as the drive is "decrypted",
which means as long as the machine is powered, the keys are not really needed.

--
Joost

Am Mittwoch, 1. Juli 2020, 13:32:49 CEST schrieb J. Roeleveld:
> If the domU is not owned by the same person as who owns dom0, then the
> decryption should be handled in the domU as dom0 should not have access to
> the decription keys.
This is the design of Xen arch.

DomUs superuser by priciple is logically different from Dom0.

> If you own both dom0 and domU, you can decide where to use the decryption
> keys.
> In this case, I would decrypt it on the dom0. The reason being:
So if you "own" DomUs and Dom0, you may own the hardware too, so why not
doing it in the "storage hardware" (where lot of solutions exist too?)... ?)
#bitjoke

> 1) the dom0 should have less exposure, which means it will be more
> difficult to break into and grab the keys
On the other hand, such a solution "within xen" would require significant more
complexity of Xen which itself would offers more exposure to attackers onto
the whole system (even the ones who did not use that "feature")...

The elegantness of xen is his simplicity.

i would say: keep it simple and/or "fit your design"...

Or use some crypto solutions integrated in the block device solution you
decide for to use for DomUs at "device level" and unlock it byself before
starting any DomUs - transparent to Xen itself. Xen allows scripting of such
stuff. See /etc/xen/scripts/block-* scripts for instance.

> 2) the data will be accessible anyway as long as the drive is "decrypted",
you probably mean "unlocked"...

> which means as long as the machine is powered, the keys are not really
> needed.
But same "applies" to DomU


just my 0.2$


niels.




--
---
Niels Dettenbach
Syndicat IT & Internet
http://www.syndicat.com
PGP: https://syndicat.com/pub_key.asc
---

On Wednesday, July 1, 2020 2:05:50 PM CEST Niels Dettenbach wrote:
> Am Mittwoch, 1. Juli 2020, 13:32:49 CEST schrieb J. Roeleveld:
> > If the domU is not owned by the same person as who owns dom0, then the
> > decryption should be handled in the domU as dom0 should not have access to
> > the decription keys.
>
> This is the design of Xen arch.
>
> DomUs superuser by priciple is logically different from Dom0.

In principle, yes. But I meant, are they all managed by the same entity, or is
this a hosting environment where VMs are provided to customers.

> > If you own both dom0 and domU, you can decide where to use the decryption
> > keys.
>
> > In this case, I would decrypt it on the dom0. The reason being:
> So if you "own" DomUs and Dom0, you may own the hardware too, so why not
> doing it in the "storage hardware" (where lot of solutions exist too?)... ?)
> #bitjoke

Hardware solutions are, for me, on the same level as the dom0.

> > 1) the dom0 should have less exposure, which means it will be more
> > difficult to break into and grab the keys
>
> On the other hand, such a solution "within xen" would require significant
> more complexity of Xen which itself would offers more exposure to attackers
> onto the whole system (even the ones who did not use that "feature")...

How would this require additional complexity?
The block-device is unlocked on the dom0 and the unlocked block device is
passed on to the domU.

> The elegantness of xen is his simplicity.
>
> i would say: keep it simple and/or "fit your design"...

Agree

> Or use some crypto solutions integrated in the block device solution you
> decide for to use for DomUs at "device level" and unlock it byself before
> starting any DomUs - transparent to Xen itself. Xen allows scripting of such
> stuff. See /etc/xen/scripts/block-* scripts for instance.
>
> > 2) the data will be accessible anyway as long as the drive is "decrypted",
>
> you probably mean "unlocked"...

Yes, I quickly typed my reply and got the terminology wrong.

> > which means as long as the machine is powered, the keys are not really
> > needed.
>
> But same "applies" to DomU

True, in my case, domUs are generally running for the same period as the host
itself. Only time they are not running is when the host is off or the domU is
being restarted.

--
Joost

Am Mittwoch, 1. Juli 2020, 14:35:26 CEST schrieb J. Roeleveld:
> The block-device is unlocked on the dom0 and the unlocked block device is
> passed on to the domU.
As i wrote, if you want to do some kind of such special solution (which depend in detail from the storage as crypto solution you decide for), you can srcipt that by xen scripting interface:

see:
/etc/xen/scripts/block*

for examples / default scripts which you may adapt for your needs.

This then get passsed i.e. by "script" parameter in your DomU storage configs.

see i.e.:
https://doc.opensuse.org/documentation/leap/virtualization/html/book.virt/cha-xen-vbd.html
https://xenbits.xen.org/docs/4.7-testing/misc/block-scripts.txt

ther's no need to modify xen itself.


hth,


niels.




--
---
Niels Dettenbach
Syndicat IT & Internet
http://www.syndicat.com
PGP: https://syndicat.com/pub_key.asc
---