> 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) -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/41354289-4ba0-4e28-8d82-49e368f970a9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
