-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, Oct 22, 2019 at 05:59:00AM +, bo0od wrote:
> John Smiley:
> > On Fri, Oct 18, 2019 at 9:27 PM Josh Skipper wrote:
> >> While I was looking for a way to individually encrypt VMs with a unique
> >> password, I stumbled upon this thread.
>
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
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?
On Fri, Oct 18, 2019 at 9:27 PM Josh Skipper wrote:
>
>> I'd just like to remind people (again) that Qubes has a storage
>
>
> 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
> 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
> 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
On 1/20/19 9:01 PM, thorsten.schie...@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
> 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
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
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.schie...@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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 18/01/2019 11.43 PM, thorsten.schie...@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
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
> 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
> 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
> 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
> 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
> - 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
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
18 matches
Mail list logo
