--
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.
--
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.
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?
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)
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).
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
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...
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...
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.
--
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.