Brainstorm & Survey: Qubes OS Workstation Setup for Sysadmin

Hey everyone,

I’m currently working on my bachelor’s thesis, which involves creating a Qubes OS-based workstation for system administrators. The goal is to leverage Qubes OS to build a secure yet practical environment for daily admin tasks. I’d love to gather your thoughts and brainstorm together. Here are some initial ideas and questions:

  1. Domain / VM Structure in Qubes OS
  • How would you organize and split up the domains or VMs?
  • Would you create a separate VM with internal access to the company network?
  • Would you keep management consoles in their own dedicated VM to isolate critical admin tasks?
  • Or would you prefer multiple smaller VMs, each for a specific task (like monitoring, configuration, user management, etc.)?
  1. Daily Workflow & Tooling
  • Which tools and software would you run in which domain/VM?
  • Do you see any value in having dedicated Disposable VMs for riskier tasks (like testing unfamiliar software, fetching updates, etc.)?
  • How would you transfer files or logs between domains? Any best practices to avoid cross-contamination?
  • What are the must-have admin tools in your daily routine?
  1. Security vs. Usability
  • Which security measures are absolutely essential?
  • Where might you make trade-offs for a more user-friendly experience, even if it slightly increases risk?
  • How do you ensure that daily tasks don’t become too cumbersome (e.g., constantly switching domains or copying files)?
  1. Additional Considerations
  • How do you feel about network segmentation within Qubes (e.g., a dedicated firewall VM)?
  • Any experience with automated patch management in a Qubes environment?
  • What should we keep in mind for scalability (e.g., when there’s a larger admin team or broader responsibilities)?
  • Any best practices you’d recommend when working with Qubes OS?

I really appreciate any insights, tips, or experiences you might share—everything helps me refine my project. Thank you in advance for your feedback!

Best regards,

3 Likes

Hi

I do sysadmin for clients and myself, here are how I proceed:

For each client, I have

  • a sys-vpn qube as they all require a VPN
  • a sys-vpn-firewall because you need a safe netvm between qubes and the sys-vpn for holding the firewall rules
  • a ssh qube
  • a vault qube
  • desktop stuff qube (conferencing, emails)

I only allow clipboard to work between the qube of a given clients, so I can’t inject crap or exfiltrate data accidently.

This highly depend the trust I have in source material, I rarely use disposable except if I need to try something weird that could damage the user profile in a qube.

Tools I use are usually those:

  • firefox or chromium depending what I need
  • keepassxc for the vault and ssh agent
  • nix, terraform, git, toolschains (nodejs, rust, gcc, go), pip, npm, whatever I need for a task
  • gimp to handle pictures

I always ensure the vpn firewall does not allow to bypass the VPN, so I’m quite sure I won’t leak client data outside the VPN.

I make sure the clipboard is limited, and that the backup policy matches the one at my client, most of the time I do not backup my clients qubes by default, I just do a backup into the qube itself to send it to my client’s storage, otherwise it could be considered as data exfiltration.

I don’t split the tasks into more qubes, I need to be productive and the security level reached is already far superior to what most of my clients would hope for themselves.

As usability tradeoff, I never reboot qubes after a template update as I shutdown my computer every day, this is way less disruptive.

I guess I already replied to most points here :smiley:

8 Likes

Is it OK if I’ll ask questions directly here regarding what you said or should I open a new topic?

This means the structure is:
sys-net, then sys-vpn, then sys-vpn-firewall, correct?

Is this something else than Split SSH?
Can you refer me to the correct method of doing this please?

I’m guessing you do that with the policies, but I have no idea how to make such thing. Is there a guide for this or how do you do that?

Are you using the firewall of the sys-vpn qube itself or where? And what rules do you use for this?

You mean like going to sleep or is it there some security into it? I never shutdown my machine

1 Like

you forgot sys-firewall :slight_smile:

qubes-clientN-* → sys-client-vpn-firewall → sys-client-vpn → sys-firewall → sys-net

it is simply a dedicated qube to connect to remote hosts using SSH, and it’s using split ssh for the key as I store it in the Vault of that client.

There is a dedicated tab in “Qubes global manager” GUI program. I need to check how to do the same using tags and write the policy myself, but the GUI works fine although it takes 5 minutes to configure a new client.

I use qvm-firewall to add rules for the client VPN, rules are applied on that qube’s netvm which is sys-firewall in this case. The rule is just deny everything except the host and port required to establish the VPN.

yes when I finish my day, I just shutdown the computer.

2 Likes

Hi ! I’m interested by the discussion and I would like to inquire some more information about your network setup.

Why the client-vpn-firewall ? Wouldn’t setting a firewall rule for the client-vpn be enough ? As rules are enforced in the sys-firewall Qube (or am I remembering things wrong?).

ex:
qube-client → sys-client-vpn → sys-firewall (drop any packet from sys-client-vpn that try to connect elsewhere) → sys-net

Thanks :slight_smile:

1 Like

Firewall rules of a qube are done on that qube’s netvm. As sys-vpn is on the network border (like sys-net) due to the VPN, you should not really trust it to hold firewall rules for the qubes below. That’s why you need a sane firewall qube between a vpn qube and AppVMs below.

2 Likes

Oooh because you restrict your qube-client from connecting to everything !

I think I know why I’m not used to that : the vpn provided wouldn’t allow connection outside of their local/private network.

Thanks for the clarification !

1 Like

Some VPNs I have to connect to are only used to connect to a range, some are there to pass all traffic toward the Internet, this depends the use case.

But there are cases in which I may want a qube to only connect to SSH hosts for instance.

2 Likes

I must add that as someone who’s required to access many different networks and systems for various clients through VPN, for me Qubes-OS was a life changer. I use a disposable qube for VPN connection and it allows me to have several connections open at the same time to different networks/clients. This is something that is not possible in any regular OS since there’s a limitation to a single VPN connection at a time. Another huge advantage is the default use of a clean OS (because disp-qube) for each connection. Working like this isn’t just making my work more efficient, it also have great impact whenever I’m required to go through any risk assessment done by the client - most of the questions simply become irrelevant because of the use of a clean disposable OS. Not only that I start with a clean OS when moving between clients, I’m actually starting with a clean OS even when moving between different networks of the same client during the same work day :laughing:
More then once, during risk assessment, I explained to the person doing the questioning about Qubes-OS and my use of Disp.qube for VPN and they would go silent for a few seconds, flip through the list of questions and come back with “ok, then we’re done here” :slightly_smiling_face:
Saying again - Qubes-OS is a life changer :trophy:

3 Likes

It’s actually possible on Linux (run a vpn in a network namespace) and OpenBSD (run a vpn in a rdomain) without too much work, should be doable on FreeBSD (in a different routing table) too, but Qubes OS makes it easier and more reliable.

1 Like