What's your system layout like?

General Discussion
1

I enjoy reading posts where people discuss their system layouts and rationales, so after reading @Sean 's post (linked below) on my other thread, I decided to create a thread for this.

Don’t forget to create a new account and scramble your language if you want to be really anonymous, but don’t forget the security principle stating that a truly secure system is one that an adversary is unable to penetrate even after having full access to all schematics (it has a name, but I forgot it).

 

Here’s another post by user ‘qubesuser01’ on a Reddit thread which is basically identical to this one:

I have some issues finding the perfect layout myself to be honest.

Let me share what I have anyway. You might be inspired.

I usually clone an existing templateVM that I will then use as the base for my other VMs. I recently moved over to a full fedora setup (too many issues with debian and software versions imo).

So I have a templateVM (call it private) cloned from fedora-30. In this templateVM I install general purpose tools/software that I am using generically and in most setups (Firefox, Chrome, LibreOffice, etc).

Then I have appVMs based on this. So I have one for personal use, that I use for email and other services where I am logged in. Will probably also use this for chat etc.

Then I have one for some voluntary work I am doing, where I am logged in to the mail service they have, and generally have a couple of documents and generic office related work.

I have a vault app VM that basically just holds different important files (keepass database, ssh keys and so on). This is airgapped

I have a standalone media VM where I have spotify installed and mpv. Don’t trust media files in general, so I just isolate them here.

I have a standalone VM for software development, where I have installed my editor, favourite terminal emulator, and toolchains for development language I code in and so on.

I also have a standalone VM for hacking purposes (I am getting into the field of IT security).

So to sum up:

Templates

  • 1 private, based on a given templateVM (in my case fedora-30)
    • Has generic all around multi-purpose tools (based on your use case, you can minimise this, stick to software that you deem trustworthy, etc)

AppVMs

  • personal - based on private - logged in to mail, used for chat (whatsapp, telegram, discord)
  • voluntary - based on private - logged in to specific mail account, used for generic office work
  • vault - based on private - airgapped, used to hold different sensitive files

Standalone

  • development - based on private - installed specific software for development (favourite text editor, favourite terminal emulator, language toolchains, etc)
  • media - based on private - installed spotify, mpv, gimp, generally used for everything media related
  • hack - based on private - used for testing different tools, playing with reverse engineering and generally just trying to get into the field

Sorry for the wall of text, hope you can use though :slight_smile:

 

My setup is simple and vanilla compared to those above–I have disposable sysVMs running on minimal templates with the absolute bare minimum installed for the roles. Then I have multiple mirage firewalls–one gating sys-net and the other gating my tor/VPN VMs. Then I have a bunch of appVMs.

I’m still relatively new to Qubes so I haven’t started using it for much more other than casual browsing and downloading, so my appVMs are basically Whonix, browsers, and torrenting. Whatever functions don’t need to be done online (e.g. opening videos) are done in specialized offline VMs.

2 Likes
2

Kerckhoffs’s principle

5 Likes
3

‘Kerckhoff’ doesn’t exactly roll off the tongue so it’s hard to remember (like Czech names). I’m just going to remember it as ‘Kermit’s Principle’. Hope Kerckhoff doesn’t roll too hard in his grave.

Thanks though

4

:joy:

5

I am not sure that word “layout” is appropriate here. It sounds related to graphical interface, so I did not expect to see the users explain their setups here. Maybe a change in the title could bring more people to this topic? I suggest “How are you using Qubes OS?”.

6

My use case is considerably more simple than what is discussed here, but I thought that it might be useful for someone, too. I am not a security specialist or an IT guy. Still Qubes OS also made me reconsider how I use my computer and the Internet in a good way, added structure to my thinking about the workflows. The implemented separation of domains helps my thinking tremendously.

I decided to use as few VMs as possible while having a much more secure workflow than everyone around me ever had, but still trying to decrease my cognitive load. “Reasonably secure” is a perfect phrase which means a different thing for everyone; and Qubes actually allows to adjust its configuration accordingly!

I have just two offline qubes: vault and personal-arxiv, where the first one keeps all the passwords and the second one contains all private documents, music, videos and photos. Even if something gets compromised, it technically cannot go online, so I decided that it’s already good enough for me.

I have just two qubes with the standard Internet access. One named work for everything work-related, including web browsing (with Noscript and Privacy Badger), emails and documents. Another one is a qube named personal exclusively used for personal emails and online banking (with Noscript and Privacy Badger). Links in the emails are automatically opened in a disposable qube. These qubes are based on a Debian template.

There is a separate qube inet for Telegram instant messaging (connected via tor to hide my IP from the server). Links in the chats are automatically opened in a disposable qube. Now that I have a Pinephone, I decided that its security domain will coincide with this qube inet, so I occasionally do browsing there with Noscript. Pinephone, by the way, allows to boot from a microSD card, so you can have “random browsing domain” when booted from internal memory and “instant messaging domain” when the card is inserted.

I also have independent qubes for Skype (via tor) and Zoom.

Now, there are many other things one does in the Internet which do not belong to the qubes listed above and I do most of them in Disposable qubes. For shopping, I open the website, choose what I want to buy and then close the qube, destroying it. Actual purchase is done in a second disposable qube to prevent their tracking of my initial search. Random internet browsing, news reading, Google translate (and deepl.com translate) are all done in many disposable qubes which get created and destroyed all the time (but mostly when I reboot). I have two disposable VM templates, Fedora and Debian, which I use interchangeably. There is no history of my web browsing anywhere. If I want to save some website or download a file, it goes to personal-arxiv qube (via “send to VM”).

So I have “just” 7 qubes not counting the system ones and templates.

7

You setup sounds very reasonable! I can confirm that less is more. Having too many domains just creates a and leads to compartmentalization screw-ups.

It seems that the thread is diverging a bit from it’s intended purpose. Maybe the thread What's your system layout like? could be more appropriate (@fsflover do you mind if I move your post there?)

I was going to bring up the issue of fingerprinting on your Disposable qubes setup because the default firefox doesn’t give that sort of protection, but it seems you already asked yourself the same question :slight_smile:

8

Sure, do it if you decide it’s better. I was just thinking that sometimes people use too many qubes, like shopping ones or translation ones, while (I think) it does not provide any additional security or convenience, so in some way my usage of disposable qubes for everything is non-standard. But most of the details still do not belong here.

9

Unfortunately, in the current state of things, this is technically not true. Due to the existence of many covert channels, even a VM with no NetVM is not completely leak-proof.

However, I think such attacks would generally be considered “advanced,” so the existing protection may be good enough for many people.

3 Likes
10

I agree with this. Maybe this is the reason why this thread hasn’t had much attention. @fiftyfourthparallel

11

Thank you for the information! Can I read more about it? Do you mean the exchange of files with a comprimised qube could lead to a covert channel? Does it help if I never let any files out?

Another problem is probably connecting USB devices to this VM (even through sys-usb). Does it help when I only connect my devices to (disposable) sys-usb and transfer files exclusively via “copy to VM”?

And indeed, even if I am not protected from those things, it is still a much higher protection than any typical OS, which feels great.

12

My general policy (for what it’s worth) is if it’s that valuable or mission-critical, it shouldn’t be on a networked computer. Period.

Complete air-gapping allows for a much smaller attack surface and a larger degree of certainty. With virtualization-gapping, you open yourself many more unknown-unknowns–on top of the known-knowns like Spectre and Rowhammer.

I’m not really familiar with the terminology. I call it a ‘layout’ because in my mind the VMs are connected like a flow chart, with nodes and links. @fsflover “How are you using Qubes OS” sounds too vague to me–the thread might get diverted to discussing what tasks are performed on Qubes, which isn’t really what I’m interested in. However, that’s just my perspective, and I’m probably not representative of the userbase. I’m open to changing the title if there’s a consensus that the term ‘layout’ is misleading to the userbase.

This thread not gaining much attention might also because Qubes users tend to be cautious, which means there’s a natural reluctance to post details about their systems’ operations. On top of that, this is a copy of the Reddit thread linked above.

2 Likes
13

Not necessarily: https://invisiblethingslab.com/resources/2014/Software_compartmentalization_vs_physical_separation.pdf

Fair enough, but I also suggested word “setup”. For example: “How did you setup your Qubes?”. Alternatively, one could use something like “Which qubes did you create?”.

It could of course be the reason, but I personally missed this thread due to its name, so we have at least one data point…

2 Likes
14

An example of a cooperative covert channel in Qubes would be abusing the CPU cache to exfiltrate data from an offline VM via a network-connected VM (e.g., sys-net). This is different from the scenarios you describe, though the scenarios you describe are additional ways that data exfiltration could occur.

You can read more here:

Also mentioned in:

Indeed, it makes such attacks more difficult and requires a higher level of skill from the attacker. Nothing is ever 100% secure, so making attacks more costly is pretty much the best you can do.

I was about to link to the same paper. :slightly_smiling_face:

Physical air gaps are not always superior! For certain use cases (particularly those mentioned in the paper), Qubes compartmentalization is arguably be more secure.

Of course, the converse is also true: There are certain use cases for which physical air gaps are more secure. The point is that it’s situational an depends on many factors. One is not always better than the other.

2 Likes
15

It’s true. Even something like posting a screenshot of your dom0 desktop (without any confidential data in view) could be used to launch an attack against you, since knowing exactly what your dom0 desktop looks like might allow an attacker to take over a VM with fullscreen permissions to create a convincing simulation of your dom0 within that VM, inducing you to perform sensitive actions like entering passphrases.

Of course, such an attack should be easy to thwart by using a protected shortcut like alt+tab, so going to such great effort is unlikely to be worth it (unless the attacker somehow knows that you rarely use protected shortcuts).

2 Likes
16

Ok, but (returning to my original point of having just one offline qube for everything) how having multiple offline qubes could help here? Perhaps only switched off/paused qubes are safe in this case, but whenever you switch them on, you’re screwed.

17

It could help if one offline VM gets compromised while the other doesn’t. Data exfiltration would be limited to the compromised VM (unless the attacker chains it with another attack).

18

Yes, powered off VMs usually cannot attack you via side channels. That’s the idea of qidle [1].

Anyway you’ll have sys-net et al constantly running which makes them prime targets for such attacks. Making them disposable helps a bit at least.

[1] [I am not allowed to post the github link. o_O]

1 Like
19

ed on my very limited knowledge). At least, it’d tide us over until someone bothers to make an ethernet unikernel.

Further discussion:

 

I see the concerns, but since nothing as specific as a screenshot of dom0 is needed, Kermit’s Law should be a good enough assurance. If an attacker has enough information about your system (across many VMs) to identify you from some details given here, then you have much bigger problems that not posting wouldn’t have prevented.

download

Pictured: Kermit’s Law

And @fslover I see the argument, especially since BadUSB is a massive issue (though USB isn’t the only means of data transfer)–but considering the unknown unknowns, physical airgapping just makes me feel safer. It’s this big baby’s security blanket, if you will. Or maybe that should refer to the faraday blanket wrapped around the computer.

1 Like
20

Oh dear. :joy:

It’s exactly the opposite.

Physical air gaps require you to transfer files via USB (or less convenient methods) rather than secure qvm-copy/move. BadUSB is a big problem. Therefore, qvm-copy/move has the security advantage over physical USB sneakernet. The attack surface of qvm-copy/move is incredibly minuscule compared to plugging the same USB drive into multiple conventional physical machines. This is a point in favor of Qubes over physical air gaps.

2 Likes