Need a (safe) way to update installed qrexec policy when the defaults change

[jpouellet]

When we update the desired defaults for qrexec policies, package updates do not override the installed configuration. Obviously this is an easy solution to avoid accidental overwriting user-specified behavior (good, and very important), but it also means users can get out of sync policy causing subtle bugs (bad) or in the worst case result in potentially vulnerable configuration if a bug in policy is fixed (very bad).

One example of where this showed up is with the switch of target from sys-net to dom0 for qubes.GetClock. See this commit and issues #3588 & #3940. There are likely other bugs ultimately caused by this too which I have not identified.

Careful thought is required to avoid re-allowing behavior which was explicitly forbidden by the user (e.g. clipboard or file copy or such) as well as denying previously allowed actions (e.g. split-gpg, etc.) as are both undesirable failure modes.

Something involving comparing to previous defaults and involving manual user inspection of the result if it had been modified from defaults comes to mind, but I have not taken the time to fully think through all the implications.

[marmarek]

This is widespread issue I haven't seen fully satisfying solution yet. Most package managers leave config updates to the user - rpm create .rpmnew files, dpkg - .dpkg-new, etc. If the file was unchanged, it is replaced directly, but otherwise, the user need to merge the changes manually, which is far from optimal.

We have an developing idea of implementing .d approach for qrexec policy, but it isn't fully formed yet. Expect related qubes-devel thread in coming weeks.

[marmarek]

This is widespread issue I haven't seen fully satisfying solution yet. Most package managers leave config updates to the user - rpm create .rpmnew files, dpkg - .dpkg-new, etc. If the file was unchanged, it is replaced directly, but otherwise, the user need to merge the changes manually, which is far from optimal.

We have an developing idea of implementing .d approach for qrexec policy, but it isn't fully formed yet. Expect related qubes-devel thread in coming weeks.