> 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. -- 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/yqjz0nbQlkPjORfC7TJQ1-OoMvMWYWD3onLlpaxdzeIdLYTwMXyJ_1NAztCLDTQQIWA0Nm6jXz6qFkOkgND2hWB39S2ISSanbgsVCPmlJ_k%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
