Template policy, services->features, core plugins

[woju]

Some templates, like whonix-ws, may like to impose some policies unto their appvms. (The example, discussed here, is time synchronisation — by default Whonix should not receive current time from dom0 for privacy reasons).

Those policies will be expressed as some plugins/enhacements to the core-admin. The logic (and program flow) of such plugins will contain that policy. Policy may be influenced by domain's properties (which are hardcoded into core) or "features", an expansion of the previous (core1-2) concept of "services". Features is a dictionary (key-value store), with keys being subset of ASCII and values being UTF-8 encoded strings. Value may be an empty string or the entire key-value pair may be absent.

During installation, template is started and it may perform some qrexec rpc calls. There should be one call (it is currently called qubes.NotifyTools), which when called signals to the plugins that there are some qubesdb entries updated, that should help the plugin to set the policy and maybe store it in domain's properties and/or features.

Then some tools, when faced with policy decision, may make decision based on the features of the domains in store. It is expressly allowed to make decisions based on properties/features of other domains, like domain's template or netvm.

Features may be shared between plugins/subsystems (i.e. plugin/tool may make decisions based on features kept by other tool/plugin), like in /proc/cmdline.

Anything missing?

/cc @marmarek

[woju]

How that fits our previous conversation about qrexec policy?

[marmarek]

Another use case for this mechanism would be Windows VMs, with Qubes Windows Tools being installed, or not. When it calls qubes.NotifyTools, some plugin will handle that to record the fact that tools are installed and the next time (or even this time?) VM should have proper GUI daemon started, possible to enable seamless mode etc.

How that fits our previous conversation about qrexec policy?

I think it is mostly orthogonal, as new qrexec policy (#867, #865) is mostly about calls made from VMs qubes, but here we are talking about mostly qubes settings and calls made to qubes. At best, those "features" discussed here may be (some of) factors being considered by qrexec policy.

[marmarek]

Related to: #1323

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.0-1.fc24 has been pushed to the r4.0 testing repository for the Fedora fc24 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.0-1.fc25 has been pushed to the r4.0 testing repository for the Fedora fc25 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.0-1+deb8u1 has been pushed to the r4.0 testing repository for the Debian jessie template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing jessie-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.0-1+deb9u1 has been pushed to the r4.0 testing repository for the Debian stretch template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update