Password encryption for individual vm's

[Blacklight447]

Hello qubes developers!

I have a question about qubes vm's.
Would it make sense to implement a method for password protecting(and maybe even encrypting it with that password) individual vm's?

Correct me if I am wrong, but it seems that by doing so, vm's are harder to access in case of a compromise.

For example, if someone were to break out of the xen hypervisor and gained access to dom 0, although this would be a fatal compromise, having some specific vm's encrypted when turned off(like the vault vm for example) should protect the content of those vm's since it's content is encrypted.

You could see it as full disk encryption, but only for specific vms, and needing the encryption password the even boot the vm and see its content.

I think this could potentially a nice feature to have in a future qubes release, what do you all think off this?
All suggestions and comments on this idea is welcome.


P. S. I wasn't sure were to poste this question, since it seems to be related to development to me, please point out where I should ask this if I got this wrong :)


Best regards,
Blacklight447

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Per-VM encryption is currently being tracked here:

https://github.com/QubesOS/qubes-issues/issues/1293

There are also prior discussions about this in the mailing list
archives, which you may find interesting.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJY2jrZAAoJENtN07w5UDAwnz0P/iJNqS6XQsJIxKt6FzcqsPDJ
e2CkPJaDUIb7pFyNB4wgXIkIvsHsVfV22Kja1DP2MEXX7GyE5UI5ncYSEr80ZN08
+T4Uc9fqEkknracdFZVk/mdKqJLsjOHqBTOIi/5KWpZCXKJLzWcwXUHX0/j/4f/i
rOLTQ0CcCba07A82i4iLlJx/+hpiPMBnhixwlYvPnccRaLEGhxRWYr9JnyprmXpZ
rRmUYae/UK2sTflqL6hbEiCGuBn7rNCsXFNGsrO9cSneD7kdwRO8eKxsYbTEhCOY
Tm/VFvblN6VL5nRCgG0mlEeuQDpKIBlm0eS1AnIcOgoxDz1mqQ/tWm6dDrtOr+NL
N5Csfbt4xynAJn+FQ/R8hvjPozeuHGckGAVsUuoik1shitVU5C8TedInqTSbMyA6
EwsreYysY3Y6d401ZXl+1pJaN0NXti0BeB8JYhzqB6CQTbAOpOoM9DE/2sYJGsxT
MJZpeyBAU324tXig8C3hsugWxRqXMXKh90YgkeSJ+FbrH2KAmdmXsNR3i6E9m4m/
kjn6uUcc0IgYY2LJWLMckPqYhvv7YvdLxAo1gk/6CoY0PRal+htT28+oVHdC5fvv
seR/D1MEJkdabZx1+Lf2fUKm7Z0ZsCqm85HTx4CL3mCUDsy1Bw235olTB1sdufRC
/ADWCVRn82lq+/Ht1Yic
=QBr5
-----END PGP SIGNATURE-----

[Blacklight447]

Thank you!

I have been reading the documentation and searched it quite a bit on duckduckgo, but I weren't successful so far, so thank you for this

Best regards,
Blacklight447



-------- Original Message --------

[Chris Laprise]

As Andrew noted, there's no per-VM encryption available before R4 is
released. However, its conceivable a user could patch something together
in R3.2 using a dom0 passphrase prompt that decrypts a storage pool
before the VM is actually started.

As for password protection within a VM, the core issue is preventing
instant access to root (if I'm reading your correctly). That's a topic
which pops up regularly. A solution is provided in the docs which uses a
dom0 Yes/No prompt instead of passwords to grant permissions:

https://www.qubes-os.org/doc/vm-sudo/#replacing-password-less-root-access-with-dom0-user-prompt

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Blacklight447]

The basic idea was that you have to provide a password to decrypt the vms data, so you can boot and use it, allowing you to be sure only you can access its data. This could even be potentially combined with an option to export the encrypted vm, to later boot it in a clean version of qubes os.

Im not looking for just a password prompt, since those do not provide any real security, unless your threat model is preventing someone to access your vm"s when you forgot to shutdown or lock your machine.





-------- Original Message --------

--
You received this message because you are subscribed to the Google Groups "qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/b24cc0d2-55d1-5537-a9f9-2d1a0d5ff15b%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[Ángel]

On 2017-03-28 at 08:33 -0400, 'Blacklight447' via qubes-devel wrote:
> The basic idea was that you have to provide a password to decrypt the
> vms data, so you can boot and use it, allowing you to be sure only you
> can access its data. This could even be potentially combined with an
> option to export the encrypted vm, to later boot it in a clean version
> of qubes os.
>
> Im not looking for just a password prompt, since those do not provide
> any real security, unless your threat model is preventing someone to
> access your vm"s when you forgot to shutdown or lock your machine.
>

You can use a HVM with LUKS disk. The password will be asked on boot,
just as when booting a physical OS with an encrypted disk.

However, being a HVM there will be less integration with other qubes
(maybe the support tools can be installed -and work- on HVM, too?).

[Joe]

I posted some scripts to this list on 15th of December 2015 with the
subject "Individually encrypting domains" that implements groups of
encrypted VMs (you can have groups of one if you so wish, of course).

I still maintain these scripts privately, and have been using them for
~two years now without problems.

I also have a Python ctypes oneline to call posix_fallocate() on
root.img to get rid of the thin provisioning stuff using sparse files
that upstream Qubes applies to make sure your data gets fucked up when
you run out of disk space in dom0.

(Works for the other .img, too, where a similar problem presents itself,
of course, but I have disabled volatile.img in my setup because I
consider the feature insane.)

If someone wants a copy I'd be happy to share.

[Andrew Clausen]

Hi Joe,

I'm interested!  Maybe you could publish them on a public git repository (e.g. github).

Kind regards,

Andrew

--
You received this message because you are subscribed to the Google Groups "qubes-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscribe@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/9060248f-c11d-22ad-8074-4cf8097d18f6%40celo.io.

[Cyril]

Joe,

I'm interesting too :)

Regards

[thorsten...@gmail.com]

I am also interested in having encrypted vms (preferably having one password for each VM-group).
Let's assume I have one or more VMs for each customer which contain sensitive data that must not leak anywhere. While working for customer 1 I want to make sure that only VMs for customer 1 are decrypted and usable (along with my non-customer VMs). VMs from customer 2,3,... should be encrypted and unaccessible at this time. When I move to cusomer 2, only these VMs should be decrypted, etc.

My goals are:

- In the rare case I forget to lock my notebook at cusomer 1 I don't want anyone to be able to extract other customers data. (While not perfect in regards to dom0 security at least it makes sure no data can be stolen)

- Not sure about this one but by default VM data is written unencrypted to disk (or only encrypted with the standard boot password), correct? So it's theoretically possible that VM1 could potentially get data chunks from VM2 in case of harddrive failure (bad sectors, etc) or similar. Or is this impossible?

I've seen this a few times in the past, where data was mixed up in the system and ended up where it didn't belong. Mainly it happend on Windows systems, so I'm not sure if it's also possible on Qubes.
One example is a Windows registry where registry keys consisted of book titles along with normal registry keys. Somehow a list of books (I'm guessing a .txt file or similar) ended up being mixed into the registry file and regedit displayed them as registry keys which were not usable (an error message appeared when selecting them, saying the file could not be found if I remember correctly)

- And lastly it would make things faster/easier when deleting data. Since the data is encrypted the VMs could just be deleted without any special care!?

Is there already a documentation or script collection for doing this?
I've found the scripts from Joe but they seem to be for Qubes 3.2 not for 4.0.

=============

Possible feature request:

Maybe this feature could be implemented into Qubes directly like this:
- Possibility to create VM-domains with domain speciefic en-/decryption password (i.e. "customer1", "customer2", ...)
- Possibility to create VMs with a VM-domain specified (without a VM-domain it could be "none" and these VMs would work just like it is at the moment)
- If a VM is created for a VM-domain, the VM data is encrypted by default with the master key of this domain which is unlocked with the user provided password.
- If one would try to start any VMs inside a VM-domain, Qubes would check if the VM-domain is currently unlocked/decrypted/mounted and starts the VMs. If it's not unlocked, a password prompt appears before they can be decrypted/mounted and started.

I'm not sure how much work this would be but I imagine it wouldn't be that hard to implement!? Or maybe this could also be a project for Google Summer of Code?

[Raffaele Florio]

> - In the rare case I forget to lock my notebook at cusomer 1 I don't want anyone to be able to extract other customers data. (While not perfect in regards to dom0 security at least it makes sure no data can be stolen)
>

After you forgot the notebook, will you restore to a clean state (like using paranoid mode, at least)? Because you are worried I think so. And this should be done everytime the notebook is left unattended. You know, compromised Dom0 = game over.
Furthermore this approach gives a false sense of security, for various reason. For example why are you excluding that someone with access at your laptop while in "customer1 mode" couldn't obtain advantages? Maybe he/she's only looking for that. Who knows?
The major issue is that the "forgotten principle" is bad. Probably it's simpler to carry the notebook with you (after all it's portable).
I got your point, but for the aforesaid reasons I think it's risky to implement this feature in Qubes OS.

# Idea proposal:
During writing I had an idea. An improved way to handle such use case could be the concept of PC (OS or Qubes) state (I hadn't time to find a suitable name, lol). I mean: when you are in a state *only* a subset of VMs are *present*, the other ones are deleted (according the definition of deleted of a non-volatile support..). When you restore to another state (it could be also a "full state") a paranoid restore is done, by default. In this way users are *forced* to restore, so they *know* the risk. The key is that this state isn't related to a VMs group, instead it's related to your entire system.

> - Not sure about this one but by default VM data is written unencrypted to disk (or only encrypted with the standard boot password), correct? So it's theoretically possible that VM1 could potentially get data chunks from VM2 in case of harddrive failure (bad sectors, etc) or similar. Or is this impossible?
>

By default the data is written encrypted. Did you mean two blocks shared between at least two logical volume?



Best Regards,
Raffaele.

[Raffaele Florio]

> Idea proposal:
>
> ===============
>
> During writing I had an idea. An improved way to handle such use case could be the concept of PC (OS or Qubes) state (I hadn't time to find a suitable name, lol). I mean: when you are in a state only a subset of VMs are present, the other ones are deleted (according the definition of deleted of a non-volatile support..). When you restore to another state (it could be also a "full state") a paranoid restore is done, by default. In this way users are forced to restore, so they know the risk. The key is that this state isn't related to a VMs group, instead it's related to your entire system.
>
Furthermore the user is not constrained to remember any password (in your approach each VMs domain has one password).


Best Regards,
Raffaele.

[thorsten...@gmail.com]

> After you forgot the notebook, will you restore to a clean state (like using paranoid mode, at least)? Because you are worried I think so. And this should be done everytime the notebook is left unattended. You know, compromised Dom0 = game over.

Yes, of course you have to consider the notebook compromised at this point and needs to be reset to a clean state afterwards. But that's another topic, It's all about minimizing the damage done here. If the VM groups are encrypted individually, at least you can have some peace of mind that non critical data could have been stolen from another customer/vm-groups.

> The major issue is that the "forgotten principle" is bad. Probably it's simpler to carry the notebook with you (after all it's portable).

This might not be possible at all times. What if you are running time consuming jobs like forensic data collection, pen testing, etc. and need to go to the toilet for example? Do you interrupt everything just to take the notebook with you and start over again afterwards?

> I got your point, but for the aforesaid reasons I think it's risky to implement this feature in Qubes OS.

Why would this be "risky" at all? It only adds to security imo since at the moment everything is accessible once you gain access to dom0. So if anyone manages to get access (ie. hidden camera to spy your password to dom0) everything is in danger. Also it wouldn't change anything for the standard VMs which would be by default in vm-group "none", meaning they are all accessible just like they are right now. So you get encrypted vm-groups which are more secure and can be unlocked when needed by the user in addition to what we have right now.

> During writing I had an idea. An improved way to handle such use case could be the concept of PC (OS or Qubes) state (I hadn't time to find a suitable name, lol). I mean: when you are in a state *only* a subset of VMs are *present*, the other ones are deleted (according the definition of deleted of a non-volatile support..). When you restore to another state (it could be also a "full state") a paranoid restore is done, by default. In this way users are *forced* to restore, so they *know* the risk. The key is that this state isn't related to a VMs group, instead it's related to your entire system.

Not sure if I understood this correctly but this sounds very impractical!? If you have to shread and restore every time when you switch customers you are going to lose a huge amount of time and you would also have to carry around all your backups in order to restore them? I'd rather use the "decrypt when needed" approach where you get instant access and don't have to wipe and restore all the time.

> Furthermore the user is not constrained to remember any password (in your approach each VMs domain has one password).

In theory it would be also possible to use the user password for "unlocking" vm-groups since the vm-groups would not be encrypted directly with the password itself but rather with a master key stored in some encryption header which is decrypted by the provided password (so you can change the password without having to re-encrypt the whole vm-groupd rather than just the encryption header).

> By default the data is written encrypted.

Do you mean that each VMs data is encrypted with a unique VM-specific key by default? I was under the impression that they are not encrypted at all and you could mount the data partitions at any time in dom0. In theory you could also mount data partitions from VM1 to VM2 without providing any keys etc.?

> Did you mean two blocks shared between at least two logical volume?

I'm not sure how this happened but as I already said, I've seen data being mixed up due to some HHD failure (probably). When all VM data is encrypted with a unique key that only belongs to this one VM or at least a vm-group, data cannot be mixed up at all since the decryption key of VM2 would read only data garbage from VM1 data. (in case this is possible in Qubes, I've only seen this under Windows so far)

[Raffaele Florio]

> Yes, of course you have to consider the notebook compromised at this point and needs to be reset to a clean state afterwards. But that's another topic, It's all about minimizing the damage done here. If the VM groups are encrypted individually, at least you can have some peace of mind that non critical data could have been stolen from another customer/vm-groups.
>

As I said I understand your point. However I think that *this* approach is too risky because it gives a false sense of security.

> Why would this be "risky" at all? It only adds to security imo since at the moment everything is accessible once you gain access to dom0. So if anyone manages to get access (ie. hidden camera to spy your password to dom0) everything is in danger. Also it wouldn't change anything for the standard VMs which would be by default in vm-group "none", meaning they are all accessible just like they are right now. So you get encrypted vm-groups which are more secure and can be unlocked when needed by the user in addition to what we have right now.
>

Because it could create bad habits. Qubes doesn't really enforce any secure scheme.

> Not sure if I understood this correctly but this sounds very impractical!? If you have to shread and restore every time when you switch customers you are going to lose a huge amount of time and you would also have to carry around all your backups in order to restore them? I'd rather use the "decrypt when needed" approach where you get instant access and don't have to wipe and restore all the time.
>

Here an improvements of my proposal. It's effectively an hybrid:
- You put the OS in a "state". There could be two "state", one where VMs are shreded and one where VMs are encrypted. To make things fast VMs could encrypted by default. However when in a "state" a specific user provided password is used. I write rapidly but I think you got the point..
- When you put in another state you could choose a paranoid mode (if the laptop was left alone) or simply Dom0 will decrypt other VMs (so the user password is asked, then forgotten).

The point I'm trying to make clear is that the system should enforce this scheme. With your approach there is a false sense of security, because cokplexity (too password) and bad habits (one password for all, not restoring when it should be done and so on..).

> In theory it would be also possible to use the user password for "unlocking" vm-groups since the vm-groups would not be encrypted directly with the password itself but rather with a master key stored in some encryption header which is decrypted by the provided password (so you can change the password without having to re-encrypt the whole vm-groupd rather than just the encryption header).
>

You missed a PBKDF. However it's not the point, user password isn't really usable, as you said before. Furthermore every VMs in this way will be implicitly in one and only one group. This scheme is already degenerated. As I said it will create bad habits..

> Do you mean that each VMs data is encrypted with a unique VM-specific key by default? I was under the impression that they are not encrypted at all and you could mount the data partitions at any time in dom0. In theory you could also mount data partitions from VM1 to VM2 without providing any keys etc.?
>

I mean that they are encrypted on the non-volatile support. If I remember correctly you were talking about data on a hard disk.

Best Regards,
Raffaele.

[thorsten...@gmail.com]

> As I said I understand your point. However I think that *this* approach is too risky because it gives a false sense of security.

> Because it could create bad habits. Qubes doesn't really enforce any secure scheme.

IMO habits are created by persons so everyone is responsible for their own actions. If you are concerned that users may make bad decisions I think it's better to raise peoples awareness for security instead of "enforcing" things.
You can display warnings or suggestions which assist the user, but in the end it's up to the user to decide whether it's suitable for the current case or not.

Let's take passwords for example, if you choose a weak password you might have a problem when handling sensitive data, but then again if you only play around with a test system without real data you might chose a weak password to make things easier (which is totally legitimate). So it always depends on the usecase. The Qubes installer might complain that your password is not secure enough but it still accepts it if you persist.

> Here an improvements of my proposal. It's effectively an hybrid:
> - You put the OS in a "state". There could be two "state", one where VMs are shreded and one where VMs are encrypted. To make things fast VMs could encrypted by default. However when in a "state" a specific user provided password is used. I write rapidly but I think you got the point..
> - When you put in another state you could choose a paranoid mode (if the laptop was left alone) or simply Dom0 will decrypt other VMs (so the user password is asked, then forgotten).
> The point I'm trying to make clear is that the system should enforce this scheme. With your approach there is a false sense of security, because cokplexity (too password) and bad habits (one password for all, not restoring when it should be done and so on..).

> However it's not the point, user password isn't really usable, as you said before. Furthermore every VMs in this way will be implicitly in one and only one group. This scheme is already degenerated. As I said it will create bad habits..

I was making a "quick" suggestion to have 1 vm-domain for each vm so you can unlock/decrypt a whole vm-domain with its specific password, since it's similar to the scripts from Joe.
You could also add VMs to one or more VM-groups like you do with users, so you could use any VM in multiple groups/domains.
Also for encrypting VM data we could use luks and add each vm-domains master key to it (luksAddKey), so every vm-domain password that is part of this VM can unlock that specific VM. You can also name it state or whatever you want, important is what it does.

> I mean that they are encrypted on the non-volatile support. If I remember correctly you were talking about data on a hard disk.

I was refering to data being stored on harddrive with just 1 encryption key for everything. If the system is running, all data is decrypted at once, so dom0 can access all VMs data in decrypted state. My concern was that if VM1 writes data to the harddrive, then it would be theoretically possible that VM2 can read this data if that hdd region ends up being mounted for VM2 somehow. I'm not sure if this is possible under Qubes, but I've seen mixed up data under Windows in the past. I'm assuming that it was caused by HDD corruption (not sure how, maybe while recovering bad sectors or when using chkdsk, etc.)

I've also seen this once on Amazon servers some time ago where video content was messed up. A normal video stream of about 20 minutes ended up being 2 hours since other video parts were mixed into it. So basically there was data from other streams that ended in another stream where they don't belong.

And that's exactly what I want to make sure can not happen in Qubes. Even in the worst case scenarios with HDD, filesystem, etc. it must not be possible that data from VM1 ends up in VM2, even if it's just small junks. So I thought if the VMs data were encrypted individually in the first place, it wouldn't be a problem at all if any data blocks would end up in another VMs hdd region since it wouldn't be able to read it (encrypted with different key).

[Brendan Hoar]

On Saturday, January 19, 2019 at 4:06:31 PM UTC-5, thorsten...@gmail.com wrote:
> And that's exactly what I want to make sure can not happen in Qubes. Even in the worst case scenarios with HDD, filesystem, etc. it must not be possible that data from VM1 ends up in VM2, even if it's just small junks. So I thought if the VMs data were encrypted individually in the first place, it wouldn't be a problem at all if any data blocks would end up in another VMs hdd region since it wouldn't be able to read it (encrypted with different key).

Agreed.

The counter argument really boils down to "well then you should have two air-gapped systems" and basically refutes the entire point of Qubes to begin with, which is hardware-enforced compartmentalization. Inserting a separation layer of group-encrypted VMs/domains makes sense to me: it allows for better run-time compartmentalization for both system security and possibly physical security as well (depending on OPSEC).

brendan

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 18/01/2019 11.43 PM, thorsten...@gmail.com wrote:
> I am also interested in having encrypted vms (preferably having one password for each VM-group).
> Let's assume I have one or more VMs for each customer which contain sensitive data that must not leak anywhere. While working for customer 1 I want to make sure that only VMs for customer 1 are decrypted and usable (along with my non-customer VMs). VMs from customer 2,3,... should be encrypted and unaccessible at this time. When I move to cusomer 2, only these VMs should be decrypted, etc.
>
> My goals are:
>
> - In the rare case I forget to lock my notebook at cusomer 1 I don't want anyone to be able to extract other customers data. (While not perfect in regards to dom0 security at least it makes sure no data can be stolen)

> [...]

We actually have an open issue for this:

https://github.com/QubesOS/qubes-issues/issues/1293

(I didn't see this mentioned in your message, so you may not be aware of
it.)

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxDs9cACgkQ203TvDlQ
MDCcuA/+J8cPzUqCLFRHfdlCqVucrw8uIvW5gAFSPXc18yjYlcvc5GUe6S08gyGx
e/QB+8SZpNaJeeaUnIpv1ZjRvkiK3KSogi/PTHwM10wBeQh+xdHcVx8M8d1zMbJb
s9/G+38CCvtO7calFdmi1PhWb2T2FOCZBvhIAOl2pIvP3Ax8oOvTuOmMFxGGBmkh
GTgHFt/jbYrBB4eMvAqo965rAyiBCQj9NQjBWobJf4xwjCFRK36QDxTo+wzTIW14
Pg5T14onZt74OAX+z4WXkd/e298yXu1i3w4ZyWG5KMubBt/Fe7qoingmvZKsxRJb
M7jEqtbNAduQUU6nqMUtuSXURH9/Hvy0oYfM/mYgzyPdazXwy0cUl8jIKAsyPmRZ
6JdigLFL8HCy1WOwl8wW5hl7QHnETMB0/pLgrj0TiJbcZwC39/Ih0fce9Qn55IWv
abThsV2tw/O9N+Rtu2L+xgmfuencN9pFtk3DPEbnYVBTXKgL3cskTXsHHAyfRdTw
4i9BWmoBxKWjfdg3HJ3S/xIKewLL2UFHuxkEs0zPUSkyXJLjTy9uYeccaXKxswDO
6hSdfPbjwjvI6lU2UC27JcRtNde2QTopO+jt0V6dRkQHgEx2Gle8tbah6x8Ecf/d
VxlkDccYjz7/srmE6ViA0iq41DXL6o7QH+dN0HPgxoOrZYmzxl8=
=wd+W
-----END PGP SIGNATURE-----

[David Hobach]

On 1/20/19 12:33 AM, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 18/01/2019 11.43 PM, thorsten...@gmail.com wrote:
>> I am also interested in having encrypted vms (preferably having one password for each VM-group).
>> Let's assume I have one or more VMs for each customer which contain sensitive data that must not leak anywhere. While working for customer 1 I want to make sure that only VMs for customer 1 are decrypted and usable (along with my non-customer VMs). VMs from customer 2,3,... should be encrypted and unaccessible at this time. When I move to cusomer 2, only these VMs should be decrypted, etc.
>>
>> My goals are:
>>
>> - In the rare case I forget to lock my notebook at cusomer 1 I don't want anyone to be able to extract other customers data. (While not perfect in regards to dom0 security at least it makes sure no data can be stolen)
>> [...]
>
> We actually have an open issue for this:
>
> https://github.com/QubesOS/qubes-issues/issues/1293
>
> (I didn't see this mentioned in your message, so you may not be aware of
> it.)

Or just encrypt all your customer A data inside a container or partition
in dom0 and attach that to the right VM on demand whilst memorizing the
respective password.

That would be ~20 lines of code or 5 min work per customer.

Anyway if your dom0 is compromised and you don't fully give up the
machine, your data is compromised as well.

[Raffaele Florio]

I'm asking apples, and you're giving me oranges. I'll explain again in what my idea is, and why I think that this naive approach is bad.

As premises you should remember that you're proposing this feature in Qubes OS, a security oriented OS. Furthermore you aren't the only user of this OS, so what it's good for you probably it's not good for others. The point is that if it's not good for others what does this feature will cause?

> IMO habits are created by persons so everyone is responsible for their own actions. If you are concerned that users may make bad decisions I think it's better to raise peoples awareness for security instead of "enforcing" things.
> You can display warnings or suggestions which assist the user, but in the end it's up to the user to decide whether it's suitable for the current case or not.
>

I partially agree.
First: I'm speaking about a scheme, more precisely a process, not simply of an user policy. My idea is a process, I'll express it somewhere below, again.
Second: every OS enforces (without quotes, they're useless in this case) a lot of things. For example, in Qubes, here are two examples:
- Backup/Restore process (again, process). Qubes isn't enforcing a policy (like backup password length), instead it enforces a backup/restore process.
- No network driver in Dom0, to support the Qubes model. (Irony: Yeah but this could be safe in various situaton, it's up to the user.. No.).
In this two way Qubes is enforcing good behavior (process), effectively it helps user to not make mistake. The same applies in this discussion. The same applies to my process idea.

Your way to handle this goals enforces bad habits :). It could be useful for 4-5 domains, but for 30 domains, for 40 domains? It's completely useless. You should have 30 passwords. (Yeah it's up to user, it's not my problem, blah blah blah). Otherwise what is the point to have different domains??
You're speaking of a security feature, in a security oriented OS, and if it's not usable in a real scenario (30 domains are really feasible, e.g. 30 customers), it should be discarded immediately. Who can remember 30 not repeatedly used passwords on Earth (also dice ware generated ones)? So unless you use bad password, you cannot. To resolve this issue you could introduce a password manager, or some other stuff. But you're generating only issues. The responsible is not the user behavior, but this approach. The user, after all has not make fault, this approach forces him/her to assume bad behavior. He/she cannot remember 30 secure passphrase. You're asking to human, inhumane qualities.
Another your proposal is VMs in multiple domains. So a lot of complexity and another bad habit, created/forced by this approach. Furthermore, handling of such monster (like: 30 domains, 70/80 VMs (potentially in multiple domains)..) will not be really fun.
(And I'm considering only issue caused by this naive approach).

> I was making a "quick" suggestion to have 1 vm-domain for each vm so you can unlock/decrypt a whole vm-domain with its specific password, since it's similar to the scripts from Joe.
> You could also add VMs to one or more VM-groups like you do with users, so you could use any VM in multiple groups/domains.
> Also for encrypting VM data we could use luks and add each vm-domains master key to it (luksAddKey), so every vm-domain password that is part of this VM can unlock that specific VM. You can also name it state or whatever you want, important is what it does.
>

Yeah, but the "state" concept is different. I'll explain again below. Furthermore you suggested, again, bad behavior, one password for all domain. Your quote here[0]. So bye bye compartmentalization. But, as I said, it's an obvious consequence. It's not your fault, you're forced by your approach to take this quick, and bad, road. It seems real flexible, but it's not possible to handle such a granular approach, in this way.

Your approach is easily and entirely simulated with encryption *in* VMs. So customer2 while in customer1 cannot access data in customerX. Your proposal isn't really different, it's a simple shift. Nothing more. Do you notice real differences? Maybe encryption *in* VMs could be more secure, thanks to various authentication technology, that the user could choose appropriately for each VMs. In Qubes this integration is, at least, more difficult to achieve. I don't want to digress. Another topic, another post..

Furthermore, I think that this granularity isn't really needed for this goal.
First: Qubes is a single user system, this approach, IIRC was also proposed to extend Qubes to a multi user system. It's not so simple or feasible, currently. (As you can see another degenerated consequence).
Second: When you're in a hostile environment you doesn't need anything else than the necessary, everytime. For example if you're at customer1 you don't need any other stuff, other than customer1 data.


*Finally* here my proposal, community please read and improve. It's, obviously, a draft.

====================================Qubes state ====================================
*Goal*: Protect user from hostile environment. This could be a hostile nation, another customer and so on. What is hostile is related to each user.
*How*: The user defines various Qubes states. Like "nation1", "customer1", "home", and so on..
- Every state defines a group of accessible VMs. The semantic is defined by the user. However take in mind that in a state the user should choose which VMs are really needed.
- Every state could be: - a paranoid state, other VMs are shreded, so they're inaccessible.
- a relaxed state, other VMs are protected with a (freshly asked) password, or some other auth scheme. Suitable for not so hostile environment.
- The user choose in which state to put his system. On a state change there are two choices:
- Paranoid restore (mandatory for paranoid state, supported for relaxed state). In a relaxed state this is useful when the laptop was left alone.
- Relaxed restore (only for relaxed state). This means that Qubes ask to authenticate, then remove the authentication. Fast. Basically it forgot it.

These are the principles. I hope the community benefits of it.
As you can see is structured, the user knows that his/her system is in a particular state. I repeat the goal. It is: protect what it's not needed in a specified environment. Practically this mean unnecessary data, nothing more. After all this is also your goal: protect unnecessary data. Qubes enforce just what VMs are accessible. Nothing more.
In this way:
- the user is aware of the risk,
- the user isn't forced to pick a quick and bad road,
- it's up to the user to choose the right behavior.
As you can see, I'm practically quoting your first quote...



[0] = <<In theory it would be also possible to use the user password for "unlocking" vm-groups>>.


Best Regards,
Raffaele.

[thorsten...@gmail.com]

> Or just encrypt all your customer A data inside a container or partition
> in dom0 and attach that to the right VM on demand whilst memorizing the
> respective password.

Something like this could work if you are using the container as a simple data storage. Unfortunately once you start working with them in any VM, data might be stored unencrypted inside this VM (temporary files, work files, swap, ...).

> As premises you should remember that you're proposing this feature in Qubes OS, a security oriented OS. Furthermore you aren't the only user of this OS, so what it's good for you probably it's not good for others. The point is that if it's not good for others what does this feature will cause?

Giving the user a way to additionaly encrypt some higher value VMs does not change anything for any user that doesn't use this feature at all. You can use it but you don't have to!

> Your way to handle this goals enforces bad habits :). It could be useful for 4-5 domains, but for 30 domains, for 40 domains? It's completely useless. You should have 30 passwords. (Yeah it's up to user, it's not my problem, blah blah blah). Otherwise what is the point to have different domains??

I'm not sure how you would have 30 or 40 vm-groups (with different threat levels) at all, let alone being active at the same time!?
You'd have to think about when this additional protection would be needed and when not. It's not like you would create a new vm-group for everything you do, is it?
So in general most of the time you are fine with the current Qubes approach, although I'd wish that all VMs were encrypted by default (volatile with a random key every boot, private with a VM specific key), just to be sure data can not leak over to other VMs somehow (hdd failure, filesystem bug, etc.).

Maybe you can give an overview of which 30-40 vm groups you would create?

The extra secure VMs (with additional key) are only for special occasions, not for being used all the time and everywhere.
Also there wouldn't be a vm-group with key for every customer, just for some rare occasions.
After the project is done, they are shredded and gone for good. At most I'd imagine having about 5 vm-groups at the same time.

> *Finally* here my proposal, community please read and improve. It's, obviously, a draft.
>
> ====================================Qubes state ====================================
> *Goal*: Protect user from hostile environment. This could be a hostile nation, another customer and so on. What is hostile is related to each user.
> *How*: The user defines various Qubes states. Like "nation1", "customer1", "home", and so on..
> - Every state defines a group of accessible VMs. The semantic is defined by the user. However take in mind that in a state the user should choose which VMs are really needed.
> - Every state could be: - a paranoid state, other VMs are shreded, so they're inaccessible.
> - a relaxed state, other VMs are protected with a (freshly asked) password, or some other auth scheme. Suitable for not so hostile environment.
> - The user choose in which state to put his system. On a state change there are two choices:
> - Paranoid restore (mandatory for paranoid state, supported for relaxed state). In a relaxed state this is useful when the laptop was left alone.
> - Relaxed restore (only for relaxed state). This means that Qubes ask to authenticate, then remove the authentication. Fast. Basically it forgot it.

I think your approach focuses on a completely different problem than what I (and others) have asked for, which is encrypted VMs.

What you describe here (paranoid state) is something you can already do with Qubes just fine. Just backup/shred until you have the "state" that you want.
(See the twitter posts from Joanna)
This might work if you only need 1 state for a longer time but it's nothing you can do during your normal (work)day where you need to switch more frequently.
You would always have to go back to your backup location (or carry them around with you) in order to being able switch to another state again.
Also remember that there are changes done in VMs so you also need to perform a backup first before shredding them and moving to another state.
It's just not feasible to spend hours to back up VMs and shredding them just to change a "state".

Which would leave the "relaxed lock mode" with simple authentication only. Needless to say that this is sort of useless since it adds no additional protection for when dom0 is compromised. You'd still need encryption to make sure the locked data is secure, which brings you back to encrypted VMs ;)

So...
I've done some quick tests on encrypting VM data under Qubes 4.0 and was able to boot and use encrypted VMs. Unfortunately some Qubes scripts seem to break things once the VMs are shut down, so after that the VM was unable to boot anymore. Haven't spent much time on this, so I'll have to get back to it whenever I have some more spare time...

[David Hobach]

On 1/20/19 9:01 PM, thorsten...@gmail.com wrote:
>> Or just encrypt all your customer A data inside a container or partition
>> in dom0 and attach that to the right VM on demand whilst memorizing the
>> respective password.
>
> Something like this could work if you are using the container as a simple data storage. Unfortunately once you start working with them in any VM, data might be stored unencrypted inside this VM (temporary files, work files, swap, ...).

Then attach the encrypted containers to disposable VMs only. Problem
100% solved.

[Raffaele Florio]

> Giving the user a way to additionaly encrypt some higher value VMs does not change anything for any user that doesn't use this feature at all. You can use it but you don't have to!
>

Sorry, what I meant isn't clear. Nonetheless the point is cleared subsequently in my previous post. I wasn't referring to the user that doesn't use the feature. It's related to the fact that you will use few domains (so it's usable), but the same feature is useless with 30 domains. As I said.

> I'm not sure how you would have 30 or 40 vm-groups (with different threat levels) at all, let alone being active at the same time!?
> You'd have to think about when this additional protection would be needed and when not. It's not like you would create a new vm-group for everything you do, is it?
> So in general most of the time you are fine with the current Qubes approach, although I'd wish that all VMs were encrypted by default (volatile with a random key every boot, private with a VM specific key), just to be sure data can not leak over to other VMs somehow (hdd failure, filesystem bug, etc.).
>
> Maybe you can give an overview of which 30-40 vm groups you would create?
>

Maybe if you read my post completely and carefully you read an example.

> The extra secure VMs (with additional key) are only for special occasions, not for being used all the time and everywhere.
> Also there wouldn't be a vm-group with key for every customer, just for some rare occasions.
> After the project is done, they are shredded and gone for good. At most I'd imagine having about 5 vm-groups at the same time.
>

<<At most I'd imagine having about 5 vm-groups at the same time.>> *Exactly.* *Exactly*. I repeat: it's good for you, but not for all. Why take your assumption as true for every Qubes user?? As I said, this feature could be used for few domains. In the majority of other case is useless. However, in my previous post I suggest that you could use encryption/authentication (etc..) *in* VMs to protect sensitive data (you'll have also more flexibility).

> I think your approach focuses on a completely different problem than what I (and others) have asked for, which is encrypted VMs.
>

Finally you're making the point. Your thesis is equal to your premise. You just want encrypted VMs. Nothing more. Not to resolve a particular issue, just encrypted VMs. And you're speaking about this feature as a godsend. Now it's clear why you've one argumentation, that is: "this is useful because this is useful".
I think that my goal is clearly stated.

> What you describe here (paranoid state) is something you can already do with Qubes just fine. Just backup/shred until you have the "state" that you want.
> (See the twitter posts from Joanna)
>
> This might work if you only need 1 state for a longer time but it's nothing you can do during your normal (work)day where you need to switch more frequently.
>

In fact a paranoid state is useful in exceptional case.

> You would always have to go back to your backup location (or carry them around with you) in order to being able switch to another state again.
> Also remember that there are changes done in VMs so you also need to perform a backup first before shredding them and moving to another state.
> It's just not feasible to spend hours to back up VMs and shredding them just to change a "state".
>

It's required only for paranoid restore. With this reply you confirmed what I said.

> Which would leave the "relaxed lock mode" with simple authentication only. Needless to say that this is sort of useless since it adds no additional protection for when dom0 is compromised. You'd still need encryption to make sure the locked data is secure, which brings you back to encrypted VMs ;)
>

Yeah, I didn't describe it clearly. I meant that VMs are protected with some auth scheme, for example: password. But, obviously, the result is used to encrypt/decrypt the VMs, not in the currently active state. So you could change state rapidly, if a paranoid restore isn't needed. And this is totally different concept, because different context.
In this way the user will change password frequently (good behavior), he/she doesn't need to remember 30 password, the user isn't forced to take quick and bad roads (like the previously mentioned degenerated model). What the user need is at his disposal, unnecessary data no. With good compartmentalization this separation is practically already done.

If it's not clear enough every idea could be improved, you seem to ignore this.

Furthermore I'm not speaking of a particular implementation because the consequence of an idea should be analyzed before. Especially in a security oriented OS, not used by two or three users. But you seem also to ignore this.
Nonetheless to support a fast relaxed state, every VMs could be encrypted, with a known key by AppVM and Dom0. When it's needed (i.e. state change) that key will be replaced accordingly. Probably Qubes data storage could be used. IIRC the first part is already here. I'll check.

However I'm annoyed to repeat the same thing various time. It also degrades this post.

Best Regards,
Raffaele.

[thorsten...@gmail.com]

> Then attach the encrypted containers to disposable VMs only. Problem 100% solved.

Sadly it's not. When you start working with files from these containers, data will eventually be written to harddrive "unencrypted" (let it be swap, temporary files, persistent work related files, ...). Once they are written to the harddrive there is always a risk of data leakage.

I found a discussion, which describes part of the problem quite good:
https://github.com/QubesOS/qubes-issues/issues/904

Also David already posted another link, which is also worth to read:
https://github.com/QubesOS/qubes-issues/issues/1293

Fortunately once DVMs are encrypted, persistent VMs can be encrypted aswell, which will eventually solve all problems.

> Yeah, I didn't describe it clearly. I meant that VMs are protected with some auth scheme, for example: password. But, obviously, the result is used to encrypt/decrypt the VMs, not in the currently active state. So you could change state rapidly, if a paranoid restore isn't needed. And this is totally different concept, because different context.
> In this way the user will change password frequently (good behavior), he/she doesn't need to remember 30 password, the user isn't forced to take quick and bad roads (like the previously mentioned degenerated model). What the user need is at his disposal, unnecessary data no. With good compartmentalization this separation is practically already done.

So at first you are against vm-encryption with the possiblity to use unique passwords since it was too hard for you to remember multiple passwords. At the same time you refused to use the same password for more than one VM.
Now you say, your "state" model also relies on ENCRYPTED VMS, which are encrypted/decrypted with ONE PASSWORD all together. *sigh*
Not gonna argue with you anymore, it's useless...

[Raffaele Florio]

> So at first you are against vm-encryption with the possiblity to use unique passwords since it was too hard for you to remember multiple passwords. At the same time you refused to use the same password for more than one VM.

> Now you say, your "state" model also relies on ENCRYPTED VMS, which are encrypted/decrypted with ONE PASSWORD all together. sigh

> Not gonna argue with you anymore, it's useless...
>

I'm saying a *totally* different thing. Furthermore you ignored *every* cons that I exposed. Then you are trivializing the discussion. Yes, it's useless.


If someone didn't understand my points, I'm here to clarify.


Happy hacking to all,
Raffaele.

[Chris Laprise]

I'd just like to remind people (again) that Qubes has a storage pool
feature. So it IS possible to encrypt VMs with different encryption
keys. It requires some initiative from the user to set it up, however,
to define the pools so they reside in encrypted volumes.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket

[Josh Skipper]

I'd just like to remind people (again) that Qubes has a storage pool
feature. So it IS possible to encrypt VMs with different encryption
keys. It requires some initiative from the user to set it up, however,
to define the pools so they reside in encrypted volumes.

While I was looking for a way to individually encrypt VMs with a unique password, I stumbled upon this thread.

I did some tests with storage pools and there seems to be a major drawback.

As I understand, you have to create a new encrypted storage pool with fixed size for every VM you want to protect individually.

So basically this defeats the advantage of the thin pool, where each VM can dynamically use as much space as needed, while having a maximum much larger than when is needed or even available.

I thought about a ways to actually get this to work, but the problem is, if I set the pool size too low, I will run into bigger problems later on where an expansion would be needed. Is this even possible if the hdd space before and after is already assigned to other pools which can not be shrinked?

So to be sure you'd have to assign more than enough space, eating up the hdd space very fast, leading to not enough space for all VMs.

Do I miss something here? If not, is there a better way to encrypt each VM individually while still using only the default pool (qubes_dom0/pool00)?

I tried to replace the VMs private LVs with an encrypted equivalent, but this did not work. To be precise, I replaced them with an opened luks volume. The volume can be mounted and used but QubesOS did not like it at all, the VMs did not start with this setup.

I guess there are modifications in QubesOS itself needed in order to do so?

[John Smiley]

Is a long, correctly generated (with actual dice using paper and pencil - no electronic copies ever) Diceware password entered at boot-time not sufficient?  If not, why not?  

--

You received this message because you are subscribed to the Google Groups "qubes-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20583f92-78e6-4e9c-9a85-c6b4656e617f%40googlegroups.com.

[bo0od]

I think its a good idea for e.g like:

- Multiple PC users, each user want to use the PC but not each user want
to give permissions to view all vms

- If by any how someone knew the passphrase for the Qubes and opened it
, at least he cant damage all vms because some (which are the important
i suppose) will request a password to delete or to enter it

...

So its something beneficial

John Smiley:

>> <https://groups.google.com/d/msgid/qubes-devel/20583f92-78e6-4e9c-9a85-c6b4656e617f%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Oct 22, 2019 at 05:59:00AM +0000, bo0od wrote:
> John Smiley:

> > On Fri, Oct 18, 2019 at 9:27 PM Josh Skipper <josh7...@gmail.com> wrote:
> >> While I was looking for a way to individually encrypt VMs with a unique
> >> password, I stumbled upon this thread.
> >> I did some tests with storage pools and there seems to be a major drawback.
> >> As I understand, you have to create a new encrypted storage pool with
> >> fixed size for every VM you want to protect individually.
> >> So basically this defeats the advantage of the thin pool, where each VM
> >> can dynamically use as much space as needed, while having a maximum much
> >> larger than when is needed or even available.
> >> I thought about a ways to actually get this to work, but the problem is,
> >> if I set the pool size too low, I will run into bigger problems later on
> >> where an expansion would be needed. Is this even possible if the hdd space
> >> before and after is already assigned to other pools which can not be
> >> shrinked?
> >> So to be sure you'd have to assign more than enough space, eating up the
> >> hdd space very fast, leading to not enough space for all VMs.
> >>
> >> Do I miss something here? If not, is there a better way to encrypt each VM
> >> individually while still using only the default pool (qubes_dom0/pool00)?
> >> I tried to replace the VMs private LVs with an encrypted equivalent, but
> >> this did not work. To be precise, I replaced them with an opened luks
> >> volume. The volume can be mounted and used but QubesOS did not like it at
> >> all, the VMs did not start with this setup.
> >> I guess there are modifications in QubesOS itself needed in order to do so?
> >

> > Is a long, correctly generated (with actual dice using paper and pencil -
> > no electronic copies ever) Diceware password entered at boot-time not
> > sufficient? If not, why not?
> >

> I think its a good idea for e.g like:
>
> - Multiple PC users, each user want to use the PC but not each user want
> to give permissions to view all vms

Generally, is someone have access to dom0, can do almost arbitrary
changes - in the current version there is no way to stop them from for
example removing/damaging qubes or modifying qubes that are shared, like
sys-net or maybe templates.
See here for details:
https://www.qubes-os.org/faq/#is-qubes-a-multi-user-system

> - If by any how someone knew the passphrase for the Qubes and opened it
> , at least he cant damage all vms because some (which are the important
> i suppose) will request a password to delete or to enter it

Encryption won't stop anyone from damaging the data. But can stop from
reading them.

Per-vm encryption has two primary use cases:
- preventing access to selected (powered off) qubes even if someone
obtains access to dom0 (either by accessing running system, or
obtaining disk passphrase)
- more reliable removing qubes - make sure the removed data cannot be
recovered from the disk with forensics tools (and knowledge of disk
passphrase)

See here for details:
https://github.com/QubesOS/qubes-issues/issues/1293

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl2u304ACgkQ24/THMrX
1yxOXwf+LAsApzirQDacJkOE1SzfZCJMMocChhnxY1ggqvc2B7uCJjhjSOTrg9iM
cYcM4d2MMLs4xheRvJnuICYX6L+gqJkaeJtsipD0zNrTYMuYP8nXKj3rvuDptFDi
LEKnTUTA2VNvkporH+PFog8/kCSVvqKttuGloE0Oaqi9LVUCR/W5gndGjPOSrGnM
zpcqIQsRsOyMftzUftxcZ4IkWFR6vHwUu05CIFP40VTMAcDsYb3/ShrPHZf0rq2H
rNiuSGcfbtdct0SjZi99wBcoYAlkrSoCCC1aPDCrqxiKIgJfH4rLqMxJK7GaPYyG
Cwbwo7uE8xC7H6dq8+kHD3Nrhhlthw==
=rDT3
-----END PGP SIGNATURE-----