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).
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: