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

[Elias]

Hi Marek and QUBES OS team,

I am currently finalizing my GSoC proposal. Before I submit my proposal, I wanted to make sure the core technical architecture aligns perfectly with your expectations.

I have drafted the Introduction, the Project Goals, and the exact Implementation details (including the staging area, the diff-review GUI, and the custom-persist integration) here:
https://docs.google.com/document/d/13sT0Gtc-ACYc_1nBBhWY4cCvFZ6vrrkPWmRjZAvxP-o/edit?usp=sharing 

I have enabled commenting on the document. Could you take a quick look to see if this approach fits the Qubes OS threat model, or if there is anything fundamental you would change in the architecture before I submit the complete proposal? In the meantime, I will continue exploring the codebase and plan to submit a few more small PRs to get fully accustomed to the Qubes contribution and review workflow.

Best regards, 
Elias

[Ben Grande]

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

On 26-03-18 22:53:13, Elias wrote:
> Hi Marek and QUBES OS team,
>
> I am currently finalizing my GSoC proposal. Before I submit my proposal, I
> wanted to make sure the core technical architecture aligns perfectly with your
> expectations.
>
> I have drafted the Introduction, the Project Goals, and the exact
> Implementation details (including the staging area, the diff-review GUI, and
> the custom-persist integration) here:
> https://docs.google.com/document/d/13sT0Gtc-ACYc_1nBBhWY4cCvFZ6vrrkPWmRjZAvxP-o
> /edit?usp=sharing 

The problem of doing the review on a document you share is that anything
we say might be lost in the future and it makes it not searcheable in
the mailing list.

One comment I have is that not all qubes might have a GUI, so there
needs to be a mechanism that works without it.

> I have enabled commenting on the document. Could you take a quick look to see
> if this approach fits the Qubes OS threat model, or if there is anything
> fundamental you would change in the architecture before I submit the complete
> proposal? In the meantime, I will continue exploring the codebase and plan to
> submit a few more small PRs to get fully accustomed to the Qubes contribution
> and review workflow.

- --
Best regards,
Benjamin Grande

Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQRklnEdsUUe50UmvUUbcxS/DMyWhwUCab9flAAKCRAbcxS/DMyW
hyTkAPsFIWku/UryXb7ossAPX3G+xw4Mh/x1ieYdeJLUSTEjlAD/VMqWCJHrDTKA
//JaBaIk5vMzgRnsBOpEPJi9O8jm/ww=
=tnJ5
-----END PGP SIGNATURE-----

[Elias]

Hi,
Thank you for your feedback Benjamin. I totally forgot about that and you are absolutely right about it.

Your comment about Qubes without a graphical user interface is very helpful, and I hadn't considered this aspect in my initial draft. To resolve this issue, I will implement a CLI fallback mechanism. If the script detects that no display server is running, the diff will be displayed via the terminal, and a standard [y/N] prompt will appear for confirmation instead of opening a GTK dialog. I have included this in the implementation details.

Here is the full text of my current architecture draft for the mailing list archive:

#Introduction

Managing a large number of virtual machines in Qubes OS poses a significant challenge to usability in terms of user-specific configurations. TemplateVMs efficiently handle system-wide updates, while user-level dotfiles (such as the contents of ~/.bashrc, ~/.gitconfig, or ~/.config/) are located in the AppVM’s home directory. As a result, users currently have to either manually synchronize these files across multiple Qubes or rely on comprehensive management tools such as Salt or Ansible. For the average user, however, setting up an Ansible playbook is overkill when the goal is simply to deploy a Git alias or a shell theme, and is often too complex to maintain.

The main challenge is to safely copy a file from one Qube to another without violating Qubes’ isolation model. A naive synchronization approach poses a significant security risk, as a compromised Qube could silently overwrite configurations (e.g., ~/.gitconfig) in other Qubes, potentially compromising the entire system or additional Qubes. Furthermore, routing such file transfers through dom0 unnecessarily increases the attack surface of the domain with the highest privileges. To address this issue, my project proposes a lean, secure and user-friendly synchronization mechanism. A special, offline “config-mgmt” Qube is used as the single source of trust for configurations. By using a strict, whitelist-based qrexec policy in dom0, this management Qube can securely transfer configuration files to target VMs. To mitigate the risk of malicious changes and ensure data persistence, the solution incorporates a GUI-based diff review process before changes are applied and uses the Qubes “custom-persist” feature to ensure that dotfiles are preserved even after the AppVM is rebooted.

My proposal is based on the concept outlined in the official GSoC project ideas list, as well as on the preliminary discussion regarding the architecture with Marek Marczykowski-Górecki on the “qubes-devel” mailing list: https://groups.google.com/u/1/g/qubes-devel/c/GCNoHQexYrE.

#Project goals

This project aims to deliver a functional, secure, and documented synchronization mechanism tailored for user configurations. 

List of Deliverables:

• Architecture Design: Setup of a dedicated, network-disconnected config-mgmt AppVM acting as the trusted source.

• Qrexec Service: Implementation of a new qrexec service (e.g., qubes.SyncConfig) with a strict whitelist policy in dom0 (ensuring no file data is stored in dom0).

• Secure Review Mechanism: A GTK/Zenity-based GUI prompt in the target VM that displays a diff of the proposed changes, requiring explicit user consent before any file is overwritten.

• Persistence Integration: Integration with the custom-persist feature (or bind-dirs) so that synchronized files outside the /home directory survive standard AppVM reboots.

• User Documentation: Clear documentation on how to securely set up the config-mgmt qube, configure the whitelist, and use the tool.

What I do plan not to do:

• I will not build a full configuration management system. This tool is explicitly designed for lightweight file synchronization and will not replace Salt or Ansible for complex system administration tasks.

#Implementation

To ensure a secure and resource-efficient synchronization process, the implementation will strictly separate the transport layer from the logic and enforce a robust verification process on the receiving end. The architecture is based entirely on native Qubes OS mechanisms (qrexec and AppVM isolation) instead of external, resource-intensive third party automation tools.

1. Automation & Trust Model

The system relies on a dedicated AppVM for configuration management. To minimize the risk of compromise, this Qube should be created without NetVM (offline) and serve exclusively as a trusted source for user configurations. Dom0 is used solely to forward qrexec calls and enforce policies. At no point are user data or configuration files stored in or processed by dom0.

2. Qrexec Policy & Data Flow

I will introduce a new qrexec RPC service, e.g., qubes.SyncConfig. The corresponding dom0 policy will follow a strict whitelist approach: 

qubes.SyncConfig * config-mgmt @anyvm ask 

(Alternatively, power users can explicitly whitelist target VMS like work-vm to allow without a dom0 prompt, relying on the in-VM review instead. The data flow is initiated from the config-mgmt qube: 

qrexec-client-vm <target-vm> qubes.SyncConfig < payload.tar

The payload will contain the relative paths and the file contents to be synchronized.

3. Staging and Path Validation (Security Core)

When the target VM receives the data via the qubes.SyncConfig service, it will never overwrite existing files immediately. This prevents a compromised source from instantly injecting malicious code (e.g., into ~/.bashrc).

• Staging: The python-based RPC service in the target VM will unpack the payload into a secure temporary directory (e.g., /tmp/qubes-config-sync/).

• Path Traversal Prevention: The script will strictly validate all incoming file paths using python’s os.path.abspath and os.path.commonpath to ensure that no file attempts to escape the designated configuration directories (e.g., preventing paths like ../../../etc/shadow).

4. The Diff-Review GUI (User Consent)

To address the risk of malicious configuration distribution (e.g., compromised ~/.gitconfig aliases), the target VM will execute a review process before applying any changes:

1. The python script generates a unified diff between the staged file and the currently active file.

2. It triggers a lightweight, native GTK or Zenity-based dialog within the target VM: “The qube ‘config-mgmt’ proposed changes to ~/.gitconfig. Review differences:”

3. The diff is displayed to the user.

4. Only upon explicit user confirmation, the script moves the staged file to its final destination.

The CLI fallback for Qubes without a GUI does not run on all target VMs that lack a display server (e.g., minimal templates or server VMs). To detect this, the script actively checks whether a graphical environment is available. If no display server is found, it falls back to a standard terminal interface, displays the Unified Diff directly in the CLI, and prompts for a standard confirmation [y/N].

Thanks again for your guidance! Let me know if you see any other areas that need refinement.

Best regards,
Elias

[Elias]

Hi Marek, Benjamin, and the Qubes OS team,
As the deadline is approaching, I would like to share another draft for review to officially submit my proposal after a feedback.
I have attached the PDF draft to this email. It includes the updated architecture (with the CLI fallback we discussed), the complete timetable, the introduction and the project goals section.
Could you take one final look at the attached PDF? I would especially appreciate a quick check on the timetable and the overall scope to ensure everything is realistic and aligns with your expectations.
If everything looks good from your side, I will go ahead and submit the final version.

Best regards,
Elias

[Marek Marczykowski-Górecki]

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

On Wed, Mar 25, 2026 at 10:35:19PM -0700, Elias wrote:
> Hi Marek, Benjamin, and the Qubes OS team,
> As the deadline is approaching, I would like to share another draft for
> review to officially submit my proposal after a feedback.
> I have attached the PDF draft to this email. It includes the updated
> architecture (with the CLI fallback we discussed), the complete timetable,
> the introduction and the project goals section.
> Could you take one final look at the attached PDF? I would especially
> appreciate a quick check on the timetable and the overall scope to ensure
> everything is realistic and aligns with your expectations.

Generally, it looks okay. As for the timetable, tests wants to be earlier,
possibly before GUI, as you'll likely find bugs this way, and you want
to fix them before adding GUI. And also, you may want to reserve one
week for unexpected issues.

> > -

> >
> > Architecture Design: Setup of a dedicated, network-disconnected
> > config-mgmt AppVM acting as the trusted source.

> > -

> >
> > Qrexec Service: Implementation of a new qrexec service (e.g.,
> > qubes.SyncConfig) with a strict whitelist policy in dom0 (ensuring no file
> > data is stored in dom0).

> > -

> >
> > Secure Review Mechanism: A GTK/Zenity-based GUI prompt in the target
> > VM that displays a diff of the proposed changes, requiring explicit user
> > consent before any file is overwritten.

> > -

> >
> > Persistence Integration: Integration with the custom-persist feature
> > (or bind-dirs) so that synchronized files outside the /home directory
> > survive standard AppVM reboots.

> > -

> >
> > User Documentation: Clear documentation on how to securely set up the
> > config-mgmt qube, configure the whitelist, and use the tool.
> >
> > What I do plan not to do:
> >

> > -

> >
> > I will not build a full configuration management system. This tool is
> > explicitly designed for lightweight file synchronization and will not
> > replace Salt or Ansible for complex system administration tasks.
> >
> >
> >
> > #Implementation
> >
> > To ensure a secure and resource-efficient synchronization process, the
> > implementation will strictly separate the transport layer from the logic
> > and enforce a robust verification process on the receiving end. The
> > architecture is based entirely on native Qubes OS mechanisms (qrexec and
> > AppVM isolation) instead of external, resource-intensive third party
> > automation tools.
> >

> > 1.

> >
> > Automation & Trust Model
> >
> > The system relies on a dedicated AppVM for configuration management. To
> > minimize the risk of compromise, this Qube should be created without NetVM
> > (offline) and serve exclusively as a trusted source for user
> > configurations. Dom0 is used solely to forward qrexec calls and enforce
> > policies. At no point are user data or configuration files stored in or
> > processed by dom0.
> >

> > 2.

> >
> > Qrexec Policy & Data Flow
> >
> > I will introduce a new qrexec RPC service, e.g., qubes.SyncConfig. The
> > corresponding dom0 policy will follow a strict whitelist approach:
> >
> > qubes.SyncConfig * config-mgmt @anyvm ask
> >
> > (Alternatively, power users can explicitly whitelist target VMS like
> > work-vm to allow without a dom0 prompt, relying on the in-VM review
> > instead. The data flow is initiated from the config-mgmt qube:
> >
> > qrexec-client-vm <target-vm> qubes.SyncConfig < payload.tar
> >
> > The payload will contain the relative paths and the file contents to be
> > synchronized.
> >

> > 3.

> >
> > Staging and Path Validation (Security Core)
> >
> > When the target VM receives the data via the qubes.SyncConfig service, it
> > will never overwrite existing files immediately. This prevents a
> > compromised source from instantly injecting malicious code (e.g., into
> > ~/.bashrc).
> >

> > -

> >
> > Staging: The python-based RPC service in the target VM will unpack the
> > payload into a secure temporary directory (e.g., /tmp/qubes-config-sync/).

> > -

> >
> > Path Traversal Prevention: The script will strictly validate all
> > incoming file paths using python’s os.path.abspath and os.path.commonpath
> > to ensure that no file attempts to escape the designated configuration
> > directories (e.g., preventing paths like ../../../etc/shadow).
> >
> >

> > 4.

> >
> > The Diff-Review GUI (User Consent)
> >
> > To address the risk of malicious configuration distribution (e.g.,
> > compromised ~/.gitconfig aliases), the target VM will execute a review
> > process before applying any changes:
> >

> > 1.

> >
> > The python script generates a unified diff between the staged file and
> > the currently active file.

> > 2.

> >
> > It triggers a lightweight, native GTK or Zenity-based dialog within
> > the target VM: “The qube ‘config-mgmt’ proposed changes to ~/.gitconfig.
> > Review differences:”

> > 3.

> >
> > The diff is displayed to the user.

> > 4.

> --
> You received this message because you are subscribed to the Google Groups "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/qubes-devel/7153bd86-faac-4dc8-8d7f-7453dd7f8af7n%40googlegroups.com.

- --
Best Regards,
Marek Marczykowski-Górecki

Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmnF+74ACgkQ24/THMrX
1yxOiAf/UGmPS0YNHTl2/doqsh8m3oUOJ/hD2NovsjX4F33mmEZuM9o88fUaSfmr
arLu+Kks1yq6tCFUvlA6/Ux15Pr1f8++b/ySlm6/scTfqqLMUxm7KjyLr5xdhIN5
rJ+f2xlg9Vcs8TD92nko2gLwvtSIrWshAcHunXU5zrnetR+d4XXLMrIdiUBul46L
jQnW8f0l0iZJ3wJcFHqmko3TgVhV3oNh6dP4nAfeeDLhiSsL/TuOMrNadNFoC0hO
ZQApe5fYfpHsOO4QXO7xSccPwq7EfxGqzd2qkoR4Grpmpam7q4jZv5kWAtU7mAYE
eNJPUquvDe3tJ4bFt+Fp1nM3y5quSw==
=aRSM
-----END PGP SIGNATURE-----