Default QubesOS Templates Metadata (Anti-Forensics)

What types of metadata are generated by QubesOS templates? What types of log files?

Which directories are these files stored in?

These APIs seem to be most relevant:

XenStore (in Qubes 2, data the same as in QubesDB, keys without leading /)
Qubes RPC (called at VM startup, or when configuration changed)
GUI protocol

There’s a warning that Qubes metadata is backed up for all Qubes, so digging through the data there is probably a good place to start. There are instructions for manually unpacking it here:

I do not know of a place where existing metadata is documented (it might exist and I just haven’t come across it).

which file format types are used for metadata, the log files.

Sorry, do you mean metadata about the templates or metadata about applications running inside of the templates? If it’s the latter then I know that some logs are in /var/log/qubes (in dom0 as well), but I don’t know if all of them are. I don’t spend much time with systemd, but I know that at least some Qubes projects have systemd-specific code, but also handle non-systemd environments… that’s about all I know as far as logging goes (not much, I know).

What about a tool like pyxs? Can it be used to modify data within xenstore?

I haven’t worked with it before, but considering it is described as a “XenStore client” it sounds like it is using the same underlying infrastructure.

Are you able to describe what your higher-level goal is? AFAIK XenStore provides pretty good isolation between different VMs (assuming that grants are managed properly). If you’re trying to avoid any writes to the disk, then QubesOS isn’t a good solution for you in its current state. The thread about “truly” disposable VMs might work, but I don’t know how well it’s been vetted (I haven’t read through the thread so maybe it’s been vetted pretty well, I just don’t want to imply an endorsement when I lack information).

I’m just wondering if Xenstore could be an attack surface. Could malware escape a VM and reconfigure Xenstore? Xenstore stores the configuration data for every domain, including dom0? could an attacker
modify domain configuration settings?

I mean, it should properly be considered part of an attack surface because it has an interface which is exposed to every VM. In principle, every piece of software could have a bug in it. In practice, I trust the developers maintaining XenStore to carefully review patches and respond promptly to any reported issues. You can see what data is stored in XenStore by running xenstore-ls / | less from a dom0 terminal. QubesOS also stores important data in QubesDB, which you can read from using qubesdb-list (analogous to ls) and qubesdb-read (analogous to cat). You might also be interested in this documentation page: