GSoC 2026 – Expression of interest: Mechanism for maintaining in-VM configuration

[Elias]

Hi Frédéric and the Qubes team,

I'm Elias, a Computer Science student at Leipzig University (5th semester, B.Sc.), currently finishing an internship at KPMG in Cyber Security Consulting.

I'm interested in the "Mechanism for maintaining in-VM configuration" project. What draws me to it specifically is the security challenge at its core: designing a synchronization mechanism that is resistant against malicious VMs attempting to enforce unwanted configuration changes. This whitelist-based trust model is something I have already considered in practice: at GISA GmbH, I monitored SIEM systems and analyzed security incidents, and at KPMG, I worked on the automation of governance, risk, and compliance processes. Both require precisely this kind of thinking: "Who is allowed to send what?"

Technically, my current understanding is that the synchronization logic should live in a dedicated management qube, using qrexec policies in dom0 to enforce a strict whitelist of which VMs can propagate which config paths. This avoids dom0 complexity while keeping the trust boundary clear.

I have a few open questions before I draft my proposal:
1. Is a dedicated management qube the preferred architecture, or should this be dom0-controlled?
2. Are there specific dotfile paths (e.g. ~/.config/git, ~/.ssh/config) that should be explicitly out of scope for security reasons?
3. I searched the issue tracker but could not find an existing issue directly related to this project. Is this a greenfield implementation, or is there prior work I might have missed?

I am already working on familiarizing myself with the qubes-os codebase and plan to submit a small contribution this week.

Best regards,
Elias Masur
elias...@gmail.com
https://github.com/EliasDevv

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Mar 15, 2026 at 11:38:29AM +0100, Elias wrote:
> Hi Frédéric and the Qubes team,

Hello,

> I'm Elias, a Computer Science student at Leipzig University (5th semester,
> B.Sc.), currently finishing an internship at KPMG in Cyber Security
> Consulting.
>
> I'm interested in the "Mechanism for maintaining in-VM configuration"
> project. What draws me to it specifically is the security challenge at its
> core: designing a synchronization mechanism that is resistant against
> malicious VMs attempting to enforce unwanted configuration changes. This
> whitelist-based trust model is something I have already considered in
> practice: at GISA GmbH, I monitored SIEM systems and analyzed security
> incidents, and at KPMG, I worked on the automation of governance, risk, and
> compliance processes. Both require precisely this kind of thinking: "Who is
> allowed to send what?"

While thinking about it, you may also want to read about the new-ish
"custom-persist" feature. It isn't exactly the same, but may be useful
in this project, or may be an inspiration to some ideas:
https://dev.qubes-os.org/projects/core-admin-client/en/latest/manpages/qvm-features.html#custom-persist

> Technically, my current understanding is that the synchronization logic
> should live in a dedicated management qube, using qrexec policies in dom0
> to enforce a strict whitelist of which VMs can propagate which config
> paths. This avoids dom0 complexity while keeping the trust boundary clear.
>
> I have a few open questions before I draft my proposal:
> 1. Is a dedicated management qube the preferred architecture, or should
> this be dom0-controlled?

Generally, storing data originating from a VM in dom0 is a risk.
Sometimes it's unavoidable, but if possible better not. And also,
dom0-based approach usually ends up not immediately compatible with GUI
domain.

> 2. Are there specific dotfile paths (e.g. ~/.config/git, ~/.ssh/config)
> that should be explicitly out of scope for security reasons?

One challenge of this project is to design it to still enforce desired
isolation. I can see users wanting to synchronize their favorite git
settings (for example aliases, colors etc) between qubes - but also, if
a qube manages to inject malicious modification of ~/.gitconfig into
another qube, that would be a problem. So, fetching a config file from a
qube, to be shared with others, is a risky operation, and needs some
extra care (maybe allow only from some dedicated qube that isn't
processing any untrusted data? or maybe design some review process that
would make it easy for the user to spot issues? I'm not sure, that's a
challenge for you to propose solution :) ).

> 3. I searched the issue tracker but could not find an existing issue
> directly related to this project. Is this a greenfield implementation, or
> is there prior work I might have missed?

Some people use management stack for that, we support:
- - salt: https://doc.qubes-os.org/en/latest/user/advanced-topics/salt.html
- - ansible: https://github.com/QubesOS/qubes-ansible/?tab=readme-ov-file#ansible-plugins-for-qubesos

But both are quite complex to use, and kinda an overkill for just
copying a bunch of files around. That's why this project idea exists.

> I am already working on familiarizing myself with the qubes-os codebase and
> plan to submit a small contribution this week.

Nice, I've noticed some of your pull requests already :)

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmm3esEACgkQ24/THMrX
1yzHNgf/anY2fNyvAmpuVwozcI+X4/jol3bR1SO7jH6TkDOUCapN0v2SmnKQgWpN
DYLKJNBMTfXH6Ru1wdCkxGnt9dCBdGzFNGn+pgZZYRu2S6CBlLiX5O2qAB3otlx7
5ZBTBjddOUvY75clDha3VGZC1hfjgSGg4dI+WUeKPaGrQDI2BFSTCrvwn6pq0Wmb
4ZkWE6WOQuT64I84AuqkxSQr3zn5y47TL8rEVUAdNM7ybrW3+7Ttz/Ysis2CPrJ7
/y+pl43s6WfqKWUUjx+N7SNqx/9AbVO7yszxjzC1+SqdOZ7YF/ZT3Ubtk4IDdL+C
pcfW8PaeUxuNdkkrdvcRZ5LfbwCeDg==
=2kGl
-----END PGP SIGNATURE-----

[Elias]

Hi Marek,

Thank you for the detailed response and for the pointer to custom-persist. I've read through the documentation and I can see how it could serve as a foundation for the synchronization mechanism, particularly the idea of persisting specific paths across qube restarts.

Regarding the security challenge you described: I think a review-based approach makes the most sense from a usability perspective. My current idea would be to design a dedicated "config-source" qube that is explicitly marked as trusted for configuration distribution. Any config file fetched from this qube would first be presented to the user in a diff-style review interface before being applied to the target qube. This way, even if another qube is compromised, it cannot directly push changes. It can only propose them, and the user has full visibility.

For the qrexec policy, my plan is to enforce a strict whitelist: only the designated config-source qube is allowed to send configuration updates, and only to explicitly whitelisted target qubes and paths.

I will study the custom-persist implementation more closely and incorporate these ideas into my proposal draft. I'll share a draft here for feedback before the submission deadline.

Best regards,
Elias Masur