qvm-sync-clock causes netvm to start on the hour

[tasket]

Qubes OS version:

R4.0rc4

---

Steps to reproduce the behavior:

Shutdown networked VMs, including default netvm (sys-net), i.e. system is in a defacto 'offline' state.

Expected behavior:

Netvm remains shutdown/not running.

Actual behavior:

ClockVM starts, which is sys-net or something that depends on a networkVM. This happens each hour.

General notes:

I think preferred behavior would be not to use --autostart and quietly avoid updating from the network if no networkVMs are running.

This is with an eye toward managing sets of VMs that run according to exclusion rules (notably, networkVMs would be the most excluded).

But even before that's a reality, having your networkVM suddenly start is unsettling if you have shutdown all your networked VMs and intend to work offline for a time. It seems like a potential security and privacy risk to automatically enable NICs (esp radio) from an unseen background process.

---

Related issues:

#2866

[rustybird]

I have a patch for dom0 qvm-sync-clock to bail out if the clockvm isn't already running. But how to do the same for VM qvm-sync-clock?

[rustybird]

I have a patch for dom0 qvm-sync-clock to bail out if the clockvm isn't already running. But how to do the same for VM qvm-sync-clock?

[marmarek]

I see two options (or a combinations of them):

• a VM property whether it should be started on qrexec call (in this case qubes.GetDate)
• a qrexec call setting (argument for allow action in policy?) whether it should start target VM if not running

In any case, explicit qvm-start (admin.vm.Start Admin API call) would start a VM. I think selecting such VM as a target in qrexec confirmation window should also start the VM, regardless of the settings above.

[marmarek]

I see two options (or a combinations of them):

• a VM property whether it should be started on qrexec call (in this case qubes.GetDate)
• a qrexec call setting (argument for allow action in policy?) whether it should start target VM if not running

In any case, explicit qvm-start (admin.vm.Start Admin API call) would start a VM. I think selecting such VM as a target in qrexec confirmation window should also start the VM, regardless of the settings above.

[rustybird]

An optional autostart=no|yes qrexec policy parameter raising AccessDenied on no if the resolved target is not running would satisfy everything (because you simply don't set it for an admin.vm.Start call or ask action), fit into the existing param_name=value syntax, and allow exceptions for individual VMs.

But it might take me a while to start working on it, and I'm not really familiar with the qubespolicy code. Maybe someone else wants to take this?

[rustybird]

An optional autostart=no|yes qrexec policy parameter raising AccessDenied on no if the resolved target is not running would satisfy everything (because you simply don't set it for an admin.vm.Start call or ask action), fit into the existing param_name=value syntax, and allow exceptions for individual VMs.

But it might take me a while to start working on it, and I'm not really familiar with the qubespolicy code. Maybe someone else wants to take this?

[tasket]

Since the undesired event is triggered by dom0, could this be addressed simply by adding an autostart=True default parameter to app run_service() and have qvm-sync-clock specify False?

[tasket]

Since the undesired event is triggered by dom0, could this be addressed simply by adding an autostart=True default parameter to app run_service() and have qvm-sync-clock specify False?

[marmarek]

Since the undesired event is triggered by dom0

Not really, calling qvm-sync-clock in VM will also cause this. And it is scheduled for automatic call. Or rather should be: QubesOS/qubes-core-agent-linux#96

[marmarek]

Since the undesired event is triggered by dom0

Not really, calling qvm-sync-clock in VM will also cause this. And it is scheduled for automatic call. Or rather should be: QubesOS/qubes-core-agent-linux#96

[tasket]

I see. In that case the suggested policy parameter would work in most cases where clockvm=networkvm.

However, it may be better to have a dom0 rpc script handle the call for qubes.GetDate and trace netvm dependencies from clockvm to networkvm first. If networkvm isn't running, return a date sourced from dom0. Then isolated vms won't have any obvious sign about the system networking state.

[tasket]

I see. In that case the suggested policy parameter would work in most cases where clockvm=networkvm.

However, it may be better to have a dom0 rpc script handle the call for qubes.GetDate and trace netvm dependencies from clockvm to networkvm first. If networkvm isn't running, return a date sourced from dom0. Then isolated vms won't have any obvious sign about the system networking state.

[andrewdavidwong]

having your networkVM suddenly start is unsettling if you have shutdown all your networked VMs and intend to work offline for a time. It seems like a potential security and privacy risk to automatically enable NICs (esp radio) from an unseen background process.

In the era of Meltdown and Spectre, it seems like an undeniable security risk.

[andrewdavidwong]

having your networkVM suddenly start is unsettling if you have shutdown all your networked VMs and intend to work offline for a time. It seems like a potential security and privacy risk to automatically enable NICs (esp radio) from an unseen background process.

In the era of Meltdown and Spectre, it seems like an undeniable security risk.

[rustybird]

In the era of Meltdown and Spectre, it seems like an undeniable security risk.

Yup. A workaround (which of course only helps users aware of this issue) would be to remember doing qubes-prefs -s clockvm '', or its GUI equivalent, when working offline. But there's a similar problem for VM update checks, and more broadly for any RPC that somehow triggers a netvm startup.

[rustybird]

In the era of Meltdown and Spectre, it seems like an undeniable security risk.

Yup. A workaround (which of course only helps users aware of this issue) would be to remember doing qubes-prefs -s clockvm '', or its GUI equivalent, when working offline. But there's a similar problem for VM update checks, and more broadly for any RPC that somehow triggers a netvm startup.

[tasket]

What if clockvm was a property for use by dom0 only, and guest VMs just got the time from dom0? Then dom0 could check the time periodically if the associated networkVM is already running.

[tasket]

What if clockvm was a property for use by dom0 only, and guest VMs just got the time from dom0? Then dom0 could check the time periodically if the associated networkVM is already running.

[rustybird]

I suppose the clockvm might want to do things that are too complicated to hardcode into dom0, e.g. give out a slightly randomized time to each caller.

[rustybird]

I suppose the clockvm might want to do things that are too complicated to hardcode into dom0, e.g. give out a slightly randomized time to each caller.

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.24-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.24-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.24-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.24-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[esote]

@marmarek I am currently experiencing this issue, even though I have qubes-core-dom0-4.0.24-1.fc25 from the default current repository. Was this not fixed in 4.0.24-1?

[esote]

@marmarek I am currently experiencing this issue, even though I have qubes-core-dom0-4.0.24-1.fc25 from the default current repository. Was this not fixed in 4.0.24-1?

[trueriver]

My preference would be an option under "provides network" in each qubes settings that "Allow start when other VMs ask for this network". Option would be ignored/greyed out if the VM did not provide network for anyone else. This would be a three way radio button "Always", "Ask each time", "Never"

My suggestion is that the default on installtion would be "Ask each time".

The less-secure but user friendly option would be to set this to Always by default, so that current behaviour is maintained unless a user overrides it.

The advantage of my design is that users could allow some network qubes to start on demand, but make sure others that may be sensitive in their current location do not expose them to unwelcome scrutiny.

Example user may be happy to connect to the wifi at an internet cafe from one VM, but not want another VM to start a tor connection when in a country where tor is unwelcome.

I cannot comment on the technical feasibility of what I am asking, nor any adverse security consequences that I have not noticed. I DO think that the current settings are inherently risky for some users in some situations.

[trueriver]

My preference would be an option under "provides network" in each qubes settings that "Allow start when other VMs ask for this network". Option would be ignored/greyed out if the VM did not provide network for anyone else. This would be a three way radio button "Always", "Ask each time", "Never"

My suggestion is that the default on installtion would be "Ask each time".

The less-secure but user friendly option would be to set this to Always by default, so that current behaviour is maintained unless a user overrides it.

The advantage of my design is that users could allow some network qubes to start on demand, but make sure others that may be sensitive in their current location do not expose them to unwelcome scrutiny.

Example user may be happy to connect to the wifi at an internet cafe from one VM, but not want another VM to start a tor connection when in a country where tor is unwelcome.

I cannot comment on the technical feasibility of what I am asking, nor any adverse security consequences that I have not noticed. I DO think that the current settings are inherently risky for some users in some situations.

[jpouellet]

Check your /etc/qubes-rpc/policy/qubes.GetDate in dom0.

It should contain target=dom0, but probably still contains target=sys-net.

See also #3941

[jpouellet]

Check your /etc/qubes-rpc/policy/qubes.GetDate in dom0.

It should contain target=dom0, but probably still contains target=sys-net.

See also #3941

[tasket]

This is still occurring for me, despite having target=dom0 in qubes.GetDate.

[tasket]

This is still occurring for me, despite having target=dom0 in qubes.GetDate.

[esote]

@jpouellet @tasket @marmarek Same for me with latest qubes-core-dom0-4.0.27-1.fc25, with target=dom0 in qubes.GetDate. If this was truly fixed in 4.0.24-1 (has this been confirmed to fix it for anyone?), could other components be starting sys-net hourly?

[esote]

@jpouellet @tasket @marmarek Same for me with latest qubes-core-dom0-4.0.27-1.fc25, with target=dom0 in qubes.GetDate. If this was truly fixed in 4.0.24-1 (has this been confirmed to fix it for anyone?), could other components be starting sys-net hourly?