Page MenuHomePhabricator

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

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:
https://www.whonix.org/forum/index.php/topic,1578.0.html

Related Qubes ticket:
https://github.com/QubesOS/qubes-issues/issues/1159

Dev wiki:
https://www.whonix.org/wiki/Dev/Qubes#UpdateVM

Details

Impact
Normal

Event Timeline

Patrick created this task.Sep 3 2015, 2:54 PM
Patrick updated the task description. (Show Details)
Patrick raised the priority of this task from to Normal.
Patrick added projects: Whonix 12, Qubes, uwt.
Patrick set Impact to Normal.
Patrick added subscribers: Patrick, nrgaway, marmarek, mfc.
Patrick updated the task description. (Show Details)Sep 3 2015, 3:25 PM

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 changed the task status from Open to Review.Sep 3 2015, 6:57 PM

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?

(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.

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.
(https://github.com/Whonix/uwt/blob/master/usr/bin/yum.anondist)
(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 changed the task status from Review to Open.EditedSep 3 2015, 10:27 PM

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

I thought, why not just add 2>/dev/null. That hides it. Created a pull request...
https://github.com/marmarek/qubes-core-admin-linux/pull/1
What do you think?

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)?

Agreed.

Here is a proof of concept filtering this out using grep. (Missing LC_MESSAGES=C.)
https://github.com/marmarek/qubes-core-admin-linux/pull/2

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 closed this task as Resolved.Sep 8 2015, 5:40 PM
Patrick claimed this task.