make Qubes-Whonix-Gateway able to function as UpdateVM out of the box

[phabricator-migrator]

Information

ID: 401
PHID: PHID-TASK-lm6pj7hotfoslhwrmrza
Author: Patrick
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

Currently still manual tweaking is required.

---

a) qubes-prefs --set updatevm whonix-gw
b) Using whonix-gw as ProxyVM for TemplateVMs.

For a), to implement this, creating a #uwt wrapper for yum could be sufficient.

For b), not sure yet.

---

Recent forum discussion:

Whonix Forum

Related Qubes ticket:

high-level target: templates should default update over Tor

Dev wiki:

Dev/Qubes

Comments

---

Patrick

2015-09-03 13:10:54 UTC

added Tor SocksPort 9125 for yum:
added Tor SocksPort 9125 for yum · Whonix/anon-gw-anonymizer-config@a2aa9e9 · GitHub

added Tor SocksPort 9125 for yum:
https://github.com/Whonix/whonix-gw-firewall/commit/d6401bb5e310504a454ee2d65b8b3d46b4dbfdb3

added stream isolation wrapper for yum:
added stream isolation wrapper for yum · Whonix/uwt@e86f349 · GitHub

---

Patrick

2015-09-03 13:36:59 UTC

added stream isolation wrapper for yumdownloader:
added stream isolation wrapper for yumdownloader · Whonix/uwt@ddc9fbc · GitHub

---

Patrick

2015-09-03 15:08:41 UTC

I think the 4 above commits made a), qubes-prefs --set updatevm whonix-gw possible. I was able to use dom0 sudo qubes-dom0-update now. Needs more testing. yum and yumdownloader can now connect through Tor on Qubes-Whonix-Gateway without manual configuration. (Whonix-Gateway does not provide a TransPort, i.e. there is no default fallback system DNS / TCP. All applications need to be configured to use a Tor SocksPort or be forced by uwt.) [I might have run into unrelated issues. (https://github.com/marmarek/qubes-core-agent-linux/pull/25)]

For this to work, the only things requiring network access, are only yum and yumdownloader in qubes-download-dom0-updates.sh, right? @marmarek

---

Patrick

2015-09-03 16:57:57 UTC

a) Works. sudo qubes-dom0-update works now. Installing an arbitrary package sudo qubes-dom0-update qubes-template-debian-7 also worked.

b) Already worked. As one would expect. Configured the Debian and Fedora TemplateVMs to use Qubes-Whonix-Gateway as NetVM. Updates were possible.

Are there any other test cases I should cover?

---

marmarek

2015-09-03 17:00:16 UTC

(resending)

re: yum + yumdownloader the only network accessing tool:

Yes, but note that there are more call to them there. How that wrapper
works? Is it placed instead of /usr/bin/yum?

Ah, qubes-dom0-update calls qvm-sync-clock first, but this is
probably irrelevant here. And independent thing to rework.

---

Patrick

2015-09-03 17:13:41 UTC

! In T401#6629, @marmarek wrote:
(resending)

re: yum + yumdownloader the only network accessing tool:

Yes, but note that there are more call to them there. How that wrapper
works? Is it placed instead of /usr/bin/yum?

Short answer:
No modifications of any Qubes scripts required. /usr/bin/yum gets replaced.

Longer answer:
“Like other #uwt wrappers.” /usr/bin/yum is a symlink to /usr/bin/yum.anondist.
(uwt/usr/bin/yum.anondist at master · Whonix/uwt · GitHub)
(using config-package-dev)
It will exec to uwtwrapper.
(https://github.com/Whonix/uwt/blob/master/usr/lib/uwtwrapper)
It determines destination ip/port, config and other relevant stuff.
Which will then exec to uwt, which will then exec to torsocks.
(uwt is required, because torsocks does not support stream isolation by ip/destination port. [upstream feature request existing])

Ah, qubes-dom0-update calls qvm-sync-clock first, but this is
probably irrelevant here. And independent thing to rework.

Yes. This doesn’t interfere here, because T384 was implemented. T397 remains TODO, but is an issue on a different level.

---

Patrick

2015-09-03 20:29:59 UTC

There is an issue with qubes-dom0-update with user output. (Purposely set the time into future for unrelated tests while testing this.) During…

qvm-run -p sys-whonix 'tar x -C /var/lib/qubes/dom0-updates'

It may show multiple times (in red color)…

tar: var/lib/rpm/__db.01: time stamp 2015-09-03 19:47:29 is 63.278026948 s in future

---

Patrick

2015-09-03 20:32:53 UTC

I thought, why not just add 2>/dev/null. That hides it. Created a pull request…
dracut: Omit network and kernel-network-modules by m-v-b · Pull Request #1 · marmarek/qubes-core-admin-linux · GitHub
What do you think?

---

marmarek

2015-09-03 20:47:55 UTC

I think it isn’t the best option - indeed such warning are not really
useful, but that would hide also errors (for example “No space left on
device”), so would be harder to find out what failed.

Also, this is exactly why there is qvm-sync-clock call.

Maybe there is a way to filter out just those messages? I can’t find an
option for that. Some grep (and make sure LC_MESSAGES=C)?

---

Patrick

2015-09-04 00:23:03 UTC

Agreed.

Here is a proof of concept filtering this out using grep. (Missing LC_MESSAGES=C.)
made variables configureable through environment by adrelanos · Pull Request #2 · marmarek/qubes-core-admin-linux · GitHub

But using grep increases dom0 attack surface or are there already other cases where dom0 grep processes VM data so this does not matter?

If so, I could try write a tar wrapper that runs within the VM that filters out that message.

---

Patrick

2015-09-04 00:57:42 UTC

New pull request:
install-kernel: handle custom EFI directory by marmarek · Pull Request #3 · marmarek/qubes-core-admin-linux · GitHub