New user guide: How to organize your qubes

The following is a new how-to guide for users who are starting out with Qubes OS. You can also find it in our documentation under How to organize your qubes.

When people first learn about Qubes OS, their initial reaction is often, “Wow, this looks really cool! But… what can I actually do with it?” It’s not always obvious which qubes you should create, what you should do in each one, and whether your organizational ideas makes sense from a security or usage perspective.

Each qube is essentially a secure compartment, and you can create as many of them as you like and connect them to each other in various ways. They’re sort of like Lego blocks in the sense that you can build whatever you want. But if you’re not sure what to build, then this open-ended freedom can be daunting. It’s a bit like staring at a blank document when you first sit down to write something. The possibilities are endless, and you may not know where to begin!

The truth is that no one else can tell you exactly how you should organize your qubes, as there is no single correct answer to that question. It depends on your needs, desires, and preferences. Every user’s optimal setup will be different. However, what we can do is provide you with some illustrative examples based on questionnaires and interviews with Qubes users and developers, as well as our own personal experience and insight from using Qubes over the years. You may be able to adapt some of these examples to fit your own unique situation. More importantly, walking you through the rationale behind various decisions will teach you how to apply the same thought process to your own organizational decisions. Let’s begin!

Alice, the software developer

Alice is a freelance dev who works on several projects for different clients simultaneously. The projects have varying requirements and often different build environments. She has a separate set of qubes for each project. She keeps them organized by coming up with a naming scheme, such as:

clientA-code
clientA-build
clientA-test
clientA-prod
projectB-code
projectB-build-test
projectB-prod
...

This helps her keep groups of qubes organized in a set. Some of her qubes are based on Debian templates, while others are based on Fedora templates. The reason for this is that some software packages are more readily available in one distribution as opposed to the other. Alice’s setup looks like this:

Alice's system: diagram 1

  • Several qubes for writing code. Here’s where she runs her IDE, commits code, and signs her commits. These qubes are based on different templates depending on which tools and which development environment she needs. In general, Alice likes to have a separate qube of this type for each client or each project. This allows her to keep everything organized and avoid accidentally mixing up any access credentials or client code, which could be disastrous. This also allows her to truthfully tell her clients that their code is always securely isolated from all her other clients. She likes to use the Qubes firewall to restrict these qubes’ network access to only the code repositories she needs in that qube in order to avoid accidentally interacting with anything else on her local network or on the internet. Alice also has some qubes of this type for personal programming projects that she works on just for fun when she has “free time” (whatever that is).

  • Several qubes for building and testing. Again, Alice usually likes to have one of these for each client or project in order to keep things organized. However, this can become rather cumbersome and memory-intensive when many such qubes are running at the same time, so Alice will sometimes use the same qube for building and testing, or for multiple projects that require the same environment, when she decides that the marginal benefits of extra compartmentalization aren’t worth the trouble. Here’s where she pulls any dependencies she needs, compiles her code, runs her build toolchain, and tests her deliverables. In some cases, she finds it useful to use standalones for these so that it’s easier to quickly install different pieces of software without having to juggle rebooting both the template and an app qube. She also sometimes finds it necessary (or just convenient) to make edits to config files in the root filesystem, and she’d rather not have to worry about losing those changes during an app qube reboot. She knows that she could use bind-dirs to make those changes persistent, but sometimes she doesn’t want to get bogged down doing with all that and figures it wouldn’t be worth it just for this one qube. She’s secretly glad that Qubes OS doesn’t judge her this and just gives her the freedom to do things however she likes while keeping everything securely compartmentalized. At times like these, she takes comfort in knowing that things can be messy and disorganized within a qube while her overall digital life remains well-organized.

Alice's system: diagram 2

  • Several email qubes. Since Alice is a command-line aficionado, she likes to use a terminal-based email client, so both her work and personal email qubes are based on a template with Mutt installed. The email qubes where she sends and receives PGP-signed and encrypted email securely accesses the private keys in her PGP backend qube (more on that below). To guard against malicious attachments, she configured Mutt to open all attachment files in disposable qubes.

  • Several qubes for communication tools, like Signal, Slack, Zoom, Telegram, IRC, and Discord. This is where she teleconferences and chats with clients. She uses USB passthrough to attach her webcam to each qube as needed and detaches it afterward. Likewise, she gives each qube access to her microphone while it’s needed, then removes access afterward. This way, she doesn’t have to trust any given video chat program’s mute button and doesn’t have to worry about being spied on when she’s not on a call. She also has a qube for social media platforms like Twitter, Reddit, and Hacker News for networking and keeping up with new developments (or so she claims; in reality, it’s mostly for feuds over programming language superiority, Vim vs. Emacs wars, and tabs vs. spaces crusades).

  • A GPG backend vault. Vaults are completely offline qubes that are isolated from the network. This particular vault holds Alice’s private keys (e.g., for code signing and email) and is securely accessed by several other “frontend” qubes via the Split GPG system. Split GPG allows only the frontend qubes that Alice explicitly authorizes to have the ability to request PGP operations (e.g., signing and encryption) in the backend vault. Even then, no qube ever has direct access to Alice’s private keys except the backend vault itself.

  • A password manager vault. This is another completely offline, network-isolated qube where Alice uses her offline password manager, KeePassXC, to store all of her usernames and passwords. She uses the secure copy and paste system to quickly copy credentials into other qubes whenever she needs to log into anything.

  • Personal qubes. One of the things Alice loves the most about Qubes is that she can use it for both work and personal stuff without having to worry about cross-contamination. Accordingly, she has several qubes that pertain to her personal life. For example, she has an offline vault that holds her medical documents, test results, and vaccination records. She has another offline vault for her government documents, birth certificate, scans of her passport, and so on. She also has some personal social media accounts in a separate qube for keeping up with family members and friends from school.

When she finishes her work for a given client, Alice sends off her deliverables, backs up the qubes containing the work for that client, and deletes them from her system. If she ever needs those qubes again or just wants to reference them, she can easily restore them from her backup, and the internal state of each one will be exactly as it was when she finished that project.

Bob, the investigative journalist

As part of his research and reporting, Bob is frequently forced to interact with suspicious files, often from anonymous sources. For example, he may receive an email with an attachment that claims to be a tip about a story he’s working on. Of course, he knows that it could just as easily be malware intended to infect his computer. Qubes OS is essential for Bob, since it allows him to handle all this suspicious data securely, keeping it compartmentalized so that it doesn’t risk infecting the rest of his machine.

Bob isn’t a super technical guy. He prefers to keep his tools simple so he can focus on what’s important to him: uncovering the truth, exposing the guilty, exonerating the innocent, and shining light on the dark corners of society. His mind doesn’t naturally gravitate to the technical details of how his computer works, but he’s aware that people are getting hacked all the time and that the nature of his work might make him a target. He wants to protect his sources, his colleagues, his family, and himself; and he understands that computer security is an important part of that. He has a Qubes laptop that he uses only for work, which contains:

A diagram of Bob's system

  • One offline qube for writing. It runs only LibreOffice Writer. This is where Bob does all of his writing. This window is usually open side-by-side with another window containing research or material from a source.

  • Multiple email qubes. One is for receiving emails from the general public. Another is for emailing his editor and colleagues. Both are based on a minimal template with Thunderbird installed. He’s configured both to open all attachments in disposables that are offline in case an attachment contains a beacon that tries to phone home.

  • Whonix qubes. He has the standard sys-whonix service qube for providing Torified network access, and he uses disposable anon-workstation app qubes for using Tor Browser to do research on stories he’s writing. Since the topic is often of a sensitive nature and might implicate powerful individuals, it’s important that he be able to conduct this research with a degree of anonymity. He doesn’t want the subjects of his investigation to know that he’s looking into them. He also doesn’t want his network requests being traced back to his work or home IP addresses. Whonix helps with both of these concerns. He also has another Whonix-based disposable template for receiving tips anonymously via Tor, since some high-risk whistleblowers he’s interacted with have said that they can’t take a chance with any other form of communication.

  • Two qubes for Signal. Bob has two Signal app qubes (both on the same template in which the Signal desktop app is installed). One is linked to his own mobile number for communicating with co-workers and other known, trusted contacts. The other is a public number that serves as an additional way for sources to reach him confidentially. This is especially useful for individuals who don’t use Tor but for whom unencrypted communication could be dangerous.

  • Several data vaults. When someone sends Bob material that turns out to be useful, or when he comes across useful material while doing his own research, he stores a copy in a completely offline, network-isolated vault qube. Most of these files are PDFs and images, though some are audio files, videos, and text files. Since most of them are from unknown or untrusted sources, Bob isn’t sure if it would be safe to put them all in the same vault, so he makes different vaults (usually one for each story or topic) just in case. This has the side benefit of helping to keep things organized.

  • A VPN qube and associated qubes for accessing work resources. The servers at work can only be accessed from the organization’s network, so Bob has certain qubes that are connected to a VPN qube so that he can upload his work and access anything he needs on the local network when he’s not physically there.

  • A password manager vault. Bob stores all of his login credentials in the default password manager that came with his offline vault qube. He securely copies and pastes them into other qubes as needed.

A colleague helped Bob set up his Qubes system initially and showed him how to use it. Since Bob’s workflow is pretty consistent and straightforward, the way his qubes are organized doesn’t change much, and this is just fine by him. His colleague told him to remember a few simple rules: Don’t copy or move text or files from less trusted to more trusted qubes; update your system when prompted; and make regular backups. Bob doesn’t have the need to try out new software or tweak any settings, so he can do everything he needs to do on a daily basis without having to interact with the command line.

Carol, the investor

Carol works hard and lives below her means so that she can save money and invest it for her future. She hopes to become financially independent and maybe even retire early someday, and she’s decided that her best bet for achieving this is by investing for the long term and allow compounding to do its work. However, after doing some research into her country’s consumer financial protection laws, she learned that there’s no legal guarantee that customers will be made whole in the event of theft or fraud. The various insurance and protection organizations only guarantee recovery in the case of a financial institution failing, which is quite different from an individual customer being hacked. Moreover, even though many financial institutions have their own cybercrime policies, rarely, if ever, do they explicitly guarantee reimbursement in the event that a customer gets hacked (rather than the institution itself).

After learning about all this, Carol decided that it was ultimately up to her to take care of her own cybersecurity. She couldn’t rely on anyone else to do it for her. Sure, most people just use regular consumer tech and will probably end up fine, but, she reminded herself, most people also don’t have as much to lose. It’s not a risk that she was willing to take with her future, especially knowing that there’s probably no government bailout waiting for her and that all the brokerage firms’ vaguely reassuring marketing language about cybersecurity isn’t legally binding. So, Carol started reading more about computer security and eventually stumbled upon Qubes OS after searching the web for “most secure operating system.” She read about how it’s designed and why. Although she didn’t immediately understand all of the technical details, the fundamental principle of security-by-compartmentalization made intuitive sense to her, and the more she learned about the technical aspects, the more she realized that this is what she’d been looking for. Today, her setup looks like this:

A diagram of Carol's system

  • One qube for each investment firm and bank. Carol has a few different retirement accounts, brokerage accounts, and bank accounts. She treats each qube like a “secure terminal” for accessing only that one institution’s website. She makes her transactions and saves any statements and confirmations she downloads in that qube. She uses the Qubes firewall to enable access only to that institution’s website in that qube so that she doesn’t accidentally visit any others. Since most of what she does involves using websites and PDFs, most of Carol’s app qubes are based on a minimal template with just a web browser (which doubles as a PDF viewer) and a file manager installed.

  • One qube for all her credit card accounts. Carol started to make a separate qube for each credit card account but ultimately decided against it. For one thing, the consumer protections for credit card fraud in her country are much better than for losing assets to theft or fraud in a bank or brokerage account, so the security risk isn’t as high. Second, there’s actually not a whole lot that an attacker could do with access to her credit cards’ online accounts or her old credit card statements, since online access to these generally doesn’t allow spending or withdrawing any money. So, even the worst case scenario here wouldn’t be catastrophic, unlike with her bank and brokerage accounts. Third, she’s not too worried about any of her credit card company websites being used to attach each other or her qube (As long as it’s contained to a single qube, she’s fine with that level of risk.) Last, but not least: She has way too many credit cards! While Carol is very frugal, she likes to collect the sign-up bonuses that are offered for opening new cards, so she’s accumulated quite a few of them. (However, she’s always careful to pay off her balance each month, so she never pays interest. She’s also pretty disciplined about only spending what she would have spent anyway and not being tempted to spend more just to meet a spending requirement or because she can.) At any rate, Carol has decided that the tiny benefit she stands to gain from having a separate qube for every credit card website wouldn’t be worth the hassle of having to manage so many extra qubes.

  • A qube for credit monitoring, credit reports, and credit history services. Carol has worked hard to build up a good credit score, and she’s concerned about identity theft, so she has one qube dedicated to managing her free credit monitoring services and downloading her free annual credit reports.

  • Two qubes for taxes. Carol has a Windows qube for running her Windows-only tax software. She also has an offline vault where she stores all of her tax-related forms and documents, organized by year.

  • A qube for financial planning and tracking. Carol loves spreadsheets, so this offline qube is where she maintains a master spreadsheet to track all of her investments and her savings rate. She also keeps her budgeting spreadsheet, insurance spreadsheet, and written investment policy statement here. This qube is based on a template with some additional productivity software, like LibreOffice and Gnumeric (so that Carol can run her own Monte Carlo simulations).

  • Various email qubes. Carol likes to have one email qube for her most important financial accounts; a separate one for her credit cards accounts, online shopping accounts, and insurance companies; and another one for personal email. They’re all based on the same template with Thunderbird installed.

  • A password manager vault. A network-isolated qube where Carol stores all of her account usernames and passwords in KeePassXC. She uses the Qubes global clipboard to copy and paste them into her other qubes when she needs to log into her accounts.

Bonus: Carol explores new financial technology

The vast majority of Carol’s assets are in broad-based, low-cost, passively-managed indexed funds. Lately, however, she’s started getting interested in cryptocurrency. She’s still committed to staying the course with her tried-and-true investments, and she’s always been skeptical of new asset classes, especially those that don’t generate cash flows or that often seem to be associated with scams or wild speculation. However, she finds the ability to self-custody a portion of her assets appealing from a long-term risk management perspective, particularly as a hedge against certain types of political risk.

Carol has added the following to her Qubes setup:

  • A standalone qube for running Bitcoin Core and an offline wallet vault. Carol finds the design and security properties of Bitcoin very interesting, so she’s experimenting with running a full node. She also created a network-isolated vault in order to try running a copy of Bitcoin Core completely offline as a “cold storage” wallet. She’s still trying to figure out how this compares to an actual hardware wallet, paper wallet, or physically air-gapped machine, but she’s figures they all have different security properties. She also recently heard about using Electrum as a “split” wallet in Qubes and is interested in exploring that further.

  • Whonix qubes. Carol read somewhere that Bitcoin nodes should be run over Tor for privacy and security. She found it very convenient that Whonix is already integrated into Qubes, so she simply set her Bitcoin Core “full node” qube to use sys-whonix as its networking qube.

  • Various qubes for DeFi and web3. Carol has also started getting into DeFi (decentralized finance) and web3 on Ethereum and other smart contract blockchains, so a friend recommended that she get a Ledger hardware wallet. She downloaded the Ledger Live software in an app qube and set up her system to recognize the Ledger. She can now start her USB qube, plug her Ledger into it into a USB port, use the Qubes Devices widget to attach it to her Ledger Live qube, and from there she can interact with the software. She has a separate qube with the Metamask extension installed in a web browser. She can also use the Qubes Devices widget to attach her Ledger to this qube so she can use Metamask in conjunction with her Ledger to interact with smart contracts and decentralized exchanges.

  • Various qubes for research and centralized exchanges. Carol uses these when she wants to check block explorer websites, coin listing and market cap sites, aggregation tools, or just to see what the latest buzz is on Crypto Twitter.

Carol makes sure to back up all of her qubes that contain important account statements, confirmations, spreadsheets, cryptocurrency wallets, and her password manager vault. If she has extra storage space, she’ll also back up her templates and even her Bitcoin full node qube, but she’ll skip them if she doesn’t have time or space, since she knows she can always recreate them again later and download what she needs from the Internet.

Conclusion

The characters we’ve met today may be fictional, but they represent the needs of real users like you. You may find that your own needs overlap with more than one of them, in which case you may find it useful to model certain subsets of your overall Qubes system on different examples. You probably also noticed that there are commonalities among them. Most people need to use email, for example, so most people will need at least one email qube and a suitable template to base it on. But not everyone will need Split GPG, and not everyone will want to use the same email client. On the other hand, almost everyone will need a password manager, and it pretty much always makes sense to keep it in an offline, network-isolated vault.

As you’re designing your own Qubes system, keep in mind some of the following lessons from our case studies:

  • You’ll probably change your mind as you go. You’ll realize that one qube should really be split into two, or you’ll realize that it doesn’t really make sense for two qubes to be separate and that they should instead be merged into one. That’s okay. Qubes OS supports your ability to adapt and make changes as you go. Try to maintain a flexible mindset. Things will eventually settle down, and you’ll find your groove. Changes to the way you organize your qubes will become less drastic and less frequent over time.

  • Make frequent backups. Losing data is never fun, whether it’s from an accidental deletion, a system crash, buggy software, or a hardware failure. By getting into the habit of making frequent backups now, you’ll save yourself from a lot of pain in the future. Many people never take backups seriously until they suffer catastrophic data loss. That’s human nature. If you’ve experienced that before, then you know the pain. Resolve now never to let it happen again. If you’ve never experienced it, count yourself lucky and try to learn from the hard-won experience of others. Keeping good backups also allows you to be a bit more free with reorganizations. You can delete qubes that you think you won’t need anymore without having to worry that you might need them again someday, since you know you can always restore them from a backup.

  • Think about which programs you want to run and where you want to store data. In some cases, it makes sense to run programs and store data in the same qube, for example, if the data is generated by that program. In other cases, it makes sense to have qubes that are exclusively for storing data (e.g., offline data storage vaults) and other qubes that are exclusively for running programs (e.g., web browser-only qubes). Remember that when you make backups, it’s only essential to back up data that can’t be replaced. This can allow you to achieve minimal backups that are quite small compared to the total size of your installation. Templates, service qubes, and qubes that are used exclusively for running programs and that contain no data don’t necessarily have to be backed up as long as you’re confident that you can recreate them if needed. This is why it’s a good practice to keep notes on which packages you installed in which templates and which customizations and configurations you made. Then you can refer to your notes the next time you need to recreate those qubes. Of course, backing up everything is not a bad idea either. It may require a bit more time and disk space upfront, but for some people, it can be just as important as backing up their irreplaceable data. If your system is mission-critical, and you can’t afford more than a certain amount of downtime, then by all means, back everything up!

  • Introspect on your own behavior. For example, if you find yourself wanting to find some way to get two qubes to share the same storage space, then this is probably a sign that those two qubes shouldn’t be separate in the first place. Sharing storage with each other largely breaks down the secure wall between them, making the separation somewhat pointless. But you probably had a good reason for wanting to make them two separate qubes instead of one to begin with. What exactly was that reason? If it has to do with security, then why are you okay with them freely sharing data that could allow one to infect the other? If you’re sure sharing the data wouldn’t cause one to infect the other, then what’s the security rationale for keeping them separate? By critically examining your own thought process in this way, you can uncover inconsistencies and contradictions that allow you to better refine your system, resulting in a more logical organization that serves your needs better and better over time.

  • Don’t assume that just because you can’t find a way to attack your system, an adversary wouldn’t be able to. When you’re thinking about whether it’s a good idea to combine different activities or data in a single qube, for example, you might think, “Well, I can’t really see how these pose a risk to each other.” The problem is that we often miss attack vectors that sophisticated adversaries spot and can use against us. After all, most people don’t think that using a conventional monolithic operating system is risky, when in reality their entire digital life can be taken down in one fell swoop. That’s why a good rule of thumb is: When in doubt, compartmentalize.

  • But remember that compartmentalization — like everything else — can be taken to an extreme. The appropriate amount depends on your temperament, time, patience, experience, risk tolerance, and expertise. In short, there can be such a thing as too much compartmentalization! You also have to be able to actually use your computer efficiently to do the things you need to do. For example, if you immediately try to jump into doing everything in disposables and find yourself constantly losing working (e.g., because you forget to transfer it out before the disposable self-destructs), then that’s a big problem! Your extra self-imposed security measures are interfering with the very thing they’re designed to protect. At times like these, take a deep breath and remember that you’ve already reaped the vast majority of the security benefit simply by using Qubes OS in the first place and performing basic compartmentalization (e.g., no random web browsing in templates). Each further step of hardening and compartmentalization beyond that represents an incremental gain with diminishing marginal utility. Try not to allow the perfect to be the enemy of the good!


This is a companion discussion topic for the original entry at https://www.qubes-os.org/news/2022/10/28/how-to-organize-your-qubes/
17 Likes

Nice. A lot of effort and (useful) work put into it, so hopefully people won’t give up on reading such a long article.
It should be rewarding and making people reconsider and build their own models based on this.

2 Likes

I can see these becoming 30-60 second video explainers. Absolutely brilliant.

5 Likes

Great work!

As far as I can see this is around 4800 words which comes in at around 26 minutes of voiceover time.

The two first cases are around 3-4 minutes while the third comes in at around 6.

I’d think that the second might be the best to start off with since devs are more naturally drawn to tools like Qubes on their own and the third case is more complex & complete.

So lets see how the second case could be done:

The first two paragraphs are great as they are, add some relevant stock videos and the lead up to jumping into Qubes itself is easily done.

Then to make it really good the different Qubes should be listed while they pop up on the screen in that chart.

Finishing off with some clips that shows the professional backup a good community can give would then make for a good video to publish all over the place :slight_smile:

1 Like

OK, just had to try it out!

This is around 1 hour of work on the two paragraphs around journalism.

All clips are free for reuse, so with credits producing videos like these for Qubes should pose no legal problems.

The voice bot can be abused heavily for free voiceover, temp mail works for that :slight_smile:

I can set aside a workday or two for producing a video if I can use it as a case and if there is a constructive process around it. (Rights can belong to the Qubes project, details should be simple)

Please do NOT spread this outside of here since its only a mockup:

Hope we can get this moving forward and also set up a good plan for spreading a video and/or other material like this :slight_smile:

P.S: If someone else could do the animation for the Qubes setup that is used as an example this could all be done in a matter of days

5 Likes

This is a very good guide. Thank you.
Question: does Signal Desktop work on Fedora (as in the journalist case study)? If so, is it as safe as the Debian version sourced directly from Signal servers?

2 Likes

I’d recommend starting (or, if one already exists, joining) a separate thread for this question. My quick answer is that I think you can install the Signal desktop add from a repo in Fedora just like in Debian, but it’s been a long time since I did that. Either way, installing from a repo is generally the safest way, as long as the package and/or repo is signed, and you trust the signing key.

For this QOS user, I would not recommend two Signal account (if I remember correctly, Micah Lee recommended this approach some years ago). Instead, use a chat program which is as easy to use and install as Signal but does not require a phone number: Session. With this approach you offer a more anonymous solution for people who wants to contact this QOS user. Furthermore, you can use one Session ID (account) for each individual with this you can use Session as kind of disposable communication messanger.

1 Like

Solid advice. I have also started keeping tabs on this, since recently.

Another chat program similar to that is Briar.


Apart from all that, one confusion I have with regards to using QubesOS is, how many different templates do I really need? Do I really need a singular TemplateVM per program/app, such as a single template for running LibreWolf web browser, and another template for running an email client; or, am I overdoing it and I should just use the same TemplateVM for Librewolf and for the email client, but just separate those into two different AppVM’s.
In short, I am not sure whether I should have specialized TemplateVMs (installing minimum amount of specific packages per TemplateVM) , OR, if I should have specialized AppVMs (running a single app per AppVM).
Am I making sense? Can someone give advice on this?

Nice documentation. I thought the “use case” scenarios were a great idea and that the graphics were effective.

It might be cool to add “icons” for the different cubes and then use them as part of the computer interface, at some point. For example, in the journalist example, you could use a pencil and paper or something similar.

1 Like

I think the subject of attack surface and templates is beyond this guide, it’s an advanced subject and I don’t think it’s useful to most new users.

I mean, I am just asking for some advice on whether to specialize on TemplateVM or AppVM level. But, anyways, if that is so, I will create a new topic.

But:

The way I see it there are three main “levels” of compartmentalization:

(I am assuming you know how to clone a template, and how to make a template the template for an existing AppVM. If not, both are trivial skills.)

  1. Leave things as they are set up on first installation of Qubes. You’ll end up installing all of your software on ONE template, which will mean your vault, personal, work, etc. qubes will all have access to the same software suite. And if I recall correctly, even something like sys-net will have access to these things because it uses the same template.

2a) The next step up is somewhat easy and gives you most of the benefits Sven was talking about (as quoted by fslover). After install, clone the debian-11 or fedora-3x template (I don’t recall the fedora version number that is current, sorry). Make THAT new template the template for all of your domains (work, personal, etc) but not of things like sys-net and sys-firewall. That way at least your working qubes are the only things that see all that software. (This way your original template is left “clean” of any modifications you might make to it.)

2b) Instead of just making one clone, make a separate template for each of those working qubes. This can make sense if the apps you want to install differ greatly for each qube. Alternatively, if they’re similar, make ONE clone, install everything on it, then make clones of it, one for each working qube.

if you go with 2b you can…at some future date…compartmentalize a bit. Or not. It’s truly up to you. I personally find myself doing compartmentalization as time goes on (and even making more and more things disposable–but I actually keep my data elsewhere so that’s feasible in many cases where it wouldn’t be for most people), but that’s me not you.

  1. Whole hog–it’s a lot more work, and a lot more to learn, but that’s to build templates from scratch even for the system qubes like sys-net and sys-wifi. Start with debian-11-minimal, which has a lot less stuff on it than debian-11, and clone it and install only what a particular qube needs. For instance, more than likely (your situation may differ of course) only the vault qube needs keepass; this way only the vault qube will have it; it will never have been put on the template now being used by (say) sys-net.

A case study here is the fact that my system is on two networks, a wifi one (for the internet) and an ethernet one (local). I don’t want those two networks touching, so I have two different qubes doing the job of sys-net. The template for one includes wifi drivers, the template for the other includes ethernet drivers. That way if somehow by mistake I assign both devices to the same qube, that qube literally won’t know what to do with the device it’s not supposed to have.

But again, that takes a lot of knowledge, in fact, if you take this on you have a new hobby.

2a and 2b is something someone should be able to take on relatively quickly, and gives you most of the benefit of 3 for 1/20th the effort. But even leaving it as-is (option 1) is vastly better than almost everything else out there.

If you happen to be looking at a fresh installation, I’d at least clone the debian or fedora template to something else as a clean backup copy regardless of which choice is made.

[Edit to add: I make a distinction between “working” or “app” qubes and “system” or “infrastructure” qubes. The first is where you’d be working with GIMP or LibreOffice or a browser. The second group is things like sys-net, sys-firewall, and so on; qubes you don’t do any work on, but provide support services. What I was trying to get at with options 2a and 2b were to leave the provided template alone for system qubes, and make a clone of the template and modify it for the working qubes–as many or as few different ways as you like.

I just realized there’s an option 2c as well…which is to make separate copies of the system qube templates and uninstall software not needed in them (such as keepass). Obviously you only want to uninstall something you’re sure you won’t need. (And of course you have to know it’s there but useless before you can even think to do this.) But that’s still easier than building from scratch (option 3).

If at some point you do decide to go with Option 3 there are threads out there (usually titled something like “Debian 11 minimal install” or “Debian 11 minimal templates”) to help you get started. Threads like that are how I got started, in fact.

end edit]

5 Likes

Nope, currently this is irrelevant for Qubes since it is for Android OS only. Also it is P2P which is not similar too Signal, means you cannot send - receive messages when one communication partner is offline. They have these issues on their roadmap but again it is neither an alternative to Signal nor to Session atm.

Great work! thanks
as noted by SteveC and fslover I’m using since a couple of years as well the clone the debian-11 & fedora-3x template … …

this is a good, strong and simple solution for a user like me, with not really high technical skills

I guess this post partially covers the following issue:

The first thing I do with my top minimal template is to install all the packages and set all the prefs and features that will be common for all other clones of it, and consequently for the qubes based on them. Like shutdown-idle, qubes-agent–core-thunar/nautilus, qubes-repo-contrib, etc, etc.
Then and only then I start to clone and build QQ (Qubes Qastle, haha)

2 Likes

A very good point made by enmus!

As you move into my levels 2b and 2c of compartmentalization, and especially in level 3, you likely want to plan ahead: What will I want on ALL of my templates? Then do what enmus said. If you want something-else on only half of the templates, then make a clone of the enmus template, put the something-else on that clone. You now have an enmus template full of the stuff you want everywhere, and a something-else template that has the enmus stuff and something else on it. Generate all your other templates from whichever one of these is appropriate.

This is exactly what I do. My “enmus template” is called deb11m-sys-base. Another template has things a user (as opposed to a tinkerer) would want to see, and it’s called deb11a-base. It was cloned from deb11m-sys-base and then I added things to it like a file manager and so on. Every template I made is based on deb11m-sys-base, but only about half of them are based on deb11a-base. (Your names will vary, of course.)

Eventually you’ll want to draw an “ancestry tree” and figure out what’s in common in the most qubes, so you do as few repeated installs as possible. But again, this is probably way down the road. You’ll grow into that, you don’t need to worry about it at first.

Thanks, I’m using coincidentally the same nomenclature deb11base… fed3xbase
working slowly into the level3. as you said the most important: to know ahead what I will and I need on the templates