I’m trying securely and safely update music cataloger. I’m not aware if there is any risk to do it actually.
How I see I should do it:
I’d download youtube video (as mp3 only), from within DTBDVM. My Music cataloger and my database are in yellow personal VM. Now, Music cataloger would have to access that mp3, to scan it’s file properties (codecs, lengths, title, author, ID3 tag whatever it’s “scannable”) and then to retrieve online info about it.
I didn’t try anything because i wouldn’t want to compromise my personal VM and music database while experimenting.
What would be the safest process? For the books, I’d of course sanitize pdf and then send it to personal, but I am not aware what are the risks with music and video files.
If mp3s and videos aren’t dangerous as pdfs and photos, which risk I could expect when DTBDVM in which I retrieved mp3 was compromised, if sending mp3 from it to personal in order to be scanned there?
One of the safest options would be to only open the untrusted files in a DisposableVM and only store them in an archive qube. See also: All Secrets in Vault vs. Distributing Secrets.
Thanks for your response @fsflover . When you say “open” do you mean to scan mp3 in tbdvm or to listen to it in tbdvm? I don’t need to listen to it, I just want to scan it with my cataloger and retrieve info about the song online.
You never know if your scanner has any bugs and vulnerabilities which can get exploited. For the same reason, dom0 does not show UTF-8 window titles. Any relatively complicated procedure of parsing/reading a file could in principle lead to a vulnerability, even looking at a file in a file manager. But, depending on your threat model, you might consider such things very unlikely.
What music cataloger are you using? If you are only retrieving information, can you simply clone your music VM, scan the internet using the cloned cataloger, convert the collected images and text to trusted formats, qvm-copy the converted data back to your original music VM and then delete the cloned VM? As long as the information you retrieve is in a format that can be cleaned (text and images), your original music files and cataloguing app should remain free from compromise. If the scanner embeds collected data into the music database, perhaps there is a way to output or export database info & album art so you can clean it before copying the data back to your original VM and then importing it into the original database.
Well, actually your post helped me to rethink the concept, and i thank you for that. This is how I see it now and please respond with further suggestions or thoughts, when and if your time allows it.
Yesm it embeds. Now, I have this database for decade(s). So, most likely it is already compromised, but I don’t know how, and God knows how it compromised my previous computers. The good thing is that it is just a bunch of text and images I could live without. As long as I can access it (it’s not locked out/damaged/destroyed by compromising), I am happy to read it. Finally, Qubes gave me an opportunity to at least protect my computer from it.
Keeping this on mind, what I think I’d do now is:
Detach my MusicVM from the net (by detaching dtMvm from the netvm) and try to open the database.
If it doesn’t work, I hope I can find some recent backup, and open it. If it still doesn’t work, trying some other cataloger, all until I succeed to open the most recent valid database copy.
If it works, prior to anything else create a copy of the database to an offline untrusted storage qube.
Reattach netVM to dtMvm, move the mp3 from the other dvm to MVM, open the cataloger/database, read/parse the mp3, retrieve online info about it, delete/move mp3 to untrusted storage qube.
Create a second, more recent copy of it in untrusted storage qube.
When listening to mp3, opening it in dMvm from untrusted storage qube.
For the next mp3, repeat the process, while deleting the oldest backup, keeping only 2 most recent working backups, hoping that the “destroy me” malicious code isn’t coded to be triggered on June 16th 2033.
Abstracting that I really don’t have so much time in my life to sanitize text and photos prior to import them (back) to a database (it’s simply isn’t worth it considering the amount of text, number of fields, and number of photos per mp3, but I promise I’ll rethink if it’s feasible) and that almost for sure my database is already compromised but readable, what do you think of the model?
I can’t really comment on your model because I’m not familiar with mp3 data scrapers. Nor am I familiar with the ways that mp3s or databases might be compromised.
I will say this though. Regarding older exploits (as old as 5-10 years), it’s highly improbable that they are designed to escape VMs or attack hypervisor shared memory or some other exotic modern attack. If anything, they are probably some old Windows exploit that wouldn’t even work in Windows today.
If by some chance your old music collection is compromised with a Linux exploit, you can likely mitigate it by isolating your music VM. I would create a fully disposable named VM and place the database in your disposable VM template. Never play music or open the database in the disposable template. Keep the disposable appVM isolated from all networks and don’t store any personal files in the VM. That way, the VM is clean upon each launch. If it gets infected when you open your music collection, there is no network access and no personal files at risk. When you reboot, it’s clean again. Just be sure to add new music files to the disposable VM template and don’t play the music or open the database from within the template.
The database was actively used until I switched to Qubes as my daily driver several months ago. It’s a funny paradox - now that I use such a secure OS, I don’t dare to use the database yet, haha.
Unfortunately, my database has to go online in order to retrieve info about the song/mp3…
Look on the bright side. If your database is already compromised, you have nothing to lose! Just use a networked disposable app VM to update the database and copy the updated database to a disposable template VM. When you launch your final non-networked disposable music VM, the database will be updated, there will be no network and no personal files will be at risk.
A less safe but more convenient way would be to mount the MP3 storage volume onto the VM that downloads files, and then download the file directly on the mounted storage volume. Or any combo you want:
Thanks Rudd-O, but while I do appreciate your showcase of Qubes flexibility and customization, it is against my comprehension of Qubes security principals, which I already show at the correspondent topic. I hope you won’t find this disrespectful, but just as a different perspective.
Thanks @necker. I think we fully agree on that. (please apologize if I’m indiscreet, but what happened with partition?)
No worries. There is nothing very discreet about changing the name of an existing account. All previous posts are updated to the new name.
When I signed up with “partition”, it was a random choice. I realized that I don’t really like the structure of the word. Not sure why. Something in the way “ti” repeats but is pronounced differently. I suppose “necker” is somewhat random too, but at least it has thematic relevance.
Just use a networked disposable app VM to update the database and copy the updated database to a disposable template VM. When you launch your final non-networked disposable music VM, the database will be updated, there will be no network and no personal files will be at risk.