Long Wiki Edits Thread

Website
622

I would agree that adding password requirements for root does not substantially improve security for VMs.

However, there has been further discussion on Github. After reading this Qubes issue that tasket created, it seems there would be a small benefit to configuring dom0 to promt for sudo authorization?

tasket

Very understandable, since VM isolation must remain the paramount organizational principle for Qubes (both in terms of code and motivations). I’m actually glad the community has been able to evolve without the conventional security mindset. Yet, spotty as guest OS security is, in Qubes it represents a measure of security offered but not taken, even though Qubes integration makes it resemble the ease of Windows UAC. There is also the question of whether our VMs appear to be easily-acquired resources for attackers (i.e. the ‘welcome mat’ layed out), which promises to be at least a nuissance factor in operations.

tasket

Apart from the possibility of protecting Xen, I feel that offering root capabilities within VMs – without resistance – could make Qubes guests attractive resources to attackers of just about any skill level.

Its hard to get a handle on the entire thread by reading these two snippets but if there is even a small benefit should the documentation (how to) be offered to Whonix users? With a disclaimer. :wink:

Edit: Qubes-VM-hardening also disables Qubes default password-less root and has a tangible security benefit. This chapter is now moot. No?

2 Likes
623

Yes, I’m using both ATM

IIRC setting up the sys-net was a PITA. I can’t remember exactly what the problem was. I had to use part command line, part GUI (which I hardly ever use) to finalize the config.

Belay my last! I just remembered what the problem was!

I had to use the GUI to set VM class to HVM and select the PCI devices i.e. Ethernet card, Wireless card. If I tried to use the CLI sys-net would just hang or not start.

If you like I can come up with steps for sys-net, sys-firewall (dvm and DispVM). Will need both since pci devices need to be set to sys-net DispVM not dvm. Although I’m gnawing at the bit to start the “One Time Pad” wiki chapter, I guess its not going anywhere. :drooling_face::grinning:

2 Likes
624

:+1:

That would be excellent 0brand and instructions would be a significant security enhancement. I for one would very much welcome it, since I haven’t investigated the issue at all.

I’m glad you’ve managed it! :slight_smile:

Agree the issue is moot re: enforcing passwords in Qubes, given the VM hardening tool enforces that anyhow, and provides a much higher security standard. So save your efforts for more valuable things.

1 Like
625

These steps work for me 9 out of 10 times for net-disp, 10 out of 10 for firewall-disp. The troubleshooting section fixes any problems with attaching PCI device and net-disp not booting. After completion, the new VMs function the same as AppVMs only non-persistent.

Q: If the PCI device is attached to the service-dvm will net-disp inherit the attached PCI device?

A: No, I tried that numerous times, does not work

Q: What do you mean by "the new DispVMs function like AppVMs only non-persistent?

A: These new service VMs can be set to auto-start, can be NetVM for other AppVMs, PCI devices can be attached and will be attached at every VM boot (persistent) with no user input required. DispVM for the most part can be used the same as a regular AppVM.

Q What names should the DispVMs be given in the steps?

A: ?

Q: Should the steps be broken up (Section 1. create service-dvm) (Section 2. create net-disp) (Section 3. create firewall-disp) (Section 4. starting VMs) (Section 6. troubleshooting)

A: ?

Off topic: Also VPN DispVMs and USB DispVMs <–working on this now) can be created :grinning:

Please let me know what changes need to be made to the instructions

Create sys-net and sys-firewall Disposable VMs

Qubes R4.0 only!

Qubes users can configure both the sys-net and sys-firewall VMs as Disposable VMs. Using DispVMs for service VMs has the advantage of preventing malware from getting persistent hooks in the VMs’ filesystem. Whereas AppVMs /home folder is persistent accross reboots, when a DisposableVM is shutdown, the VM is removed from Qubes and all related VM images are deleted from the host filesystem. Since fresh VMs are created every time a Dispvm is started, this ensures no malware could remain persistent across reboots.

Note: if users intend to use the same naming convention for the new VMs as currently on their system. The old sys-net and sys-firewall VMs must either be deleted or cloned with a new name.

These steps create the service-dvm (template for DispVMs) net-disp (Dispvm) and firewall-disp (Dispvm)

1. In dom0, create the dvm that will be used as Template for service DispVMs

qvm-create -P <pool_name> --template <template_name> --class AppVM --label gray service-dvm

2. In dom0, set service-dvm virtualizaion mode to hvm

qvm-prefs service-dvm virt_mode hvm

3. In dom0, set service-dvm as template for disposable VMs

qvm-prefs service-dvm template_for_dispvms true

4. In dom0, create net-disp DispVM based on service-dvm

qvm-create -P <pool_name> --template service-dvm --class DispVM --label red net-disp

5. In dom0, set net-disp to provide network for other VMs

qvm-prefs net-disp provides_network true

6. In dom0, set net-disp NetVM to none

qvm-prefs net-disp netvm ""

7. In dom0, list all available PCI devices to determine the correct backend:BDF address(es) to assign to net-disp

Note: the bakend:BDF address will look similar to this dom0:00_1a.0

qvm-pci

8. In dom0, attach the network PCI device(s) to net-disp

Note: if 00_1a.0 is the BDF of the Ethernet controller that will be assigned to net-disp, the command would look similar to this: qvm-pci attach --persistent net-test dom0:00_1a.0

qvm-pci attach --persistent net-disp <backend>:<bdf>

9. (Optional) In dom0, set net-disp to start automatically when Qubes boots

qvm-prefs net-disp autostart true

10. (Optional) In dom0, set net-disp as the dom0 time source

qubes-prefs clockvm net-disp

11. In dom0, create firewall-disp

qvm-create -P appvm_pool --template service-test --class DispVM --label green firewall-disp

12. In dom0, set firewall-disp to provide network for other VMs

qvm-prefs firewall-disp provides_network true

13. In dom0, set net-disp as NetVM for firewall-disp

qvm-prefs firewall-testing netvm net-testing

14. In dom0, set firewall-disp as NetVM for other AppVMs

qvm-prefs <vm_name> netvm firewall-disp

15. (Optional) In dom0, set firewall-disp to auto-start when Qubes boots

qvm-prefs firewall-disp autostart true

16. (Optional) In dom0, set firewall-disp as the default NetVM

qubes-prefs default_netvm firewall-disp

Starting net-disp and firewall-disp VMs

Prior to starting net-disp, users must ensure that no currently running VMs – such as the current sys-net – has the same PCI device attached. These VMs must be either shutdown or the PCI device detached.

Once VMs have been successfully started, users should ensure no other VMs will interfere with the VMs at the next Qubes boot. If the new net-disp VM and the current sys-net VM are both set to auto-start – and have identical PCI devices attached – may lead to failed starts for both VMs.

1. In dom0, start net-disp

qvm-start net-disp

2. In dom0, start firewall-disp

qvm-start firewall-disp

Troubleshooting

If users see an error stating “The PCI device could be attached”, rebooting the Qubes system will likely rectify the problem. After net-disp boots successfully for the first time, users should have no further VM boot problems. The network PCI device will be attached with every VM boot without the need to manually attach proir to every VM start.

2 Likes
626

My last post “Creating sys-net and sys-firwall Disposable VMs” instructions has been extensively modified

Steps added to create firewall DispVM,
All other steps have been updated as well

2 Likes
627

@pano

Colors may be useful? Opinions?

Color relations?

  • Qubes: blue - since the Q logo of Qubes is blue
  • console: black (maybe “more black then black”? can we do bold or something other than block to illustrate console)
  • VirtualBox: ?

Maybe colors for box colors?

Or maybe symbols for Qubes, console and graphical would help?

Some templates that could use such a revision:

2 Likes
628

That’s outstanding work 0brand!

I wonder whether the method for setting disposableVMs for sys-net and sys-firewall belongs on the Qubes website, since it is Qubes-specific? @adw We could then link to it and add it as an obvious hardening step.

If we don’t hear anything, I think we just add all this text, clearly mark it as experimental / testers-only, and find an appropriate home for it (Advanced Security Guide?).

Also keen for someone to chime in that it is the canonical method and safe - although it looks logical to me. Also, does the anon-ws VM and Tor Browser work fine in a disposableVM in this configuration i.e. disp-sys-net, disp-sys-firewall, disp-anon-whonix? If so, you’re probably the first person to pull it off.

My main worry is that anonymity might be affected somehow given previous (still open) Qubes issues with dvm-templates.

For bonus points or fun (since you like testing), you could attempt customizing the disp-anon-whonix with the alpha sandboxed Tor Browser (that requires Whonix 14) and see it works okay in this combo. That would be another first in the community probably. :slight_smile:

Good idea Patrick. It’s just a case of getting around to it.

If anyone wants to edit those templates, I’ll unprotect them.

PS Community is humming along nicely. I see in different threads: I2P development, VBox .ova shrinking, dispVMs in Qubes, encrypted email etc, new contributors solving issues on phabricator etc. Good stuff.

2 Likes
629

torjunkie:

I wonder whether the method for setting disposableVMs for sys-net and sys-firewall belongs on the Qubes website, since it is Qubes-specific?

Yes.

fix Qubes documentation edit cumbersomeness · Issue #3629 · QubesOS/qubes-issues · GitHub applies? :slight_smile:

If we don’t hear anything, I think we just add all this text, clearly mark it as experimental / testers-only, and find an appropriate home for it (Advanced Security Guide?).

Yes.

Also this shouldn’t be manual instructions for long. Is there a Qubes
ticket yet to make that the default?

PS Community is humming along nicely. I see in different threads: I2P development, VBox .ova shrinking, dispVMs in Qubes, encrypted email etc, new contributors solving issues on phabricator etc. Good stuff.

:))

630

Once again, great minds think alike! I was thinking this would be something that should be on the Qubes Docs. I didn’t know how to ask though.

That sounds great!

If one of the qubes devs could take a look at this would be very helpful. If we don’t here back, maybe ask on Qubes mailing list?

Yes! I’ve been using this setup since RC3 or RC4 (can’t remember which) The only problem I have is the disp-anon-whonix will not start after updating my system when I first boot every once in a great while. Requires system reboot for disp-anon-whonix to launch.

Example

Debian and Whonix Templates

sudo apt-get update && sudo apt-get dist-upgrade (all template VMs)

sudo dom0-qubes-updates

qvm-run disp-anon-whonix 'firejail torbrowser'

Seems like the Dispvm starts but no apps can be run?

Very possible

No problem!

BTW disp-sys-usb functioning. Should be finished writing the steps later on today :slight_smile:

1 Like
631

0brand:

If one of the qubes devs could take a look at this would be very helpful. If we don’t here back, maybe ask on Qubes mailing list?

I wouldn’t recommend wait here. Looks to me they have an even bigger
flood of incoming inquiries than Whonix.

The proper process as far as I understand would be to create a
qubes-issues ticket “document …”. Offering to provide a pull request.
Maybe wait for answers. Only maybe if it looks required. And then to
provide a pull request against qubes-doc on github.

qvm-run disp-anon-whonix 'firejail torbrowser'

For debugging… Does this help?

qvm-run disp-anon-whonix konsole

Does it work that far?

firejail torbrowser

Might give more clues.

632

Sorry, I replied to torjunkies post without reading through your post first. I just finished reading through fix Qubes documentation edit cumbersomeness · Issue #3629 · QubesOS/qubes-issues · GitHub

@torjunkie I can create the Qubes ticket if you like? I have a lot on my plate so it may take a few day to get this completed.

I know this command works

qvm-run disp-anon-whonix konsole

I can’t remember if I tried running running any apps from it when I was having problems. I will try runnig firejail torbrowser from the konsole next time it happens. Thanks!

2 Likes
633

We always welcome quality documentation contributions! The procedure for contributing Qubes documentation is explained here:

Basically: Submit a pull request to qubes-doc. We’ll review it and may ask for changes, if necessary. Once it passes review, it’ll be merged and appear on the live website.

I’m afraid you’ll probably never receive a response from the Qubes devs here or on our mailing lists about this. It’s not intentional or malicious; they’re simply so swamped that they probably won’t reply or even see it. Moreover, all of their time spent on reviewing documentation submissions is spent on the ones submitted via the proper channels (which are explained above), so your best bet for getting developer eyes on the document is by submitting it that way.

Yes, Patrick understands. :slightly_smiling_face:

For a documentation contribution, it is not necessary to create an issue in qubes-issues. Instead, you can just submit a pull request as explained on the page linked above.

3 Likes
634

Awesome! There is still some fine tuning needed before the instruction will be ready. Should not take long to complete. Once the changes are reviewed, I will submit a pull request to qubes-doc

Completely understood. I can well imagine the workload you/they have. I have problems myself just keeping up with Whonix wiki edits in a timely manner. :slight_smile:

Thanks for the quick reply.

And as always, Thanks for all the hard work!

2 Likes
635

I think it can help, but if you want something really good, then allow the reader to see only the sections he need.

If for example there was a dropdown or two, at the top of the page, instead of all the “If you are using…” boxes throughout the page, using the wiki would be much easier.

1 Like
636

pano:

I think it can help, but if you want something really good, then allow the reader to see only the sections he need.

If for example there was a dropdown or two, at the top of the page, instead of all the “If you are using…” boxes throughout the page, using the wiki would be much easier.

That would be very good, but we don’t have this skill in Whonix team at
the moment. So not realistic. (We stuck without webmaster, stuck with
mediawiki, let alone such sophisticated web development.)

637

Instructions for Disposable USB qube are complete. These instructions assume the the service-dvm in the previous instructions would be used as the disp-sys-usb template i.e. template_for_dispvms true

My next step is to do some fine tuning on both sets of DispVM instructions. Get feedback for any changes. Then I will submit a pull request to qubes-docs (if that is OK with everyone)

Also, I know much of the sys-usb info I mentioned is already in the Qubes docs. I wanted to add it here in case anyone wanted to test the instructions. Having all info in the same place makes it easier.

Create a Disposable sys-usb VM

Qubes 4.0 users now have the option of creating a sys-usb Disposable VM. This will provide significant benefits over the default sys-usb VM. Considering that USB devises can pose a serious security risk, the use of a disposable USB qube would mitigate many of the risks associated with attaching a USB. Not only is dom0 afforded the same protections the default USB qube provides from a malicious USB. The Disposable USB qubes’ non-persistent filesystem prevents malware from gaining a persistent foothold in the VMs /home folder.

Users must first create the dvm template which the disposable USB VM is based on (steps 1-3 “Create sys-net and sys-firewall Disposable VMs” chapter)

1. In dom0, create the disposable USB VM

qvm-create -P <pool_name> --template service-dvm --class DispVM --label red disp-sys-usb

2. In dom0, set the virtualization mode to hvm

qvm-prefs disp-sys-usb virt_mode hvm

3. In dom0, set disp-sys-usb NetVM to none

qvm-prefs usb-disp netvm ""

4. In dom0, list all available PCI devices

qvm-pci

5. In dom0, attach the USB controller to the USB VM

Note: the bakend:BDF address will look similar to this dom0:00_1a.0

qvm-pci attach --persistent disp-sys-usb <backined>:<bdf>

6. Hide USB controllers from dom0

Warning: If a USB AEM is being used, all USB controllers should not be hidden from dom0. This would prevent the USB AEM devices from functioning.

Note: If users created a usb qube during qubes install or by using salt, the following steps can be ignored.

If users have created a USB qube manually, there will be a brief period of time during the boot process when dom0 will be exposed to your USB controllers and any attached devices. This is a security risk, since even a brief exposure to a malicious USB device could result in dom0 being compromised. It is recommended users hide (blacklist) all USB controllers from dom0.

GRUB2

In dom0 terminal, open GRUB2 configuration file in a text editor

sudo nano /etc/default/grub

Locate the line that begins with GRUB_CMDLINE_LINUX and append the following text

rd.qubes.hide_all_usb

save and exit

In dom0 , update GRUB2 for the new changes to take affect

grub2-mkconfig -o /boot/grub2/grub.cfg

In dom0, reboot Qubes for the new boot parameters to take affect

sudo reboot

EFI

In dom0, open EFI boot configuration file in a text editor

sudo nano /boot/efi/EFI/qubes/xen.cfg

Locate the line that begins with “kernel=” and append the following text

Note: more than one “kernel=” line may be present

rd.qubes.hide_all_usb

save and exit

Troublshooting

If the USB qube fails to start the likely reason is one of the controllers does not support reset. Quite often the offending contoller is a USB 3.0 device. The following errors would suggest this is the issue.

In dom0, xl dmesg output

(XEN) [VT-D] It’s disallowed to assign 0000:00:1a.0 with shared RMRR at dbe9a000 for Dom19.
(XEN) XEN_DOMCTL_assign_device: assign 0000:00:1a.0 to dom19 failed (-1)

In dom0, when qvm-start disp-sys-usb is run

internal error: Unable to reset PCI device […] no FLR, PM reset or bus reset available

Users have serveral solutions available to restore VM functionality

  • remove the offending controller from the disp-sys-usb VM and try to restart the VM.

  • disable the USB 3.0 in the BIOS.

  • try to force USB 2.0 modes for the USB ports

    In dom0, force USB modes for all USB ports

    lspci -nn | grep USB | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ setpci -H1 -d @ d0.l=0

  • set the pci_strictreset option

    In dom0, set the no-strict-reset option

    qvm-pci attach --persistent --option no-strict-reset=true disp-sys-usb <backend>:<bdf>

1 Like
638

It looks like dispvm-sys-net, dispvm-sys-firewall, and disp-sys-usb have been pushed to the qubes docs. Not by me.

I looked it over and with the method described you are not able to use custom firewall rules set with static DispvVMs . However it is possible If users follow the instructions in this thread. The rule set must be added to the dvm template which the disp-sys-firewall is based on. Obviously firewall rules cannot be added for Whonix due to stream isolation.

This method is a little complicated but it is possible.

1. Create dvm template disp-sys-firewall is based on
2. Create disp-sys-firewall
3. Add custom rule set to dvm template. Note: Use the disp-sys-firewall IP address when creating rule set

1 Like
639

I haven’t seen one. It would be a nice option at install time - Create disposable sys-net, sys-firewall, and sys-usb VMs.

Or some fancy script that runs all those commands in order so the user doesn’t screw up.

He stole your thunder :slight_smile:

Great work on all of this BTW!

At least it’s done. You could suggest your improvements on github? Easy enough to create an anonymous account there.

Marek is assigned to review it ATM.

Excellent!

Thanks for chiming in Andrew. Appreciated.

I like yours better. If the docs don’t have your suggested improvements and passes Marek’s approval, you are welcome to add all your text to a page here somewhere, as it is more user-friendly and educational which is better for low-intermediate users IMO.

Qubers are more about getting the job done with few beginner tips, which doesn’t do it for everyone :wink:

1 Like
640

To summarise, I think there is where it’s at.

TO DO

  • Startpage bypass of Tor blocks.
  • 0brand’s dispVM 101 for low-intermediate users. Perhaps a whole new page, with a section in Advanced Security Guide pointing to it (?)
  • Footnote Qubes-Whonix VM protection script as per Patrick suggestion
  • Remaining email fixes (numerous)

Up-for-grabs

  • Proxy steps as per entropy’s info in previous post.
  • One Time Pads
  • Prettying up boxes in documentation perhaps (color)?
  • Template request
  • Debian developer request re that system-d setting that is a risk to anonymity (in another forum post)
1 Like
641

I have an pseudonymous github account. Don’t use it much though.

I completed the changes needed for qubes-docs and added a few thing that may be of interest the users (i think) :slight_smile:

It would be helpful if i could get a little feedback before the pull request is submitted. So I don’t duplicate all the content already on this tread. Just the introduction and the first 2 sections are posted.

I wanted to kill 2 birds with one stone with this submission.

  • find out if this way of creating DispVMs is sound
  • find out if adding custom scripts, software in the dvm is OK (I use them). This would be great to know for future wiki docs?

Create Custom sys-net, sys-firewall, and sys-usb DispVMs

Users have the option of creating cusomized DispVMs for the sys-net, sys-firewall and USB VMs. These VMs behave much like the default VMs created during Qubes installation with the exception of a non-persistent filesystem. Another similarity shared with the default service VMs is the option to use custom fireall rulesets as will as Qubes VPN scripts. This can be accomplished in spite of the fact that a fresh VM is created each time a DispVM is launched by adding rules or cusum scripts to the dvm template. Users also have the option to set the DispVMs to autostart at system boot in addition to attaching pci devices with the --persisent option. Since both of the aformentioned configuration options are required only at the initial DispVM creation. Using DispVMs in this manner is ideally suited for untrusted VMs which reqire persistent pci devices such as USB VMs and NetVMs.

Note: if the dvm is customized with a VPN or firewall ruleset. A seperate dvm must be created for use by each DispVM. Otherwise, if no custimizations are made to the dvm. Users need only create a singular dvm which can be used as template for all DispVMs

Create the dvm from which the DispVM will be based on

1. In dom0, create the dvm template

qvm-create -P <pool_name> --template <template_name> --class AppVM --label gray service-dvm

2. (Optional) In dvm, add user customizations

Firewall rulestets and Qubes VPN scripts can be added like any other VM

3. In dom0, set service-dvm as template for disposable VMs

qvm-prefs service-dvm template_for_dispvms true

Create the sys-net DispVM

1. In dom0, create sys-net DispVM based on service-dvm

qvm-create -P <pool_name> --template service-dvm --class DispVM --label red disp-sys-net

2. In dom0, set disp-sys-net virtualizaion mode to hvm

qvm-prefs service-dvm virt_mode hvm

3. In dom0, set disp-sys-net to provide network for other VMs

qvm-prefs disp-sys-net provides_network true

4. In dom0, set disp-sys-net NetVM to none

qvm-prefs net-disp netvm ""

5. In dom0, list all available PCI devices to determine the correct backend:BDF address(es) to assign to disp-sys-net

qvm-pci

6. In dom0, attach the network PCI device(s) to disp-sys-net instructions on finding and assigning pci devices can be found here (link to documention)

qvm-pci attach --persistent net-disp <backend>:<bdf>

7. (recommended) In dom0, set disp-sys-net to start automatically when Qubes boots

qvm-prefs disp-sys-net autostart true

8. (Optional) In dom0, set disp-sys-net as the dom0 time source

qubes-prefs clockvm disp-sys-net

If after reading this you think it should be reverted back to the original content/format please let me know. Maybe bring up the custom scripting in the dvm another time?

2 Likes