Technically, yes. In reality, I don't recommend it too much, unless you have a USB 3.2 Gen2 or Thunderbolt connection, because anything other than that will make things incredibly, ungodly slow.

https://www.qubes-os.org/doc/installation-guide/#installing-to-a-usb-drive

Not at all official. The only official venues are the ones listed as official on this page:

https://www.qubes-os.org/support/

Also, please note our remarks about unofficial venues here:

https://www.qubes-os.org/support/#unofficial-venues

I'm no expert but a laptop that supports, or comes with open source firmware such as Coreboot/Libreboot is a good start.

System76/Clevo machines or a supported Thinkpad.

Also https://www.qubes-os.org/doc/certified-hardware/

The network manager is in the sys-net VM and should be installed by default. The debian 9 vm will connect via a virtual network if you use sys-firewall as the netvm. Have you read this page? https://www.qubes-os.org/doc/networking/

They do mention this on their website. https://www.qubes-os.org/doc/system-requirements/#qubes-release-4x

The issues you're having appear to be because of your CPU not supporting the required things. Try Qubes 3.2.

> Hardware support may be another. CPU features may be another.

I'll take this a step further and say a Chrome Book will almost certainly not be able to run Qubes 4. Those machines are usually made with inexpensive, low-power chips and those sorts of chips won't have the virtualization technologies Qubes 4 requires.

A used X series Thinkpad is definitely the way to go.

This is a security measure to avoid parsing complex input and to protect against homograph attacks (discussion). You can control it by modifying <code>/etc/qubes/guid.conf</code>. The setting you want is allow_utf8_titles: "allow the use of UTF-8 in window titles; otherwise, non-ASCII characters are replaced by an underscore."

• Any that use OpenVPN will work, I can't speak for other protocols.

• The provider doesn't need to offer disconnect-on-vpn-dropout if you use a setup like https://www.qubes-os.org/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts

• Yes.

• I don't believe so. there are email lists https://www.qubes-os.org/mailing-lists/

While /r/qubes does have /u/andrewdavidwong (qubes community manager) as a mod, it is not an official channel for support, but like most places on reddit you'll hopefully get some sort of help.

The only official channel at the moment is the user and dev mailing list. Here and IRC are unofficial.

> I see many people posting questions but hardly getting any help including myself.

It's a relatively new OS so the number of people capable of helping or who have run into similar quirks are low. It also does not help, when for example you ask for help, someone gives suggestions of a direction to take to troubleshoot and you don't reply.

People have to understand that the more details you give the better chance of help.

There is not an installer, but there are very thorough set-up instructions on the Qubes website. I would suggest setting up your VPN on what is called a ProxyVM.

The only other thing you will need is the OpenVPN configuration files for PIA (you'll be using the OpenVPN client, instead of PIA client). The config files will be in a ZIP file in the Client Support Area on PIA's website--you'll first need to select the level of encryption that you want, then the server you want to connect to.

As for your general questions at the end, Qubes is not a "variant of" Fedora--it's really more of a virtual machine environment, and by default, most of the virtual machines run Fedora. (They can also run Debian, Windows, or other Linux distros.)

I'm running OxygenOS on a OnePlus 6 (and I'm perfectly aware of OnePlus' history wrt privacy and data collection).

Here's my approach to security and privacy:

1. Never use fingerprint and/or face recognition. I use a strong, alphanumeric password. This is annoying at times, but ultimately it is rewarding to know that the information needed to unlock my phone is contained in my memory and only there.

2. Disable location. None of my apps have access to my location.

3. Delete as many Google apps as possible.

4. No facebook.

5. ProtonMail for email.

6. Signal for messaging.

7. NordVPN for VPN.

8. Orbot for proxying over the Tor network.

9. Orfox for when I need to browse over Tor.

10. Firefox with AdBlock, Https everywhere, PrivacyBadger. All tracking disabled, turned off saving history/cookies.

11. Disabled both streams of data collection OnePlus wants.

12. Waiting for LineageOS compatibility with OnePlus 6, at which point I will flash it immediately.

Personally, I read a lot of the docs https://www.qubes-os.org/doc/ but then still had problems so I went to the community forum https://qubes-os.discourse.group/ and got help there. My system is great now and I love it.

There is also an unofficial IRC channel on freenode and a Matrix chatroom. Both good if you need further assistance.

What do you mean by “learning-by-doing”, it sounds good but do you have any examples?

You haven't given us nearly enough information about your setup to be of assistance.

I'd suggest comparing your CPU model to the ones listed here https://www.qubes-os.org/hcl/. You should check if yours even has the features you listed before asking how to enable them.

> Has anyone encountered this, is this by design? Is the application selection tab just for adding shortcuts to but all domains have access to all of the TemplateVM apps?

Correct, the all applications are loaded into the domain that are from the template. Selecting the application in the domains setting is only apply a shortcut to the menu.

You can check out this guide to see if this will help with what you want. I use it to have links from my email open in a DispVM.

Opening links in your preferred AppVM

disposable vms are very well discussed at https://www.qubes-os.org/doc/dispvm/ please note that it's not a template vm that becomes a template for dispvm, but an appvm. create an appvm based on debian template, configure it to your liking an then enable using it for dispvms. then set it either as systemwide dispvm or just selected vms.

Today it means virtualization. On this blog post, Joanna describes a vision for the future of Qubes were things are compartmentalized also in other ways, so we don’t depend as much on the hypervisor, but today it means virtualization.

Mostly, yes. Here's the rough state of things as of Qubes 3.2, the most recent version.

• Running GPU accelerated applications is nearly impossible, and it would be an extremely bad idea anyway. If this is a deal-breaker for you, you're better off with a different OS.
• USB device support has improved a lot! I've successfully used my internal USB webcam via USB passthrough see docs. It's a pretty good compromise between usability and security, but it is a bit complicated.
• You can't run VirtualBox, period. Many people seem to be running Windows 7 AppVMs, though, which sounds fine as long as you don't need GPU acceleration.
• Again on the topic of NVidia, I wouldn't count on being able to install their proprietary Linux drivers. The documented process seems to be broken right now and I don't know how high a priority it is to fix it.

The best resource for these types of questions is the Qubes Hardware Compatibility List. Looks like the T460s and T460p are both well supported, as are most Lenovo laptops. You'll probably be fine.

Both NordVPN and qubes can use openvpn. The Linux confit for nordvpn is just a list of config files for their servers, so just download the configs for the nordvpn servers (the zip file from the step with wget) and copy your favorite servers file to the file from the qubes docs, ie

cp

The keyboard driver is probably not detecting the key event.

Identify the /dev/input device associated with your keyboard and then cat the device as you press keys. You should see if the keyboard is or is not emitting the proper keycode. Perhaps the key went bad.

More info: https://stackoverflow.com/questions/13220566/linux-raw-input-without-root-permission

> I’m assuming that they aren’t that common, since Xen doesn’t seem to be very widely used compared > to things like Windows or MacOS, but the known examples of it have been patched already, right?

They aren't common for at least a couple of reasons.

1) Xen is reported to be quite small compared to for example the kernels of Linux/Mac/Windows. Xen's size is also mentioned in the design choices described here https://www.qubes-os.org/attachment/doc/arch-spec-0.3.pdf

2) Much work has gone in to trimming down Xen as it's used in Qubes. For example, the PV mode that has been a source of multiple escapes has been deprecated in favor of PVH.

Yes, the known examples have been patched.

A custom version of Xen was the backbone of AWS up until recently. AWS is reported to be moving to KVM, although I don't think they are deprecating Xen entirely https://xenresources.com/does-aws-use-xen-hypervisor/

For that reason I think it is safe to say Xen gets a fair amount of attention and usage.

Check Removing noexitboot and mapbs

On https://www.qubes-os.org/doc/uefi-troubleshooting/#removing-noexitboot-and-mapbs

This helped to fix it for me...well the screen is going Black after some log lines are displayed after start....but some seconds later the screen Shows up again....and it continues ....

> if it is possible with GPU pass-trough is it mandatory to have > a second graphics card or will integrated graphics be sufficient for the desktop/other > parts of the OS while running a game?

Provided you can get the passthrough to work, integrated graphics should be fine for the rest of the system.

> just a few clicks or is it very in depth like on most linux distros with KVM

Closer to "very in depth". For more details, see https://www.qubes-os.org/doc/how-to-use-pci-devices/

> . and last how would one go about installing software? i assume this is not done with a normal package manager?

In a given guest, you would install software as on a non-qubes guest.
Only difference is that you would install a package in a template in order to make it available to all VMs based on that template.

Great summary!

One pitfall >Intel CPU with support for VT-x/VT-d

Firmware support is needed on the motherboard in addition to the CPU. MSI for example has VT-x but spotty VT-d implementation on some firmware and skipped it on one of my machines. You'll need to check with the vendor first and confirm if vt-d is supported. I've noticed it varies on models and may be left off public spec sheets.

The unofficial reports here have some motherboard info that may help: https://www.qubes-os.org/hcl/

Re:AEM, if you're very savvy, safeboot.dev project and TPM2 leveraging secureboot may be a future route if you're comfortable. Its not really a fully user facing project yet and Qubes support looks tricky, Ive only tried Ubuntu with it. Pointing it out as an alternative to AEM or Heads (safeboot.dev is also led by Trammel Hudson) if you're interested in recent hardware and a DIY approach.

You mean custom built as in a desktop computer ?

If so, the easiest route for the basic requirements would be

• Motherboard for a recent intel CPU, preferably with PS/2 connectors for mouse/keyboard
• Intel CPU with support for VT-x/VT-d
• As much RAM as you can afford (I’d go for 32GB)
• A decent SSD
• Stick with the built in Intel GPU

If you want to take advantage of stuff like Anti-Evil-Maid your will run into challenges. Then you need to find a motherboard that can accommodate a TPM 1.2 chip as well as the actual chip (difficult) or you can roll the dice and get a TPM 2.0 supported system (easy) and hope the motherboard can emulate TPM 1.2 (I haven’t tried).

If you want to match the certification requirements you’d need to find a Coreboot-supported motherboard. Those are limited and far between (and none are “new” AFAIK).

Purism are fairly “recent”, all in all.

EDIT: I should preface this with saying I’m relatively new to Qubes too. I went for a maxed out ThinkPad T420 myself.

Librems are listed on the Qubes HCL.

• https://www.qubes-os.org/hcl/#purism_librem-14-v1_i7-10710u_comet-lake_integrated-graphics-uhd-620

They're not listed on Qubes' Certified Hardware list because Purism for any reason doesn't pay the monthly rate requirement in order to have the Qubes seal of approval.

• https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-process

But for reasons already stated (Disabled iME, HEADS Firmware, Librem Key, Hardware Kill Switches), they're still one of the best for security.

lenovo thinkpad series have a good compatibilty with qubes. but in all cases you can find a solution.

for exemple i have a dell with some inside component from alienware with an i7 and an rtx. did take some times to install because of a bug from the graphic cards driver, but you need solid knowledgs of linux before trying to debug an install of qubes.

and try to look for your computer in this list : https://www.qubes-os.org/hcl/

hope you a nice experience with qubes.

&#x200B;

ps: sorry if my english is not perfect, not a native speaker

> So this is just a file being digitally signed by developers stating that they aren’t being coerced or blackmailed by a third party?

Basically, yes. You can read more about the concept here:

https://en.wikipedia.org/wiki/Warrant_canary

> How do we verify the signatures?

That's documented here:

https://www.qubes-os.org/security/pack/#how-to-obtain-verify-and-read

The short answer is no. The long answer why not and what could be possible is here

“However, we can be pretty sure there will never be a GPU passthrough solution that works on every system. It is not just about the complexity of the problem and the multitude of GPU products available. As mentioned above, some manufacturers intentionally obstruct GPU passthrough in their graphics cards, so it is likely that some hardware configurations will never have full support. This is why the compromise solution will be available as a fallback even once more robust GPU passthrough is developed.”

It's a known issue with compositor, just disable it.

https://www.qubes-os.org/doc/gui-troubleshooting/#screen-blanks--weird-computer-glitches-like-turning-partially-black-or-black-boxes

The short answer is... don't do that.

The longer answer is.. No. Really. Don't do that.

&#x200B;

You didn't really specify what the USB device is. Outside of keyboard and mouse, USB should never ever touch dom0. If you need to transfer files in, (also heavily not recommended but you do you), attach the drive to an AppVM, transfer files to the AppVM, then use dom0 command to copy them in.

If it's an external keyboard you need, in dom0:

sudo qubesctl state.sls qvm.usb-keyboard

See: https://www.qubes-os.org/doc/usb-qubes/ for more info.

(Seriously.. don't do that.. it's Bad, mmmkay?)

Should be possible by editing your RPC policy appropriately:

https://www.qubes-os.org/doc/rpc-policy/

https://www.qubes-os.org/doc/qrexec/

Excerpt from second link: > work-mail work-archive allow
> [...]
> The first rule allow call from work-mail to work-archive, without any confirmation.

I don't personally use it, but you can have Tor Browser without Tor. This way you can browse without being slowed down through Tor network but with Tor Browser's privacy enhancements. Beware it's a very rough setup at the moment.

I finally got it to work, after having removed whonix templates and vm's, by doing this:

sudo qubes-dom0-update --enablerepo=qubes-templates-community --action=install qubes-template-whonix-ws-15

and

sudo qubes-dom0-update --enablerepo=qubes-templates-community --action=install qubes-template-whonix-gw-15

Then manually created whonix vm's from manager. I also added this one manually:

qvm-create whonix-ws-15-dvm --class=AppVM --template=whonix-ws-15 --label=red

Then in 'whonix-ws-15-dvm' from advance settings, tick Allow starting DisposableVMs from this qube, from there you can set anon-whonix its DispVM to whonix-ws-15-dvm.

Hi,

While brainstorming and doing more reading on the Qubes OS docs, I came across this section.

I made a new VM called uni-net that could be called a "subnet" for the three other uni-related VMs (uni-campus, uni-home, uni-shared). In uni-net, I followed those iptables commands and I was able to achieve successful pinging between uni-campus to uni-shared and uni-home to uni-shared. Following that, I setup a samba share on uni-shared and I was successfully able to mount that share and able to read-write data into it.

Problem solved!

>Note: We don’t recommend installing Qubes in a virtual machine! It will likely not work. Please don’t send emails asking about it. You can, however, install it on an external USB hard drive (at least 32 GB) and run from it, at least for testing. Bear in mind, however, that such disks are typically orders of magnitude slower than even the slowest internal hard drives.

https://www.qubes-os.org/doc/installation-guide/

At least some of the templates can be installed using the salt system. It's possible all of them have salt configurations. That said you'd need to have all of the installation files already stored locally since you don't even have sys-net or sys-firewall yet.

If you literally only have a dom0 and nothing else configured I'd just redo the the install system from scratch.

Have you followed the instructions here? https://www.qubes-os.org/doc/multiboot/

Some question which might help pinpoint your problem, as it isn't really very clear from your OP:

1. What boot mode is your BIOS set to operate: legacy or UEFI?

2. Have you installed the GRUB bootloader? Is it on the MBR?

3. Are you getting a GRUB bootloader screen at all? If so, does it list Windows?

4. Does Windows boot?

5. When you say you can't see the Qubes partition, where can't you see it, that you would expect to do so?

6. What USB do you want to wipe? If you want to just re-copy the installation media, then using whatever utility you used to write it in the first place should work (eg dd). If you want to (non-cryptographically) wipe it anyway, then dd if=/dev/zero of=/PATH/TO/DEVICE/ (eg of=/dev/sdb) should do it.

Two final thoughts:

A. Read the link above, and in particular the security warnings about dual-booting with Qubes, and make sure you understand the risks and that the outcome is what you want to achieve.

B. If you haven't already, back up your Windows partition, or at a minimum any data you want to save, and make sure you have access to usable Windows installation media in case things go very wrong.

C. You could install to a flash drive, if you have a big enough one (~32GB IIRC). But from experience, this can be slow to run. YMMV. A compromise might be a separate internal HDD, all the better if it's one where you can physically disable the power whilst using Windows to avoid potential for contagion. Still not ideal, but better.

>I did that with the Rufus Tool and used DD Image Mode

use the second way, the one that implies the command line

dd if=Qubes-R3-x86_64.iso of=/dev/sdX bs=1048576 && sync

but for this you'll need a computer that runs GNU/Linux

There's one entry for a T400 on the Hardware Compatibility List (HCL) on qubes-os.org ; https://www.qubes-os.org/hcl/#lenovo_thinkpad-t400-6473pvu_core2-duo_gm45_intel-gma-4500mhd

Difference is that this was done with coreboot, not libreboot, but I personally don't know much about libreboot to determine if there is a difference in this case for the T400 (or if coreboot on the T400 is basically the same as libreboot, as libreboot sends patches to upstream). Note that this was also tested on Qubes 3.2, not the stable 4.0.

Here's when the entry for the T400 was added to the HCL; https://groups.google.com/forum/#!msg/qubes-users/D9slVaqF1u4/84fFLfuYEwAJ

The most important thing you'll want to know if it support VT-x and VT-d; proper virtualisation required for running Qubes (it's possible without, but you will be spammed with warnings). But occurring to the entry in the HCL the CPU in the testers T400 supports it. Before buying a laptop for Qubes, check if the CPU in it supports VT-x and VT-d (if it's an Intel). You can do so on Intel's website.

I personally don't know if SLAT is a big deal. It's important to check since the T400 tested doesn't support it.

About RAM:

You've run Qubes before. RAM requirements depend on what you want to do; how many VM's you'll want to have open, and what programs you'd like running in it. Personally I'd say 4GB of RAM is not something you should want. I've personally ran Qubes with 8GB and it was fine for having a few VM's with a Firefox instance each.

About other specs:

The CPU speed does not have to be such a bottle neck. RAM is the most important thing. Though, I've not ran Qubes on another lower specced than a X220 i5, so I'm not someone that can answer this particular question I'm afraid.

If possible, put in an SSD though.

The Qubes documentation helpfully answers questions like this, and is the sort of place you land when you Google things about it:

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

Specifically, under the "Creating and Using HVM domains": https://www.qubes-os.org/doc/hvm/#converting-virtualbox-vm-to-hvm

>It would help if reading material on how to achieve this was linked to in your post.

Yep. It certainly would. However, I've been using Qubes for a week and was able to find the answer quite easily. I generally assume that someone capable of installing/using Qubes is also capable of reading the documentation.

Qubes is built on Xen, not on Fedora. Dom0 is based on Fedora, but all of the code is open source. If you really want it to be Arch then fork it and go from there. If you want to see the future of Qubes I would strongly recommend reading this. Also in the near future you will be able to use Arch as a separate GUI VM that possibility is referenced here and should be available in Qubes 4.1.

It’s not clear which files you have—the cloned repository? OpenVPN config files?—and which ones you don’t.

The instructions here https://www.qubes-os.org/doc/vpn/ (Set up a ProxyVM as a VPN gateway using iptables and CLI scripts) are very good and if you get stuck on a step you can refer to that specific step.

I've been lurking for a while as well and also recently opened an account so I see where you're coming from :)

What you call the DOS settings are actually the BIOS settings (your laptop firmware). To access it, when you first start the PC, hit F1 repeatedly until you see something that does look like a DOS screen. The settings I changed on my T450s:

1) Config > Intel AMT > Disabled -- not crucial but it is a security risk so why keep it on. 2) Security > Virtualization > Enable both Intel VT settings. That is VERY important. It helps with virtualization which Qubes uses constantly. 3) Security > secure boot > Disabled. I may be wrong but I don't think Qubes is compatible with SecureBoot (not less secure b/c of that) 4) Startup > UEFI/Legacy Boot > Legacy Only. AFAIK 3.2 is not UEFI compatible out-of-the-box so for your first install, make it easy on yourself.

To use USB devices w/o compromising dom0, you have to create a USB subsystem (USB Qube). You should start with the documentation and report your problems: https://www.qubes-os.org/doc/usb/

Regarding your WWAN, lots will depend on your hardware model and how it will be recognized (PCI or USB) . I can see that setup being a challenge but I hope I'm wrong.

Good luck and post your questions as you go.

Actually I've found this

https://www.qubes-os.org/doc/secondary-storage/

I'm confused as to how this works. Is the VM now fully located on another drive? Will it leave any traces one the main Qubes host?

Our goal for this release candidate is to improve the stability and reliability of Qubes 4.0, so we’ve prioritized fixing known bugs over introducing new features. Full announcement: https://www.qubes-os.org/news/2017/11/27/qubes-40-rc3/

I don’t use Qubes myself, but I’ve looked into it. As I currently understand, the project maintains a list of certified hardware on its website. The Lenevo 900 is listed (use the “find” tool in your browser) as compatible across all listed categories. If the 920 has similar hardware, I imagine it would be similar. Cheers.

sys-net -> sys-firewall -> sys-vpn-provider1 -> sys-vpn-provider2 -> AppVM

You can add as many proxyVMs upstream as you like, that's one of the features I love about Qubes. Good guide here for VPN setup: https://www.qubes-os.org/doc/vpn/

Don't do the GUI method in the first half of the guide, do the manual config via terminal/shell scripts/iptables which makes it pretty much leakproof. I ran leak tests with several tools and it works like a charm.

In /rw/config/vpn for each VPN provider I even created a /servers directory with .ovpn config files for different servers then wrote a quick swap-server shell script which copies over the server $1 argument I called with the shell script, drops the VPN and re-establishes with the new config file. Takes aboutr 3-4 seconds and now downstream machines are coming from Panama instead of Australia. Really works well, and there is no way for any of the downstream machines to reach the outside world through any means but the VPN tunnel or leak info.

I had no problems even configuring a chain of 3 vpn tunnels using 3 different providers, no problems at all. I kinda felt like Dan Acroyd in the movie Sneakers where they were bouncing their call all over the world. ;-)

Cheers & enjoy, let me know if you run into any problems following the guide.

We must distinguish between two types of operations:

• Copying and pasting <em>clipboard text</em> between VMs
• Copying/moving <em>files</em> from between VMs

There is, indeed, a limit to the quantity of text that can be copy/pasted between VMs using the inter-VM clipboard. If the quantity of text you wish to copy seems to exceed this limit (e.g., if the pasted result appears truncated), then I suggest first saving the text as a file in the source VM, then copying/moving that file to the destination VM.

The inter-VM clipboard is secure against sniffing (i.e., other VMs can't access inter-VM clipboard text unless you explicitly paste into them), but we assume that the intra-VM clipboard is not. (In fact, that's why Qubes was created.)

Read more: https://www.qubes-os.org/doc/copy-paste/#tocAnchor-1-1-1

Which Qubes version are you on? You can check by typing this in dom0:

$ cat /etc/qubes-release

3.1 is the latest, and I believe it should include the fedora-23 template by default, so you may want to upgrade.

However, if you just want to download the new fedora-23 template, you can do so from dom0 like this:

$ sudo qubes-dom0-update qubes-template-fedora-23

Downloading other templates works the same way. However, to install community-supported templates, you have to enable that repo, e.g.:

$ sudo sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-whonix-gw qubes-template-whonix-ws

You can read all about the available templates here:

https://www.qubes-os.org/doc/templates/

Just building on this OP, you need to figure out what you want to keep secure. There are no silver bullets, just mitigations that, stacked on top of each other, can stop certain kinds of attacks.

Fwiw, you can make Manjaro significantly more secure than it comes stock. A hardened kernel, good firewall rules, SELinux or other mandatory access control system, Secure Boot, disk encryption, etc. Maybe check out lynis and its recommendations?

If you need to do more security sensitive stuff only some of the time, you can still make Qubes' idea of disposable VMs a reality in basically any distro these days thanks to KVM. Just bring up a VM, do your stuff, then delete it. It's not quite as smooth as Qubes and it's harder to get things like USB and network firewalling configured correctly, but it's not impossible.

The first time I hear that, ProtonVPN is built by the ProtonMail Team

NordVPN has a linux Client, so just install that on your linux box like you would do on any other linux machine or use openvpn, you can just Download the nordvpn configuration files for openvpn

It very much depends on how you use Qubes. I'll give a run down on how mine is configured. Just as a side note: I use the Mirage Unikernel Firewall over the default sys-firewall that came with Qubes as it is far lighter on system resources (it is set to only use 32MB as I'm writing this over the several hundred megabytes of the default sys-firewall).

Except for a few select scenarios (that I'll get to shortly), I route all my traffic through a VPN (Mullvad in my case) using WireGuard instead of OpenVPN. I have a dedicated domain for that VPN that gets its network from my firewall. For enforcing use of my VPN outside of the Mullvad app so no clear text traffic can leak, I have configured firewall rules to only allow TCP network packets that come from the individual Mullvad server IP addresses that support WireGuard. I am then pretty confident that clear text traffic won't leak.

The key cases where traffic doesn't get routed first through my VPN and instead gets network directly to my firewall is for things like managing my router, connecting to my home server, using my network printer, and managing my Pi-Hole. There are firewall rules to allow connections to those internal IP addresses over the specific ports that I need to connect to them from.

That's how mine is configured at least. I hope that gives you some ideas.

There is a Qubes specific guide on Mullvad's docs

So you can set the Mullvad VPN VM as a NetVM for specific AppVMs and your ordinary sys-net VM for others.

I'm the OP from this thread.

I'm using Mullvad too. I would recommend using the official Mullvad client in a Debian ProxyVM. It's braindead easy. The client is open source, released under the GPL, so there are no security/privacy risks about using it unlike with other VPN providers who have proprietary clients. Here's how:

1. Clone your Debian 8 templateVM

2. Use whatever VM you do your webbrowsing in to download the official mullvad client and signing keys (Or the source code if you're paranoid and want to compile it yourself)

3. Verify the signature

4. Transfer the mullvad .deb file to your cloned Debian 8 templateVM

5. sudo dpkg -i [mullvad-deb-file]

6. You will receive a message about missing dependencies when the command is done, so run sudo apt-get -f install

7. Make a proxyVM based on the Debian 8 clone

8. Add network-manager to the ProxyVM under the "services" tab in Qubes VM manager

9. Make sys-net the netVM of the proxyVM

10. Start ProxyVM, start Mullvad client

11. Make the ProxyVM the netVM of any VM you want routed through the VPN

Done. Please ask questions if you encounter problems.

TIP: In the Mullvad client, click "settings" and choose "Block internet on connection failure" and "Stop DNS leaks". You can also change your exit node country easily, unlike with the openVPN config files.

That would be the first step, it would rule out the firewall. If it works that way then you know it's something with the firewall and the PureVPN docs may explain if there are ports that need to be opened, etc.

If it still doesn't work you might need to read PureVPN's docs to see if there's anything you need to do to connect through NAT, since your proxyvm will still be using an internal IP address even if its connected directly to the netvm.

Even the most trusted VPN providers, like Proton and Mullvad, buy infrastructure from the same companies.

You might trust Mullvad to not work with the NSA, but what about a company like m247, both Proton and Mullvad are primarily host on m247 infrastructure. The reason VPN provider have access to +2000 servers all over the world is that they don't own the servers themselves.

Encapsulation data is not the same as personal data don't expect 3rd companies to not share it with intelligence agencies, and that is all they need to deanonymize you.

But it really only matter if you need more than a privacy VPN.

You say "normal update", I cannot know what you consider a normal update. But for me, I agree that the word "normal" could mean "conforming to a type, standard, or regular pattern : characterized by that which is considered usual, typical, or routine", routine updates would be those I just listed.

You asked: "Can I run a normal update of the Whonix-15 template that already exist and it will update fully to 16", assuming the above: No.

You must follow what is written on the whonix page to update a VM from whonix 15 to 16: https://www.whonix.org/wiki/Release_Upgrade_Whonix_15_to_Whonix_16

If you do that, your second part: "and then I just have to rename my whonix-15 templates to whonix-16 and be squared away?", is correct.

I can only go off what you have said and what those words mean. If you mean something from what you wrote, please clarify.

There are multiple MacBook Pros listed in the HCL (which I’ll link to below), but I don’t know apple products well enough to tell them apart. You should check the list out, and see if you recognize your model.

Are you using UEFI, or Legacy BIOS? Multiple devices get a black screen during install when using UEFI, but work fine when using Legacy BIOS. I think there are modifications you can make to get UEFI to work, but if i was you, I’d just try Legacy BIOS and see what happens

https://www.qubes-os.org/hcl/

Do you mean that root image of the template got corrupted? Well, you can attach the image to a working disposable vm and fix it from there or create a temporary HVM using your choice of rescue CD iso and attach the image as described in the linked documentation. Documentation

I thought I'd corrupted my partition once, followed this guide and was able to get to the LUKS+LVM qubes_dom0-root to run fsck on per the Qubes documentation.

If fsck still won't run you could always try to copy the data off - for some reason ext filesystems will often let you mount even if you can't successfully fsck. Copy off the data from dom0 root to another driver temporarily, run mkfs.ext4 on the root volume, and copy the data back. It's not a great solution, and is only a last resort.

I'd actually copy the data off your AppVMs/other VMs for any critical data before you try this because it is very risky.

The closest setup to your system is the HCL entry here

CPU is close to yours but rest of system is not. The mailing list entry has some tips that might be helpful. Wish I had more to help with but this is the best I could find.

Assuming that you have checked the obvious (e.g. network source in the qubes settings, ethernet cable plugged in, etc) my next guess would be that you are running into the "xen dhcp hole" that requires you to manually configure networking inside the qube. Quoting https://www.qubes-os.org/doc/standalones-and-hvms/ ...

> Even though we do have a small DHCP server that runs inside the HVM’s untrusted stub domain to make the manual network configuration unnecessary for many qubes, this won’t work for most modern Linux distributions, which contain Xen networking PV drivers (but not Qubes tools), which bypass the stub-domain networking. (Their net frontends connect directly to the net backend in the netvm.) In this instance, our DHCP server is not useful.

According to the spec sheet on the ASUS website, your laptop meets system requirements, but I think you need to enable VT-d and VT-x in BIOS. They are disabled by default in most cases.

See also the installation guide.

https://www.qubes-os.org/doc/installation-guide/

Qubes does not and cannot protect against all vulnerabilities. In fact it is based on an assumption that there are undiscovered vulnerabilities in all software. Separation and how it forces you to do things in certain way limits and mitigates some of the risks, but it’s not foolproof. Qubes documentation lists the critical components that have to be trusted here. The Qubes certification requirements indicate other potential attack vectors the software cannot prevent, so it’s up to hardware vendors to fix those.

> Storing them on an other, air-gapped computer or a hardware device (Yubikey or similar) would be even more most securer

That's debatable: https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-using-a-separate-physical-machine

one option would be to install the drivers to the fedora template sys-net is based off of, then rebooting reach vm based off of it to see if it stays connected.

the other option since you're using a USB device is to set up the sys-usb qube. Here's the Qubes documentation on it . I had to go through this because it was recognizing my laptops camera as a USB instead of PCI. be warned though, if you're using a USB keyboard, you need to prepare some file ahead of time as your keyboard won't work in dom0 until you do

To install qubes, backup everything on Windows to another device, such as a USB stick, then follow the guide here: https://www.qubes-os.org/doc/installation-guide/

kernel-latest package is for dom0 only. So If you want to update the kernel of domU as well, you should install a package named kernel-latest-qubes-vm.

sudo qubes-dom0-update kernel-latest-qubes-vm

See the documentation.

https://www.qubes-os.org/doc/managing-vm-kernel/

Theoretically yes. However it requires a lot, a lot of programming. It is not just something that can be done overnight. It is something the devs want to do: https://www.qubes-os.org/news/2020/03/18/gui-domain/

Fedora 31 is EOL, you should upgrade to Fedora 32.

Documentation. Qubes announcement of Fedora 31 being EOL.

No, templates are not meant to run and have internet access, just not. What you are talking about is a Standalone vm, which is it own Template- and AppVM. Or otherwise you need to configure an AppVM to persist stuff (see the docs)

It should be that you can open your bios and turn on VT-x/d (virtualization and I/O MMU virtualization, or whatever your bios calls it)

Also, if you require the most extreme security measures, then you shouldn't dualboot/multiboot (qubes doc)

You can set up a netVM as stated in this docs: https://www.qubes-os.org/doc/vpn/ and you can set "Default netVM" in "Qubes Global Settings". It would be also possible to install the VPN on the firewall VM.

If you would really want to run the VPN from the VMs itself, then you could install the VPN on the template VM, but I don't think that is advised. Usually you would solve this with a separate netVM. The app VMs themselves shouldn't connect to Internet, they always connect to firewall/VPN VM.

https://www.qubes-os.org/doc/certified-hardware/

Either of these are fully qubes certified and both use the same lenove x230 base and the x230 is on the supported list for libreboot.

https://libreboot.org/docs/hardware/

You could always get one of these and do the changes they do to it but this is the fastest out of the box situation I know of.

correct. looks like a graphic issue.

I also have a tuxedo computer (desktop) and I also have the installer fail with that message. I have not found the fix though...

Tried these: https://www.qubes-os.org/doc/uefi-troubleshooting/

Probably way too many to list or explain unless you're an expert (i.e., advanced degree + many years of high-level industry experience) in virtualization engineering (I'm not). I think going down the rabbit hole of trying to secure Xen in a way that's usable for single-user desktop computing is a good way to gain an appreciation of all the work that has gone into Qubes.

https://wiki.xenproject.org/wiki/Securing_Xen

Then take a look at the Qubes Architecture documentation. This page includes the original spec PDF, which is only of historical interest now, but it might still shed some light on your question.

https://www.qubes-os.org/doc/architecture/

Of course you can change it to debian, no problam with that!!!

That is the purpse of Qubes OS that you can use multi distros.

Just pay attantion if you use a minimal tamplate that the following packet installed:

>qubes-usb-proxy <------ to provide USB devices to other Qubes.
>
>qubes-input-proxy-sender <----- to provide keyboard or mouse input to dom0.

Caution: If you want to use a USB-keyboard, please beware of the possibility to lock yourself out! To avoid this problem enable your keyboard for login!

https://www.qubes-os.org/doc/usb-qubes/#enable-a-usb-keyboard-for-login

Just a thought occurs to me about the whole compression thing. That's going to slow down read/write operations and with multiple VMs running, it could potentially cause detrimental performance issues.

I would wonder if your machine could take a second SSD. If so you could set it up and use it to store the VM images, which I imagine is probably the majority of the overhead in your system.

You can view information about that here.

That might be a cheaper solution.

Per Qubes OS Issues #4714:

> Looks like updates proxy doesn't work. See what VM you have set for those templates in /etc/qubes-rpc/policy/qubes.UpdatesProxy (see documentation) - the line with target=.... Check if that VM exists and can be started.

I think that instead of moving it to home, it's better to bind the directory under /var/lib/ to rw. See this guide: https://www.qubes-os.org/doc/bind-dirs/

(I feel like not binding /var/lib by default was a mistake, but maybe someone knows a good reason for it?)

Ping works by design, irrespective of rules set in the QubeManager.
Look at the docs

> R4.0 note: ICMP and DNS are no longer accessible in the GUI, but can be changed via qvm-firewall described below.

Both ping and DNS will work out of the box - to control them you need to use qvm-firewall

>So if I edit the /etc/resolv.conf of a template it'll work with the VPN on DispVMs?

It should.

>What DNS server do I add? A specific one for the VPN provider or just a standard DNS?

I never used Windscribe, but after a quick search I came across this page that shows "10.255.255.3", try to set that.

This is surely possible. You can route sys-whonix through a proxy or VPN or anything you like. I have done this using separated hardware, but you can achieve it using Qubes, too. The Whonix website has a lot of useful information on that, e.g.

https://www.whonix.org/wiki/Tunnels/Connecting_to_Tor_before_a_proxy

I vaguely remember there was some discussion on the Qubes' mail list as well ...

You mean you have HVM working fine but not AppVMs (https://github.com/QubesOS/qubes-issues/issues/4551)? I guess it has value if just to layer network VMs on separate OS (e.g. OpenBSD sys-net --> Fedora sys-firewall). While I'm a fan of both and OpenBSD's contributions to security are important, Fedora has a huge community and sponsors. At the risk of starting religious wars, the argument made with Whonix is pretty rough but hard to ignore: https://www.whonix.org/wiki/FAQ#Why_isn.27t_OpenBSD_Used.3F Incorporating an OpenBSD template seems like more distraction than payoff. My armchair view is that the future of Qubes is probably more dependent on an alternative to Xen, and with Windows 7 end of life getting QWT for Windows 10 AppVMs with USB passthrough (smart cards/yubikeys) for more - hopefully not ephemeral - corporate backing.

Combining Tor with some other kind of tunneling can actually worsen privacy. It depends on the details. This Whonix document is worth a read.

If you are willing to do a fresh install, there is a new ISO you can download that installs them by default. Backup/copy your data, wipe the drive, and do a fresh install, then restore. I did. Easy enough. Everything works.

&#x200B;

https://www.qubes-os.org/downloads/

From their documentation, it's not out yet — at least from their repository. Hopefully, they will add it soon. I guess, you can try to update it from the same way it's updated from 8 to 9 but here doing it 9 to 10. I would worry though if there are going to be some errors (e.g. something being removed, etc.), something essential to e.g. template VM.

There is support for u2f in qubes, using a proxy mechanism.
It doesnt extend to dom0.

The only way I can see this working would be if you had 1 USB controller that you reserved for dom0, and you reserved that for the solokey. You could use udev rules to ensure that other devices were not accepted, but you would still be opening yourself to a risk in dom0 from the USB firmware. You may think this is a worthwhile tradeoff.

Ah, ok. By BIOS loop do you mean it just returns to the boot entry menu? Or something else?

I had spotty success with UEFI, so I reverted to BIOS / legacy and that’s been rock solid for me. I have a Thinkpad X220, though, so a bit older than your hardware.

Also, check out the Qubes HCL for your exact model https://www.qubes-os.org/hcl/. There might be some insight there.

And you can also post to the (significantly-more-active) Qubes-users mailing list. Not guaranteeing a solution or anything there but it’s a bit more active than this subreddit.

Good luck! Keep us posted and we’ll be happy to help if we can.

I've ever even attempted what you are trying to do, so anything I say below comes only from my limited experience with Qubes in general.

You are almost certainly not meant to attach sys-usb to sys-net as the NetVM. Rather you are supposed to use sys-usb to pass the ethernet device to sys-net as an attached USB device.

The first step would be to make sure sys-usb can see your adapter when you plug it in. Hopefully it will be seen as some sort of ethernet adapter.

If sys-usb is able to recognize the device, then the next step is to pass the USB device to sys-net. Use these directions to pass the device itself to sys-net. What you are hoping for is for sys-net to be able to see the USB device as an attached ethernet port. If sys-net is able to see the attached USB device as an ethernet port, then it should be able to manage it using the same tools it uses to manage your existing wifi or ethernet connections.

I have no idea what to say about the cables. My general approach to solving this sort of problem would be to first try and get it working on a simple Linux install. That way you can verify that the Android <-> Linux tethering works and that your phone has everything it needs to successfully tether a vanilla Linux install. (It is usually easier to find online guides for this type of thing as well as opposed to finding Qubes specific guides.)

Then, once you have it working in a normal Linux install, you can try and see what additional steps need to be done to get it working in Qubes. Typically this just involves passing the devices around correctly to the various VMs, which is what I was trying to describe above.

Not sure how much help the above will be but perhaps it will get you started troubleshooting in the right direction. If you do manage to get it working please report back so that other people can see what it required.

qvm-block

Run it without arguments and it lists available devices. Run it with the attach command to attach a given block device to a given VM. Documnetation.

For curious readers:

>Can I install Qubes in a virtual machine (e.g., on VMware)?

>Some users have been able to do this, but it is neither recommended nor supported. Qubes should be installed bare-metal. (After all, it uses its own bare-metal hypervisor!)

https://www.qubes-os.org/news/2018/01/23/qubes-whonix-next-gen-tor-onion-services/

However, I wouldn't recommend doing it unless you really need the privacy, as it will be very slow and you'll be using up the bandwidth of a lot of volunteers.

You need to provide a lot more detail like error messages, what steps in the install process work vs what steps don't, what hardware your machine has (i.e. does it meet the 4.x minimum requirements), etc. It's pretty hard to help if the only info we have to go on is "the install didn't work."

Security and Anonymity are different. You can be secure by download and checking with checksums and verfying with PGP. But if you want anonymity, you can use TOR, yes they do have an onion link. It's in their website.

At the bottom of: https://www.qubes-os.org/downloads/#mirrors

It will take hours, it goes through 6 Nodes not including if use bridges. You still need to verify with PGP. If you insist on OnionShare, you have to trust the person sharing with you and verify with PGP as well.

Basically, Whonix isn't supposed to work on 3.2. It's all explained here, but in short, Whonix stopped supporting Qubes 3.2 a long time ago, and now that 3.2 has reached EOL, you're really using it at your own risk.

When you created sys-usb your USB controller was attached there. Simply removing the qube does not reattach it to dom0. Did you follow these instructions?

If you're getting stuck at step 2, you could try making the specified edits before removing the qube. If that doesn't work then you may want to get your hands on a PS/2 keyboard to complete the process.

Can I run applications, like games, which require 3D support?

&#x200B;

&gt;Those won’t fly. We do not provide OpenGL virtualization for Qubes. This is mostly a security decision, as implementing such a feature would most likely introduce a great deal of complexity into the GUI virtualization infrastructure. However, Qubes does allow for the use of accelerated graphics (OpenGL) in Dom0’s Window Manager, so all the fancy desktop effects should still work.

&#x200B;

https://www.qubes-os.org/faq/