-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Template policy, services->features, core plugins #1637
Comments
How that fits our previous conversation about qrexec policy? |
Another use case for this mechanism would be Windows VMs, with Qubes Windows Tools being installed, or not. When it calls
I think it is mostly orthogonal, as new qrexec policy (#867, #865) is mostly about calls made from |
Related to: #1323 |
The function qdb_init() should get NULL but instead it got uninitalised local variable, since PyArg_ParseTuple does not touch pointers to omitted argumets. QubesOS/qubes-issues#1637
The function qdb_init() should get NULL but instead it got uninitalised local variable, since PyArg_ParseTuple does not touch pointers to omitted argumets. QubesOS/qubes-issues#1637
The function qdb_init() should get NULL but instead it got uninitalised local variable, since PyArg_ParseTuple does not touch pointers to omitted argumets. QubesOS/qubes-issues#1637 (cherry picked from commit 9e9dfc9)
And place them in /qubes-service/ QubesDB directory. This allows extensions to easily store some data not exposed to VM, but also have control what VM will see. And at the same time, it make it compatible with existing services framework QubesOS/qubes-issues#1637
And place them in /qubes-service/ QubesDB directory. This allows extensions to easily store some data not exposed to VM, but also have control what VM will see. And at the same time, it make it compatible with existing services framework QubesOS/qubes-issues#1637
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
|
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 fromdom0
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
The text was updated successfully, but these errors were encountered: