Dev/Qubes
< Dev(Redirected from Dev/Qubes OS)
Contents
- 1 Qubes Persistence
- 2 Debian Template
- 3 bind-dirs vs Tor
- 4 Config Files Changes
- 5 IPs
- 6 Tor Browser
- 7 Run updates over Proxy/Tor
- 8 Time Sync
- 9 How big is Qubes OS's user base?
- 10 IP Spoofing Protection
- 11 Inter-VM Networking
- 12 Forum Discussion
- 13 IP
- 14 Misc
- 15 Time
- 16 tb-updater vs TemplateVM
- 17 UpdateVM
- 18 Upgrade through Clearnet
- 19 Build
- 20 Test
- 21 Qubes VM Manger Firewall Tab Settings
- 22 Qubes Upstream Bugs
- 23 stable vs testing
- 24 Handling of file system in TemplateVMs vs TemplateBasedVMs
- 25 Split GPG
- 26 sys-whonix as Qubes FirewallVM
- 27 Connection Issues
- 28 Matrix of Qubes VM Types
- 29 Network in TemplateVMs
- 30 Torified Updates Proxy
- 31 Updates Proxy Debugging
- 32 Troubleshooting
- 33 bind-dirs flow chart
- 34 qubes-whonix-postinit.service flow chart
- 35 Qubes-Whonix 14 release testing
- 36 lightdm autologin
- 37 ssh into Qubes dom0
- 38 releasever
- 39 R3.1 template package in dom0 R3.2
- 40 UEFI
- 41 yubikey
- 42 Qubes VM debug mode
- 43 salt
- 44 anon-vm tag
- 45 tags inheritance
- 46 Connection through Qubes Updates Proxy
- 47 See Also
- 48 Footnotes
Qubes Persistence[edit]
Table: Qubes R4 Inheritance and Persistence
| Inheritance [1] | Persistence [2] | |
|---|---|---|
| TemplateVM | n/a | Everything |
| TemplateBasedVM | /etc/skel/ to /home/ | /rw/ (includes /home/ and bind-dirs)
|
| DisposableVM | /home/ | Nothing |
Debian Template[edit]
https://groups.google.com/forum/#!topic/qubes-devel/EBxvtMlwp5k
bind-dirs vs Tor[edit]
Does bind-dirs will be run before /lib/systemd/system/tor@default.service?
Yes.
qubes-mount-dirs.service has Before=local-fs.target, which it ordered before sysinit.target. After=sysinit.target in turns is included by default (unless DefaultDependencies=noDefaultDependencies=no).
Config Files Changes[edit]
I don't know how rpm packaging works. However, the TorVM rpm packaging seems simpler to me and introduce less overhead than Debian packaging at first view. Is there something like config-package-dev for Fedora? config-package-dev is a package to overtake ownership of other > package's files. Such as, in Debian the Tor package owns /usr/share/tor/tor-service-defaults-torrc. Whonix needs to modify that file and keep it updated. config-package-dev can be used to avoid getting the file being overwritten when upstream releases and upgrade. Is there something like this for Fedora or is this even required? That would make a port much simpler, because for many parts, it is just diverted config files.
qubes-tor pacakages provides own config file (tor --defaults-torrc option used), so no need to override the one provided by tor package.
But to answer your question - no, rpm do not have option to take ownership of files from other packages, but to workaround this (rather sensible) limitation you can modify the config in triggers (so the file will be modified after each original package update).
IPs[edit]
Qubes uses non-fixed LAN IPs? How do internal LAN IPs get assigned to TorVM / AppVMs?
QubesVm IP address is generated based on its netvm ID (subnet number) and the said VM static ID, so unless user is switching netvm, the IP is pretty static. We've chosen 10.137.<subnet-id>.<vm-id> which is quite exotic so conflicts with real LAN are very rare (even if rather harmless in isolated network).
Tor Browser[edit]
In your Torless TBB launcher script for use with Qubes' transparent Tor proxy, TOR_SOCKS_HOST=10.137.3.1. Is this supposed to be the same for all Qubes machines regardless of how many ProxyVMs users have created (or other user settings)? Or is the user supposed to change this before using the script?
Perhaps it is good idea to add some firewall rule in TorVM to redirect traffic to any 10.137.0.0/16 IP + port 9050/9049 to the tor running in TorVM. This way AnonVM can use any IP as a sock proxy address.
Run updates over Proxy/Tor[edit]
Without wasting a lot space, having lots of standalone VMs... How could one persistently install software in QubesOS using package managers over Tor just for a specific VM? Routing all traffic over Tor is also an option, but not a ideal one either (having some clearnet traffic is better for various reasons).
Set TorVM as netvm for the template. By default template updates are routed via "update proxy" (simple http proxy, which allow access only to yum-repository-like sites). This proxy is running in netvm, so after TorVM. Because of that its you need to disable 'yum-proxy-setup' service for this template and allow some traffic in the firewall settings. Or enable 'qubes-yum-proxy' service in TorVM and ensure that its traffic goes through tor.
Time Sync[edit]
Introduction[edit]
Discussion about insecurity of NTP:
https://groups.google.com/d/msg/qubes-devel/YHK_rAUm0s0/ARrBPHrf0fkJ
Can Qubes OS leave VM's clocks untouched and keep time sync to the VM or is there some forced-VM-timesync-with-dom-0 that can not be turned off? In that case, that would be a bad.
Currently time synchronization is done in some silly way: qvm-sync-clock called each 6min from dom0 cron. That tool fetch the current time using ntpdate in netvm (VM set as clockvm in qubes-prefs), then pass the result to 'date -s' in each VM.
You can disable this mechanism globally by unsetting(*) clockvm (qubes-prefs -s clockvm none).
(*) Which apparently was broken, fix will be included in updates soon.
Instructions[edit]
UNTESTED!
Install a comfortable editor (optional!).
sudo qubes-dom0-update kate
Edit your VM settings. (Feel free to drop 'EDITOR=kate' and/or to use an editor of your choice.)
sudo EDITOR=kate virsh edit whonix-ws
Find the following block.
<clock offset='utc' adjustment='reset'> <timer name='tsc' mode='native'/> </clock>
Replace it with the following.
<clock offset='utc'>
<timer name='rtc' tickpolicy='catchup' track='guest'/>
<timer name='xen' present='no'/>
</clock>
How big is Qubes OS's user base?[edit]
https://groups.google.com/d/msg/qubes-users/AqZV65yZLuU/Kib1jFLZanUJ
IP Spoofing Protection[edit]
AppVMs can't spoof each other in Qubes' network.
Corollary: stream isolation cannot be circumvented.
Inter-VM Networking[edit]
Current Qubes + Whonix implementation has both the Whonix-Gateway and Whonix-Workstation connected to the same backend FirewallVM and iptables forwarding is manually established between the Whonix IP addresses. This current method is really just an efficient hack for our initial Qubes + Whonix implementation. The native/proper way to network VMs in Qubes is via chaining their networking "backend" together, which is part of Xen networking structure. This is how other VMs in Qubes are networked, including TorVM. According to Qubes devs, these Xen backends provide simple point-to-point networking between VMs. So this would be advantageous for further isolation of inter-VM Whonix traffic, since, currently, all inter-VM traffic is routed through the internet-facing FirewallVM, which can also be shared by other VMs. This current implementation with a shared FirewallVM could be somewhat of a security concern for inter-VM traffic, and a reason to move to native/proper isolated point-to-point "backend" networking. Also, in the future, it is desirable to leverage full ProxyVM/ServiceVM networking between Whonix-Gateway and Whonix-Workstation, as the TorVM does. ProxyVM utilizes Xen "backend" networking but automates it with transparent Qubes GUI networking, making use of dynamically created virtual networking interfaces. Whonix may need to add onto or adjust its internal networking setup to be compatible with such native Qubes networking.
Older, perhaps outdated discussions related to this topic:
- https://groups.google.com/d/topic/qubes-users/RFXoZ3zt-PE
- https://groups.google.com/d/msg/qubes-users/GhgWH5mHf2E/0LU35M6GPecJ
- https://groups.google.com/d/msg/qubes-users/GhgWH5mHf2E/96odaNoBVRwJ
Newer discussion:
- https://forums.whonix.org/t/multiple-whonix-workstations-that-can-communicate-with-each-other
- https://tor.stackexchange.com/questions/13522/how-to-configure-whonix-gateway-for-communication-between-two-local-workstations/13546#13546
Forum Discussion[edit]
IP[edit]
grep -r 10.152.152.10 *[edit]
packages/anon-ws-leaktest/usr/lib/leaktest-workstation/simple_ping.py:target = "10.152.152.10"
Let's make a patch adding command line support implementing either --qubes or --ip?
packages/whonixcheck/usr/lib/whonixcheck/preparation: GATEWAY_IP="10.152.152.10" packages/whonixcheck/usr/lib/whonixcheck/preparation: GATEWAY_IP="10.152.152.10"
Overruleable. These variables get only set there if they are not yet set. So they can be manipulated by using environment variables, or better by dropping a config snippet to /etc/whonix.d/40_qubes, /etc/whonix.d/40_qubes that contains: export GATEWAY_IP="<qubes-ip>"
(Make that 40_qubes_autogenerated if the file gets autogenerated.)
packages/anon-kde-streamiso/usr/share/anon-kde-streamiso/share/config/kioslaverc:socksProxy=http://10.152.152.10 9122
We could implement a package anon-kde-streamiso-qubes, that overrules anon-kde-streamiso and that gets only installed when using --qubes. (KDE config files are stackable although debuging is a bit cumbersome.) We'd just have to make sure the path to anon-kde-streamiso-qubes comes (before or after?) anon-kde-streamiso's path in the KDEDIRS envrionment variable.
Or we could install either anon-kde-streamiso or anon-kde-streamiso-qubes (--qubes) depending on which build switch is being used.
packages/anon-kde-streamiso/debian/control: settings are set, for KDE applications to socks 10.152.152.10:9122. packages/anon-kde-streamiso/README.md:settings are set, for KDE applications to socks 10.152.152.10:9122.
Just a package description strings doing nothing. Either nevermind or rewrite the comment.
packages/whonix-base-files/etc/apt/apt.conf.d/90whonix:## running on 127.0.0.1:9104 forwarding to 10.152.152.10:9104. packages/whonix-base-files/etc/apt/apt.conf.d/90whonix:## running on 127.0.0.1:9104 forwarding to 10.152.152.10:9104. packages/whonix-base-files/etc/apt/apt.conf.d/90whonix:## running on 127.0.0.1:9104 forwarding to 10.152.152.10:9104. packages/whonix-base-files/etc/apt/apt.conf.d/90whonix:#Acquire::socks::proxy "socks://10.152.152.10:9104/";
These are just comments doing nothing. We can either nevermind or rewrite the comments.
packages/whonix-ws-firewall/usr/bin/whonix_firewall:[ -n "$GATEWAY_IP" ] || GATEWAY_IP="10.152.152.10" packages/whonix-ws-firewall/etc/whonix_firewall.d/30_default.conf:GATEWAY_IP="10.152.152.10"
Overrulable.
File: /etc/whonix_firewall.d/40_qubes
Content: GATEWAY_IP="<qubes-ip>"
Note: Keep a possible race condiation in mind. Depending on how that config snippnett is created and when whonix_firewall starts. Should the config change after whonix_firewall was already loaded, reload Whonix's firewall ("sudo whonix_firewall").
packages/anon-shared-helper-scripts/usr/lib/anon-shared-helper-scripts/tor_bootstrap_check.bsh: TOR_CONTROL_HOST="10.152.152.10" packages/anon-shared-helper-scripts/usr/lib/anon-shared-helper-scripts/tor_bootstrap_check.bsh: TOR_CONTROL_HOST="10.152.152.10"
Overruleable. These variables get only set there if they are not yet set. So they can be manipulated by using environment variables, or better by dropping a config snippet to /etc/whonix.d/40_qubes, /etc/whonix.d/40_qubes and /etc/torbrowser.d/40_qubes that contains: export TOR_CONTROL_HOST="<qubes-ip>"
(Make that 40_qubes_autogenerated if the file gets autogenerated.)
packages/uwt/usr/bin/uwt: echo " sudo $NAME -i 10.152.152.10 -p 9104 /usr/bin/apt-get --yes dist-upgrade"
Just an output string when using "uwt -h". Not overrulable at the moment. We can either put both IPs in there. Or would it be worth sourcing the /etc/uwt.d folder to make that IP configurable? (It is also a performance question.)
packages/uwt/etc/uwt.d/30_uwt_default: uwtwrapper_gateway_ip="10.152.152.10"
Overrulable. Create a file /etc/uwt.d/40_qubes with content: uwtwrapper_gateway_ip="<qubes-ip>".
packages/uwt/man/uwt.1.ronn:`sudo uwt -t 5 -i 10.152.152.10 -p 9104 /usr/bin/apt-get.anondist-orig --yes dist-upgrade`
packages/uwt/man/uwt.1.ronn: uwt -t 5 -i 10.152.152.10 -p 9109 /usr/bin/wget ${1+"$@"}
Just a man page documentation string. We could modify the man page to cover both use cases.
packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:TransPort 10.152.152.10:9040 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:DnsPort 10.152.152.10:53 IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9050 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9100 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:#SocksPort 10.152.152.10:9100 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9101 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9102 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9103 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9104 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9105 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9106 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9107 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9108 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9109 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9110 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9111 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9112 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9113 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9114 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9115 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9116 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9117 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9118 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9119 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9120 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9121 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9122 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9123 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9124 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:## 127.0.0.1:9150 to 10.152.152.10:9150 [as part of the packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9150 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9152 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9153 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9154 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9155 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9156 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9157 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9158 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9159 packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9160 IsolateDestAddr packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9161 IsolateDestAddr packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9162 IsolateDestAddr packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9163 IsolateDestAddr packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9164 IsolateDestAddr packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9165 IsolateDestAddr packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9166 IsolateDestAddr packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9167 IsolateDestAddr packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9168 IsolateDestAddr packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9169 IsolateDestAddr packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9170 IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9171 IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9172 IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9173 IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9174 IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9175 IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9176 IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9177 IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9178 IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9179 IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9180 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9181 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9182 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9183 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9184 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9185 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9186 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9187 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9188 IsolateDestAddr IsolateDestPort packages/anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist:SocksPort 10.152.152.10:9189 IsolateDestAddr IsolateDestPort
Not overrulable. Unfortunatly Tor does not support variables in config files. Should I (Patrick) make a feature request against Tor?
If you could use static IPs, we could fall back to use Debian packaging's patching mechanism. But that would be burdensome maintenance wise. Because there would be need for a separate qubes repository, that always has the patch applied. Or users would always have to upgrade from source code, which seems inconvenient. Or can we think of something else?
packages/tb-updater/usr/bin/update-torbrowser: [ -n "$GATEWAY_IP" ] || GATEWAY_IP="10.152.152.10"
Overrulable. Create a file /etc/torbrowser.d/40_qubes with content: GATEWAY_IP="<qubes-ip>".
packages/whonix-legacy/debian/whonix-legacy.preinst: sed -i 's/192.168.0.10/10.152.152.10/g' "/home/user/.torchat/torchat.ini" || true packages/whonix-legacy/debian/whonix-legacy.preinst: sed -i 's/192.168.0.10/10.152.152.10/g' "/home/user/.xchat2/xchat.conf" || true
No change required here. Only applies to Whonix 8.3.
packages/whonix-gw-network-conf/etc/network/interfaces.whonix: address 10.152.152.10
TODO research: Does ifupdown support variables? If not... We have to think of something.
packages/anon-ws-dns-conf/etc/resolv.conf.anondist:nameserver 10.152.152.10
TODO research: Does /etc/resolv.conf support variables? If not... We have to think of something.
packages/anon-ws-dns-conf/debian/control: 10.152.152.10, where an Anon-Gateway is supposed to provide a DnsPort on port packages/anon-ws-dns-conf/README.md:10.152.152.10, where an Anon-Gateway is supposed to provide a DnsPort on port
Just documentation strings. Either nevermind or patch documentation.
packages/sdwdate-plugin-anon-shared-streamiso/etc/sdwdate.d/31_anon_dist_stream_isolation_plugin:PROXY="10.152.152.10:9108"
Overrulable. Create a file /etc/sdwdate.d/40_qubes with content: PROXY="<qubes-ip>"
packages/sdwdate-plugin-anon-shared-streamiso/debian/control: Sets sdwdate's proxy settings to socks 10.152.152.10:9108. packages/sdwdate-plugin-anon-shared-streamiso/README.md:Sets sdwdate's proxy settings to socks 10.152.152.10:9108.
Just documentation strings. Either nevermind or patch documentation.
packages/anon-ws-disable-stacked-tor/usr/lib/anon-ws-disable-stacked-tor/torbrowser.sh:## 127.0.0.1:9050 to Whonix-Gateway 10.152.152.10:9050 and packages/anon-ws-disable-stacked-tor/usr/lib/anon-ws-disable-stacked-tor/torbrowser.sh:## 127.0.0.1:9150 to Whonix-Gateway 10.152.152.10:9150. packages/anon-ws-disable-stacked-tor/usr/lib/anon-ws-disable-stacked-tor/torbrowser.sh:#export TOR_SOCKS_HOST="10.152.152.10"
Just documentation strings. Either nevermind or patch documentation.
packages/anon-ws-disable-stacked-tor/etc/rinetd.conf.anondist:127.0.0.1 9050 10.152.152.10 9050 packages/anon-ws-disable-stacked-tor/etc/rinetd.conf.anondist:127.0.0.1 9150 10.152.152.10 9150 packages/anon-ws-disable-stacked-tor/etc/rinetd.conf.anondist:127.0.0.1 11109 10.152.152.10 9119 packages/anon-ws-disable-stacked-tor/etc/rinetd.conf.anondist:127.0.0.1 9051 10.152.152.10 9052 packages/anon-ws-disable-stacked-tor/etc/rinetd.conf.anondist:127.0.0.1 9151 10.152.152.10 9052
Maybe anon-ws-disable-stacked-tor: consider replacing rinetd with rlinetd (probably not a great idea).
TODO research: does /etc/rinetd.conf support variables? If not, we have to think of something.
packages/whonix-ws-network-conf/etc/network/interfaces.whonix: gateway 10.152.152.10
Same comment as whonix-gw-network-conf/etc/network/interfaces.whonix.
packages/anon-torchat/usr/share/anon-torchat/.torchat/torchat.ini:tor_server = 10.152.152.10 packages/anon-torchat/usr/share/anon-torchat/.torchat/torchat.ini:tor_server = 10.152.152.10
Probably requires a package anon-torchat-qubes that conflicts with anon-torchat that gets installed when using --qubes.
packages/xchat-improved-privacy/usr/share/xchat-improved-privacy/.xchat2/xchat.conf:# /set net_proxy_host 10.152.152.10
Just documentation strings. Either nevermind or patch documentation.
packages/xchat-improved-privacy/usr/share/xchat-improved-privacy/.xchat2/xchat.conf:net_proxy_host = 10.152.152.10
Just documentation strings. Either nevermind or patch documentation.
grep -r 10.152.152.11 *[edit]
packages/whonix-ws-firewall/usr/bin/whonix_firewall:## From 10.152.152.11 icmp_seq=1 Destination Port Unreachable
These are just comments doing nothing. We can either nevermind or rewrite the comments.
packages/anon-gw-anonymizer-config/etc/tor/torrc.examples:HiddenServicePort 80 10.152.152.11:80 packages/anon-gw-anonymizer-config/etc/tor/torrc.examples:HiddenServicePort 11009 10.152.152.11:11009 packages/anon-gw-anonymizer-config/etc/tor/torrc.examples:HiddenServicePort 80 10.152.152.11:80
These are just comments doing nothing. We can either nevermind or rewrite the comments.
packages/whonix-legacy/debian/whonix-legacy.preinst: sed -i 's/192.168.0.11/10.152.152.11/g' "/home/user/.torchat/torchat.ini" || true
Same comment as for packages/whonix-legacy/debian/whonix-legacy.preinst.
packages/whonix-ws-network-conf/etc/network/interfaces.whonix: address 10.152.152.11
Same comment as for packages/whonix-gw-network-conf/etc/network/interfaces.whonix above.
packages/anon-torchat/usr/share/anon-torchat/.torchat/torchat.ini:listen_interface = 10.152.152.11
Same comment as for packages/anon-torchat/usr/share/anon-torchat/.torchat/torchat.ini above.
Misc[edit]
Random facts.
- AdminVM is a synonym for dom0 [3].
- AdminVM is not based on Fedora Template VM. More like a standalone VM.
- Qubes Q3 RC1 AdminVM is based on Fedora 20. [4]
- Qubes Q3 RC1 Fedora Template VM is based on Fedora 21.
Time[edit]
sudo mv /etc/qubes-rpc/qubes.SetDateTime /etc/qubes-rpc/qubes.SetDateTime.disabled
tb-updater vs TemplateVM[edit]
prerequisite knowledge[edit]
- TPO stands for The Tor Project
- The /home folder of a TemplateVM is copied to a TemplateBasedVM at creation time of the TemplateBasedVM. From then, TemplateBasedVM's /home folder is left untouched. (Source: https://groups.google.com/forum/#!topic/qubes-users/WwVJhGA-Xnc)
- Tor Browser installation path in Whonix 12 will change to ~/.tb. (https://phabricator.whonix.org/T338)
- Since Qubes-Whonix 11, Tor Browser gets installed by default for new images. (Not for in place upgrades.)
- Tor Browser Updater (Whonix) (((https://github.com/Whonix/tb-updater))) vs
- Tor Browser Internal Updater
- Tor Browser Updater (Whonix) is unable to keep user settings (modifications such as bookmarks). It renames the old folder. Adds ".old.$(date)". So nothing is lost. Then installs a fresh one. Something important to know. This limitation can probably not be lifted in tb-updater. Upgrading Tor Browser is hard. (TPO often changed the folder layout in past.) That's what Tor Browser's internal updater is for.
- No one has demonstrated yet, that it is possible to install & run and/or update TBB to either /usr/*, /opt/* or anything of that sort. This is because within the TBB folder, by TPO default, binaries and user data is mixed. (It is a portable application. [Portable with a meaning similar to portableapps.com. Portable on USB drives or similar. Not platform, arm + anything portable.])
- By TPO default, users are supposed to have TBB in their home folder.
- It is very unlikely, that TBB will be available as regular deb package anytime soon. [5]
- A quick an dirty packaging of TBB would likely require too much maintenance effort. [Needs keeping up with upstream releases.]
- Packaging TBB is further complicated, because TBB abuses Firefox's user settings mechanism for configuring anonymity related settings. (Firefox prefs) Therefore separation of binaries and user data is difficult.
- Once TBB is in user's home folder... [as TPO wants it] [and it does not work otherwise]... And once the user used it... And once the user stored settings there that the user cares about... [bookmarks, etc...] It gets very difficult for the TemplateVM and/or tb-updater to keep the TBB folder up to date. That's what Tor Browser Internal Updater is for.
- Unfortunately, this means, if a user had for example 5 different Qubes-Whonix-Workstation based AppVMs where Tor Browser is in use, the user would have to update each of its 5 TBBs using Tor Browser Internal Updater.
- This is an issue, because Qubes updates are already complicated. (Various templates and dom0 needs to be updated.) This adds another layer of complexity. Users also have to care about updating stuff from within their AppVMs, which is counter intuitive.
- TBB stable has automatic updates enabled by default. [6]
Implementation as of Qubes-Whonix 11[edit]
- As of Qubes-Whonix 11 it is confusing. Running tb-updater in the TemplateVM and restarting AppVM won't result in up to date TBB's. [Since if the TemplateVM modifies /home, this will not propagate to AppVM's /home.]
Brainstorming[edit]
Headless TBB Internal Updater Updates in AppVMs[edit]
We could call a qrexec service that starts TBB in each individual AppVM heedlessly (without / with hidden gui, using xvfb or similar) so it will be fetching updates.
up to date versions of Tor Browsers in newly created AppVMs inherited from updated TemplateVMs[edit]
ship Tor Browser tarballs in Qubes TemplateVMs in /var/cache/tb-binary and extract in AppVMs at boot time to user's home folder:
https://phabricator.whonix.org/T417
keep as is[edit]
Newly created Qubes-Whonix-Workstation AppVMs inherit the TBB version that came pre-installed in the Qubes-Whonix-Workstation TemplateVM. From there, TBB's internal updater keeps care of updating it.
Forum Discussion[edit]
- https://forums.whonix.org/t/what-should-tor-browser-updater-whonix-do-in-a-templatevm
- https://forums.whonix.org/t/idea-for-aqrexec-service-to-install-new-versions-of-tor-browser-to-a-list-of-vms
UpdateVM[edit]
Moved to Next#Torified_dom0_Updates.
Upgrade through Clearnet[edit]
Qubes R3.2[edit]
Just a note about upgrading a Whonix-Gateway TemplateVM through Clearnet. Untorified! This is easily possible by setting the following environment variable.
export UWT_DEV_PASSTHROUGH="1"
Qubes R4[edit]
Undocumented.
Build[edit]
Build Single Qubes Package[edit]
Source: https://groups.google.com/forum/#!topic/qubes-devel/o6pn-kV7cU0
BACKEND_VMM=xen dpkg-buildpackage -b
Build Qubes-Whonix Templates[edit]
git clone https://github.com/QubesOS/qubes-builder.git
(source of the following instructions)
cd qubes-builder
~/qubes-builder/builder.conf
GIT_BASEURL ?= https://github.com
GIT_PREFIX ?= QubesOS/qubes-
NO_SIGN ?= 1
VERBOSE ?= 2
BACKEND_VMM = xen
DIST_DOM0 ?=
DISTS_VM ?= whonix-gateway whonix-workstation
USE_QUBES_REPO_VERSION ?= 4.0
USE_QUBES_REPO_TESTING ?= 1
BRANCH ?= master
COMPONENTS ?= \
linux-template-builder \
builder \
builder-debian \
template-whonix
BUILDER_PLUGINS ?= \
builder-debian \
template-whonix
GIT_URL_template_whonix = https://github.com/adrelanos/qubes-template-whonix
import-whonix-keys:
if ! [ -d "$(KEYRING_DIR_GIT)" ]; then \
export GNUPGHOME="$(KEYRING_DIR_GIT)"; \
scripts/verify-git-tag; \
gpg --keyserver pgp.mit.edu --recv-key 916B8D99C38EAF5E8ADC7A2A8D66066A2EEACCDA || exit 1; \
echo '916B8D99C38EAF5E8ADC7A2A8D66066A2EEACCDA:6:' | gpg --import-ownertrust; \
fi
get-sources: import-whonix-keys
make get-sources
make template
Official Builds[edit]
- [7]
- [8]
- build command format
- Place for build template commands
- https://github.com/QubesOS/updates-status/issues
- https://github.com/QubesOS/build-issues/issues
Test[edit]
- works as UpdateVM
- can be used as ProxyVM for Fedora and Debian templates
- whonixcheck (--verbose) in sys-whonix, whonix, whonix-gw, whonix-ws
- Does qubes whonix network / firewall service run after qubes-sysinit.service? Check full systemd dependency resolution.
Qubes VM Manger Firewall Tab Settings[edit]
Short:
Have no effect for Qubes-Whonix VMs. Can be ignored.
Long [9]:
All that settings are in separate file in the VM directory - dom0 /var/lib/qubes/appvms/whonix/firewall.xml. If the VM is running, those settings are converted to iptables syntax and loaded into QubesDB of directly connected ProxyVM. The qubes-firewall service in the ProxyVM watch for such changes and applies the rules.
I.e. in case of Whonix, the connected ProxyVM is sys-whonix. Since in Whonix qubes-firewall service is disabled (Whonix 12 [10]), these settings do not affect Whonix. (qubes-whonix-firewall.service is what Whonix uses.)
Qubes Upstream Bugs[edit]
Usability:
stable vs testing[edit]
Building R3 vs R3.1. Comments on which branch / config to build.
https://github.com/QubesOS/qubes-issues/issues/1318#issuecomment-147133115
Handling of file system in TemplateVMs vs TemplateBasedVMs[edit]
Qubes R3[edit]
| root | home | |
| create new AppVM | Yes | Yes |
| modifications in TemmplateVMs for existing AppVMs | Yes | No |
- when you create a new AppVM, it inherits the TemplateVMs root and home folder
- when you make changes in your TemplateVM root such as installing new packages, those will be available to existing AppVMs after TemplateVM shutdown + AppVM (re)start
- when you make changes in your TemplateVM home, those will be not be available to existing AppVMs
Qubes Proposal[edit]
| root | home | |
| create new AppVM | Yes | No |
| modifications in TemmplateVMs for existing AppVMs | Yes | No |
Split GPG[edit]
See Dev/Split_GPG.
sys-whonix as Qubes FirewallVM[edit]
Goals:
- any TemplateVM behind sys-whonix should be restricted to torified updates proxy only
- Whonix TemplateVMs behind sys-whonix should be restricted to torified updates proxy only
- Whonix TemplateVMs connected to a ProxyVM other than sys-whonix should refuse to connect and show a warning [done]
Qubes tickets:
- Implement new firewall dom0->VM interface
- mechanism to hide Qubes VM Manager 'Firewall rules' tab
- Template policy, services->features, core plugins
Tickets:
Connection Issues[edit]
- icmp mtu connection issues?
Matrix of Qubes VM Types[edit]
ProxyVM NetVM AppVM
StandaloneVM TemplateBasedVM DisposableVM
HVM HVM Template
Network in TemplateVMs[edit]
As default setting, any TemplateVM (including Whonix) in Qubes R4.0 and above have their NetVM set to none.
Networking and update of TemplateVMs is possible through Qubes Updates Proxy.
Torified Updates Proxy[edit]
sys-whonix[edit]
File /usr/share/tinyproxy/default.html gets modified. The following is the original.
<head>
<title>{errno} {cause}</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
Modified to the following.
<head>
<title>{errno} {cause}</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="application-name" content="tor proxy"/>
</head>
Whonix TemplateVMs[edit]
Inside Whonix TemplateVMs, the following command is run will be run.
Qubes R3.2[edit]
curl_output="$(UWT_DEV_PASSTHROUGH="1" curl --silent --connect-timeout 10 "${PROXY_SERVER}")" || true
After the variables are substituted, the command actually run will be the following.
curl_output="$(UWT_DEV_PASSTHROUGH="1" curl --silent --connect-timeout 10 "http://10.137.255.254:8082/" || true
To simulate (test) this, run the following command.
UWT_DEV_PASSTHROUGH="1" curl --silent --connect-timeout 10 "http://10.137.255.254:8082/" ; echo $?
Should output the following.
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>403 Filtered</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <meta name="application-name" content="tor proxy"/> </head> <body> <h1>Filtered</h1> <p>The request you made has been filtered</p> <hr /> <p><em>Generated by <a href="https://banu.com/tinyproxy/">tinyproxy</a> version 1.8.3.</em></p> </body> </html> 0
That output gets `grep`ed for PROXY_META, i.e. for.
<meta name="application-name" content="tor proxy"/>
If that matches, the whonix-secure-proxy Qubes service is activated. In other words, the /var/run/qubes-service/whonix-secure-proxy status file is being created.
Qubes R4[edit]
TODO
UWT_DEV_PASSTHROUGH="1" curl --silent --connect-timeout 10 "http://127.0.0.1:8082/"
Related[edit]
- Cache updates #1957, qubes-updates-cache, qubes-updates-proxy
- design decision: Difficulty to upgrade Whonix TemplateVMs over clearnet considered a bug or feature?
- bug: Templates incorrectly think they're not connected to a Whonix gateway.
Updates Proxy Debugging[edit]
- qubes-updates-proxy (and its deprecated name: qubes-yum-proxy) - a service providing a proxy for templates - by default enabled in NetVMs (especially: sys-net)
- updates-proxy-setup (and its deprecated name: yum-proxy-setup) - use a proxy provided by another VM (instead of downloading updates directly), enabled by default in all templates
Troubleshooting[edit]
See Troubleshooting#Qubes_specific.
Connectivity Issues[edit]
See Troubleshooting#Qubes_specific.
bind-dirs flow chart[edit]
qubes-mount-dirs.service -> /usr/lib/qubes/init/mount-dirs.sh -> /usr/lib/qubes/bind-dirs.sh
qubes-whonix-postinit.service flow chart[edit]
qubes-whonix-postinit.service -> /usr/lib/qubes-whonix/init/qubes-whonix-postinit ->
- /usr/lib/qubes-whonix/bind-directories
- /usr/lib/qubes-whonix/replace-ips
- enable / disable Tor through qvm-service
Qubes-Whonix 14 release testing[edit]
- make sure /etc/systemd/system/multi-user.target.wants/qubes-whonix-firewall.service is gone
- sudo service qubes-whonix-firewall status
- sudo service whonix-firewall status
- Onion Services
lightdm autologin[edit]
sudo kate /etc/lightdm/lightdm.conf.d/user.conf
[SeatDefaults] user-session=xfce autologin-user=user
sudo systemctl enable lightdm
ssh into Qubes dom0[edit]
In dom0. Install socat.
sudo qubes-dom0-update socat
In dom0. Install server software.
sudo qubes-dom0-update openssh-server
sudo systemctl enable sshd
sudo systemctl start sshd
sudo systemctl status sshd
In dom0. Setup qrexec rpc.
Open /etc/qubes-rpc/local.ssh in an editor with root rights.
If you are using a graphical Whonix or Qubes-Whonix, run.
If you are using a terminal-only Whonix, run.
Add.
#!/bin/sh exec socat STDIO TCP-CONNECT:localhost:22
Save.
In dom0. Setup qrexec policy.
Open /etc/qubes-rpc/policy/local.ssh in an editor with root rights.
If you are using a graphical Whonix or Qubes-Whonix, run.
If you are using a terminal-only Whonix, run.
Add.
sys-net dom0 allow
Save.
Start listener in server VM.
Open /rw/config/rc.local in an editor with root rights.
If you are using a graphical Whonix or Qubes-Whonix, run.
If you are using a terminal-only Whonix, run.
Add only required when doing this in sys-net for servers that should be reachable directly from outside world.
iptables -I INPUT -p tcp --dport 22 -j ACCEPT
Add.
socat TCP-LISTEN:22,fork EXEC:"qrexec-client-vm dom0 local.ssh"
Save.
Done.
releasever[edit]
Where/how does one set $relesever?
It is a yum/dnf magic variable - version of package providing system-release.
R3.1 template package in dom0 R3.2[edit]
In UpdateVM.
sudo rm -r /var/lib/qubes/dom0-updates/*
dom0.
sudo dnf remove qubes-template-whonix-ws
dom0.
sudo qubes-dom0-update --clean qubes-template-whonix-ws-3.0.6-201612190633
R3.2: *0628 R3.1: *0633
UEFI[edit]
- https://www.qubes-os.org/doc/uefi-troubleshooting/
- https://groups.google.com/forum/#!topic/qubes-users/Er10fhAR1Ro
yubikey[edit]
yubico tested with Qubes R4 RC1.
1. Install dependencies.
In debian-8 / debian-stretch / whonix-ws TemplateVMs:
Fedora TemplateVM:
2. Shut down TemplateVMs.
3. Reboot TemplateBasedVMs that shall use the yubico.
4. Attach yubikey.
It should show up in Qubes USB systray widget. Use that to assign it to a VM that shall use the yubikey.
Otherwise run on dom0 to see if Qubes knows about it.
Attach. Read command usage help and use from command line.
5. Browser support.
- For Firefox: An add-on would be required. (Untested)
- Chromium (
debian-stretchTemplateBased AppVM): out of the box. (Tested.)
6. Testing:
7. Tested services:
- Googlemail (multiple yubikey's can be added as backups)
Qubes VM debug mode[edit]
Quote Marek https://forums.whonix.org/t/whonix-live-mode/3894/36
Works only with HVM (on PVH or PV you don’t have emulated VGA). Also it enables more verbose logging - shouldn’t affect performance, but syslog in the VM may be hard to read in some cases. No other disadvantages.
See table at the bottom of https://www.qubes-os.org/news/2018/01/24/qsb-37-update/
VM type \ Qubes OS version | 3.2 | 4.0-rc1-3 | 4.0-rc4 | ---------------------------------- | --- | --------- | ------- | Default VMs without PCI devices | PV | HVM | PVH |
Conclusion: Qubes VM debug mode is not the way to go since in Qubes R4 the default for most VMs (that is VMs without PCI devices) (which includes Whonix) is PHV, since these don't have emulated VGA.
salt[edit]
Qubes R3.2[edit]
TODO: document
Qubes R4[edit]
This is whatsudo qubesctl state.sls qvm.anon-whonix does in effect. [11] It does not only do what qvm.anon-whonix does, since salt resolves dependencies. In other words, qvm.anon-whonix starts a chain reaction that includes all of the following.
- install packages from
qubes-templates-community- install
qubes-template-whonix-gw - install
qubes-template-whonix-ws
- install
- create VM called
sys-whonix- with label:
black - with
500MB memory - with
provides_network - enables autostart
- with label:
- create a VM called
anon-whonix- with label:
red - with netvm:
sys-whonix - default-dispvm:
whonix-ws-dvm - add tag
anon-vm
- with label:
- create a VM called
whonix-ws-dvm- as DispVM Template [12]
- with label:
red - with netvm:
sys-whonix - default-dispvm:
whonix-ws-dvm - add tag
anon-vm
- dom0 config changes
- prepend
/etc/qubes-rpc/policy/qubes.UpdatesProxywith the following text
- prepend
whonix-ws $default allow,target=sys-whonix whonix-ws $anyvm deny whonix-gw $default allow,target=sys-whonix whonix-gw $anyvm deny
- prepend
/etc/qubes-rpc/policy/qubes.GetDatewith
- prepend
anon-vm tag[edit]
Qubes dom0 package qubes-core-admin-addon-whonix (forum discussion) is responsible for:
- set NetVM to
sys-whonix[...] - set default DispVM set to
whonix-ws-dvm[...] - set tag
anon-vm
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-core-admin-addon-whonix
Qubes dom0 package qubes-mgmt-salt-dom0-virtual-machines will depend on qubes-core-admin-addon-whonix, therefore ensuring it will be installed. (T792) (#3881)
The template package qubes-whonix ships script /etc/qubes/post-install.d/30-whonix-ws.sh, which contains qvm-features-request whonix-ws=1, which is parsed by dom0 package qubes-core-agent-linux qubes RPC qubes.PostInstall.
As per Marek, qvm-features-request whonix-ws=1 should not be set by salt.
tags inheritance[edit]
Tags are not inherited. Generally settings are not inherited from TemplateVM by TemplateBasedVM. Where needed, core-admin-addon can be made to copy selected settings from TemplateVM to TemplateBasedVM.
Connection through Qubes Updates Proxy[edit]
In Qubes TemplateVM.
R3.2[edit]
R4[edit]
See Also[edit]
- Dev/Test - How to "UnWhonix" - Instructions on how to remove Whonix Tor default networking for Whonix-Gateway. After applying these instructions, Whonix-Gateway will connect to clearnet.
- How to add a ProxyVM between anon-whonix and sys-whonix? (whonix-ws-email -> sys-fw-whonix -> whonix-gw -> sys-firewall -> sys-net)
Footnotes[edit]
- ↑ Upon creation.
- ↑ Following shutdown.
- ↑ https://github.com/QubesOS/qubes-issues/issues/1015
- ↑
https://groups.google.com/d/msg/qubes-users/zHdY6Oe58t0/qSFkLZdpng4J
Actually you need rpmfusion-free-release-20.noarch.rpm, as Qubes dom0 is based on Fedora 20.
- ↑
- ↑
https://blog.torproject.org/blog/tor-browser-50-released
Starting with this release, Tor Browser will now also download and apply upgrades in the background, to ensure that users upgrade quicker and with less interaction. This behavior is governed by the about:config pref app.update.auto, but we do not recommend disabling it unless you really know what you're doing.
- ↑ Qubes issue ticket: Mechanism for triggering template build
- ↑ https://github.com/Whonix/whonix-developer-meta-files/blob/master/release/qubes-templates-offical-build-commands
- ↑ https://groups.google.com/d/msg/qubes-devel/uzgN42uEJpE/hymUCMxoCwAJ
- ↑ https://github.com/Whonix/qubes-whonix/blob/master/lib/systemd/system/qubes-firewall.service.d/40_qubes-whonix.conf
- ↑ https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/
- ↑
template-for-dispvms: true - ↑ https://github.com/QubesOS/qubes-core-admin/pull/214#issuecomment-399698122
There are five different options for subscribing to Whonix source code changes.
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.
Whonix is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Libre Software license as Whonix itself. (Why?)