Stop leaking template name in appvm!

sapphire993 · February 19, 2026, 12:28pm

Im honestly kinda shocked… why the heck are you allowing any app to sniff template name in a regular appvm??? It’s really pissing me off because this kinda data is critical… and it’s by design??? wtf…
so… if you go into any appvm and AS REGULAR USER try to qubesdb-read /qubes-base-template it will show you the template of the appvm!!!..

WHY is this like that???
HOW do I stop appvm to leak my template names???

rustybird · February 19, 2026, 1:47pm

It was added as part of #1101, which states “VM already has ability to get the template name (for example from logs), so this will not pose additional data leak.”

I’d suggest giving your templates boring enough names instead.

Atrate · February 19, 2026, 2:02pm

Why do you care? What’s your threat model if it includes things like this?

sapphire993 · February 19, 2026, 2:18pm

so instead of fixing logs etc… they decided to just give up??? what kinda logic is that…
and this was over a decade ago… didnt they know what fingerprinting is back then? highly doubt it… so why… WHY… I cant access that google thing from TOR…

because this is CRITICAL identification data… and if for whonix its working because the template name is the same among everyone… regular template names ARE NOT!!! so you may do WHATEVER you like but you will NOT gain any privacy…

rustybird · February 19, 2026, 2:24pm

If your concern is software running in two different qubes finding out that they are based on the same template: The software doesn’t even need the template name for that at all. Taking inventory of installed packages, file timestamps on the root volume, etc. should do the trick. (But a website running in an unexploited browser can’t do this, nor query qubesdb for the template name.)

sapphire993 · February 19, 2026, 2:32pm

Im not talking about website… obviously it’s about a potentially malicious app running on whatever template…
so say I have gazillion of templates… each for one app or whatever… APPS should NOT have access to this kinda data… wtf?!

are you really all ok with that???

rustybird · February 19, 2026, 2:34pm

The app qube would only see the name of its 1 template though. Not the gazillion minus 1 names of the other templates that may exist on the system.

Atrate · February 19, 2026, 2:37pm

Breathe.

because this is CRITICAL identification data

The question then is: why are you putting “CRITICAL identification data” into your template names? Also, what would an adversary gain if they were to gain access to that CRITICAL data?

sapphire993 · February 19, 2026, 2:42pm

it’s like saying why you care about privacy if you dont have anything to hide… dude… come on…

template names are my INTERNAL way of ORGANIZING things…

good… now… THINK…

unman · February 19, 2026, 3:18pm

I think it would be helpful if you were to set out what threat model you
are concerned about, what is the specific issue you see here, and why
it matters.

Is it that a malicious actor could identify the name of the template
used by this qube? Could that be used to fingerprint you and in what
circumstances?
Is it because it might be possible to correlate use of templates between
different qubes?
In the naming scheme you have adopted are you really using “CRITICAL
identification data”? Why? It might be better not to use “CRITICAL
identification data”,(whatever that might be), anywhere on the system.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

otter2 · February 19, 2026, 3:23pm

A weak way I can think of is simply not having qubesdb package in your vm, but it shoud break things. Also malicious program might bring its own qubesdb client

@rustybird I know you know it better than I do, perhaps there is a policy one could set to deny reading certain keys, or obfuscate them?

unman · February 19, 2026, 3:38pm

I think there is not any such policy in place at the moment, (or
framework to support it.)

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

otter2 · February 19, 2026, 8:34pm

I have filed an issue and invite readers to participate:

github.com/QubesOS/qubes-issues

Add controls for qubesdb data

opened 08:30PM - 19 Feb 26 UTC

RandyTheOtter

P: default

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) ###… The problem you're addressing (if any) Information accessible through qubesdb is sensitive for certain use cases, but currently there is no good way to control it: https://github.com/QubesOS/qubes-issues/issues/8381 https://forum.qubes-os.org/t/stop-leaking-template-name-in-appvm/39537 ### The solution you'd like Ability to configure what qubes have access to what data. RPC policy comes to mind but this of course is up to the developer. Even something as simple as a toggle that prevents dom0 from sharing any qubesdb data is valuable. ### The value to a user and who that user might be Users can prohibit untrusted domains from accessing sensitive data. Mostly useful for improved privacy, to avoid fingerprinting. This also makes it marginally harder for an attacker to collect system information. ### Completion criteria checklist (This section is for developer use only. Please do not modify it.)

0at · February 19, 2026, 10:33pm

It is a little unintuitive to me that the name of a template would be accessible to an app qube. Or for that matter, even that the name of the app qube would be accessible to that same qube. For example, if I trap someone inside of a box, I’d assume that they wouldn’t be able to find out what color I painted the outside of that box, or the existence of or the details of a label I stuck to the outside of it.

A more practical example, I’ll stop this now that I’m aware of this thread, but I’ve had a habit of naming my qubes with references to different books/films I like, which apparently could give an attacker personal information about my tastes, separately from the fingerprint (packages, logs, etc.) that could obviously be taken from the inside of the qube.

I guess I assumed that packages, logs, files, etc. are ‘inside’ a qube, while the name, color, etc. are ‘outside’ the qube.

appih5587 · February 20, 2026, 1:03am

I’m also a bit confused - it’s written clearly in the linked issues above that the template name is available in the VM logs, but I haven’t seen any clear reason why this is the case / the desired outcome ?

unman · February 20, 2026, 1:28am

It is the case, (as with other references) because the qube inherits
most of the filesystem from the template, as is clearly documented.
So eg logs from the template appear in the qube: it’s a consequence of the
template/qube design.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

appih5587 · February 20, 2026, 1:55am

I understand that the VM inherits from the template’s FS, and that some of the template’s logs will appear in the VM - but it’s not clear why the template’s name, which to me seems like a cosmetic, “outside” property, appears inside the template’s inner logs

rustybird · February 20, 2026, 2:56am

VMs (including TemplateVMs) set their hostname from the VM name during startup:

github.com/QubesOS/qubes-core-agent-linux

vm-systemd/qubes-early-vm-config.sh

v4.3.40


      
          # Set the hostname
          if ! is_protected_file /etc/hostname ; then
              name=$(qubesdb-read /name)
              if [ -n "$name" ]; then
                  if [ -f /usr/bin/hostname ]; then
                      hostname "$name"
                  else
                      echo "$name" > /etc/hostname
                      echo "$name" > /proc/sys/kernel/hostname
                  fi
                  if [ -e /etc/debian_version ]; then
                      ipv4_localhost_re="127\.0\.1\.1"
                  else
                      ipv4_localhost_re="127\.0\.0\.1"
                  fi
                  sed -i "s/^\($ipv4_localhost_re\(\s.*\)*\s\).*$/\1${name}/" /etc/hosts
                  sed -i "s/^\(::1\(\s.*\)*\s\).*$/\1${name}/" /etc/hosts
              fi
          fi

That’s also why the VM name appears in the shell prompt by default.

dkzkz · February 20, 2026, 11:07am

This is why i started this project https://codeberg.org/dkzkz/apparmor-qubes by using apparmor to deny access to critical information for app like the machine-id of the users , the version of debian etc… i also asked @unman if in the future every debian template could ship with those apprmor profile for browsers and some apps.

You can also mix kicksecure and my apparmor profile but even with that a app will still be able to see if you’re using qubes or not

But i’m agree on this point by default apps should not see you’re using Qubes and they must not see your appvm name. Privacy and anonymity value is growing in the society. We never saw in the history so many apps and OS about privacy and anonymity i really think Qubes dev should make effort for this issue. By doing that Qubes will attract many other users and they will get more donation.

unman · February 20, 2026, 12:24pm

My response was that it would require much testing before this could be
applied. dkzkz posted looking for volunteer testers, but little apparent
response. If you want this sort of thing implemented, then get on board
with that testing.

It’'s not impossible to hide the qube name from the qube, although I am
yet to be convinced of the need for this. As to “not seeing you’re using
Qubes” that is very difficult, and most approaches are just theatre.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.