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!!!..
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.
Why do you care? What’s your threat model if it includes things like this?
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…
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.)
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???
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.
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?
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…
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.
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?