> 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). -- 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/8392c8b9-cb53-412d-802a-181de24f65ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
