Qubes Structure

[xao]

Hi! 

Sorry for the bad question structure, don't know how to write it properly.

I've seen some examples of how people setup their system and the most paranoid ones create separate standalone vm for each application and firewall that allows only this application to connect to the internet.

Currently, I have 4 template vms - debian 10 with all programs I use installed in it, fedora 30 minimal for netvms, and whonix templates. All my vms that I use on day to day basis are made with debian template. After seeing all those setups I feel that my system is an open garden for hackers and they can do whatever they want, and I will find it out only after I get completely hacked.

So, my question is how to setup your system for maximum security? Is there any guidelines on how to do so?

I understand that it may be a silly question because it mostly depends on from whom I protect myself, but let's imagine I need to protect from everyone.

I would appretiate any advice on how to improve my system's security or where to look for the information.

Thanks for reading and have a nice day!

Some examples of people's setups:

1. https://www.reddit.com/r/Qubes/comments/eevf02/whats_your_user_setup_i_love_reading_about_how/fbxybtk/

2. https://old.reddit.com/r/privacytoolsIO/comments/dq8haz/iyho_firefox_vs_tor_vs_brave_for_browser_selfhost/f6192p4/

3. https://github.com/Qubes-Community/Contents/tree/master/docs/user-setups

[tetra...@danwin1210.me]

On Sun, Dec 29, 2019 at 10:56:31AM +0100, xao wrote:
>Hi! 
>
>Sorry for the bad question structure, don't know how to write it properly.
>
>I've seen some examples of how people setup their system and the most paranoid ones create separate standalone vm for each application and firewall that allows only this application to connect to the internet.
>
>Currently, I have 4 template vms - debian 10 with all programs I use installed in it, fedora 30 minimal for netvms, and whonix templates. All my vms that I use on day to day basis are made with debian template. After seeing all those setups I feel that my system is an open garden for hackers and they can do whatever they want, and I will find it out only after I get completely hacked.
>
>So, my question is how to setup your system for maximum security? Is there any guidelines on how to do so?
>
>I understand that it may be a silly question because it mostly depends on from whom I protect myself, but let's imagine I need to protect from everyone.

If you need to protect from everyone then you should turn your computer
off, lock it in a vault, embed the vault in a block of solid concrete,
bury the whole mess at the bottom of a mine, and post an armed guard at
the door. Then you *may* be safe.

Ultimately your security is not the product of some "setup" but of the
degree to which you understand how your setup works and what the
implications are of the choices that you make.

If you understand very little, then the most paranoid of setups will get
you very little in terms of security, because you will end up making
choices that compromise that security -- or you will just end up wasting
a great deal of time on things that don't matter.

If you need security but don't understand computers, avoid using
computers!

[xao]

>If you understand very little, then the most paranoid of setups will get 
you very little in terms of security, because you will end up making 
choices that compromise that security -- or you will just end up wasting a great deal of time on things that don't matter. 

I do have some experience in computers and cybersecurity, and I want to know more. I came here to find more information about qubes architeturing; get the most out of it.

If you can provide some links or advice that help me to make better qubes setup, I would be thankful to you.

[Franz]

Look at this link

https://www.qubes-os.org/doc/security-guidelines/

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/16f551a47ee.d18df96243681.4660457132775699060%40privacy.com.co.

[xao]

Don't know how I missed this link before, but after reading it, things got much clear. Thank you!

[brenda...@gmail.com]

On Monday, December 30, 2019 at 6:25:03 AM UTC-5, xao wrote:

Don't know how I missed this link before, but after reading it, things got much clear. Thank you!

One important tenet of Qubes is that the security focus is primarily protecting you from cross-domain (cross-VM) disclosure or exposure. However, anything within a particular VM/domain is about as vulnerable as a typical linux system.

Hence, why Qubes requires a certain amount of self-discipline even for basic use cases.

In addition some folks extend that a bit and utilize Qubes further to separate "personae" from eachother, sometimes routing each through different VPNs.

Banking VM only for banking; job1 VM only for day job; ...and superhero domain only for your alternate crime-fighting identity, etc.

In addition, as soon as one starts customizing templates, fingerprinting during a breach becomes easier, to the point where a breach in two VMs can end up cross-correlating personae in two VMs even if they connect to the internet differently.

That's why question #0 is: what are your specific threat concerns? Question 1 is: how will you mitigate them? Mitigations *begin* with behavior, not technology. Technologies just assist with/automate the behavior.

Lastly, one assumption that comes up a lot is that disposable VMs are amnesiac. They are not (currently anyway*). The data written to the disposable VM is unlinked when the disposable VM volumes are removed but they are not explicitly erased from storage (though may be overwritten over time). Why? The primary intent of disposable VMs was to prevent propagation of malware from dodgy files or dodgy websites or targeted attacks. The intent was NOT to prevent forensic recovery of data from shut-down disposable VMs.*

B

* though, that would be a nice feature. there are some baby steps happening now (e.g. blkdiscard is now run across the volumes before unlinking them, which may end up being opportunistically anti-forensic on *some* hardware if trim is enabled all the way down through the storage stack).