> ---------------------------------------- > From: scurge1tl <scurge...@cock.li> > Sent: Sat Jun 01 11:34:00 CEST 2019 > To: <qubes-users@googlegroups.com> > Subject: Re: [qubes-users] How to automate cloud backups of trusted vault > files? > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > > 'Side Realiq' via qubes-users: > >> ---------------------------------------- From: Andrew David Wong > >> <a...@qubes-os.org> Sent: Sat Jun 01 03:33:28 CEST 2019 To: Side > >> Realiq <siderea...@mailfence.com> Cc: > >> <qubes-users@googlegroups.com> Subject: [qubes-users] How to > >> automate cloud backups of trusted vault files? > >> > >> > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > >> > >> On 31/05/2019 10.33 AM, Side Realiq wrote: > >>> Thank you Andrew! > >>> > >>> Wouldn't described scenario be mitigated, if one downloads the > >>> backup in a separate disposable non-internet VM, decrypt it, > >>> and transfer the decrypted files to the vault? > >>> > >> > >> The problem is that, if the decrypted files have been > >> compromised, they could compromise the vault when you open them > >> inside the vault. > >> > >> P.S. -- Please avoid top-posting. > >> > >> - -- Andrew David Wong (Axon) Community Manager, Qubes OS > >> https://www.qubes-os.org > >> > > > > But how can the decrypted files be compromised if they were first > > encrypted first locally and only the encrypted files were uploaded? > > Attackers should be always able to compromise the encrypted files, > > and compromise the decrypted files only if they could break the > > encryption. You mean that qvm-backup could protect you if the > > attackers break the encryption and put malicious files inside your > > backup? > > > > Basic rule for any security setup is to never move any data upwards > from low sec to higher sec area, under any circumstances. > > Thats why we have in the /etc/qubes-rpc/policy/qubes.ClipboardPaste an > option to set: > > $anyvm vault deny > $anyvm $anyvm ask > > To prohibit the insecure behavior. > > But would here help this as a higher sec option for cloud storage of > sensitive data? Could this be reasonably automatize: > > To get the file TO the cloud from the high-sec vault-vm to lower sec VMs > - - encrypt the container/file in vault-vm > - - hash the container/file after encryption in vault-vm > - - log the container hash > - - cp the container to the cloud-vm > - - cloud it > > To get the file FROM the cloud, and move it from the low-sec to > high-sec VMs (even not recommended) > - - download the container/file from cloud to the cloud-vm > - - hash it directly in the cloud-vm, or hash it in the DispVM > - - check the hash with the logged hash in the vault-vm for authenticity > - - if ok, cp (even not recommended) the file to the vault-vm > - - hash it again (?) and make double check the authenticity of the file > - - decrypt it and enjoy its content > > Here you mitigate the option of running a malicious file changed by > the adversary, but not the attacks related to the dirt leaking from > the process of copying the files from low-sec to high-sec VMs. > > One could lower the issue with multiple vault VMs, which would > compartmentalize the possible damage but also increase complexity. >
Thank you sharing the process! Overall it seems that there is currently no existing open source solution that 1) helps with backups from vault to cloudVM and 2) is automated. So every user is doing their own solution. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1317973014.68501.1559407403897%40ichabod.co-bxl. For more options, visit https://groups.google.com/d/optout.
