On Tuesday, May 16, 2017 at 9:31:50 PM UTC-4, Andrew David Wong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 2017-05-16 01:24, cooloutac wrote: > > On Sunday, May 14, 2017 at 11:09:25 PM UTC-4, Andrew David Wong > > wrote: On 2017-05-14 21:38, cooloutac wrote: > >>>> On Sunday, May 14, 2017 at 3:48:04 PM UTC-4, Andrew David > >>>> Wong wrote: > >>>>>>> > >>>> > >>>> What do you mean? Are you suggesting that qvm-backup has > >>>> "more attack vector" than an encrypted KeePassX (or whatever) > >>>> database? Why? No, I think it's actually the opposite. An > >>>> attacker could feed you a malformed database file, which you > >>>> believe is your authentic database file. If it's not > >>>> authenticated, you won't be able to tell. When you try to > >>>> decrypt and open it with KeePassX, it could try to compromise > >>>> KeePassX. qvm-backup is designed to protect against this > >>>> class of attack. I'm not sure what you mean. If an attacker > >>>> has a copy of your encrypted database and subsequently gets > >>>> the key/passphrase to that database, she can then decrypt > >>>> the database regardless of what you subsequently do. > >>>> > >>>> Are you saying that you would render the contents of the > >>>> database worthless by changing every password stored in that > >>>> database? How would you know to do this? Are you assuming > >>>> that you'll somehow know the instant your database has been > >>>> compromised? What if the attacker changes some or all of your > >>>> passwords before you do? What if you have persistent > >>>> passwords (e.g., not for online accounts) that can't be > >>>> rendered useless in this way? > >>>> > >>>> > >>>> Well if they can do that to one file, couldn't they do that > >>>> to alot more others if backing up the whole vm? I would think > >>>> one file is alot easier to check. Since that whole vaultvm is > >>>> only dedicated to that one file for me anyways, and I don't > >>>> have custom configs or scripts in it. > >>>> > > > > No. With qvm-backup-restore, the entire backup blob is checked for > > integrity and authenticity. That check will fail if any bit in the > > blob has changed. Since the blob is encrypted, an attacker won't > > be able to tell what individual files are in it, unless you divulge > > that information in some other way. > > > >>>> One cool thing I saw about paranoid mode is it take into > >>>> account things in user directories that are not even user > >>>> data to begin with. so ya I back up other vms that way > >>>> especially templates, and especially vms with custom configs. > >>>> or vms with just alot of data in alot of diff folders out of > >>>> convenience. > >>>> > >>>> But for the vault I just do the single file. > >>>> > >>>> And so say if the database file is malware, what do you mean > >>>> by qvm-backup would prevent it? > >>>> > > > > Suppose you take your encrypted database file and store it > > somewhere (e.g., cloud storage, HDD in a safe deposit box). Suppose > > that an attacker secretly replaces that file with a malicious one > > without your knowledge. The next time you decrypt that database > > file, it silently compromises your client or VM and leaks your > > passphrases through side channels or does other nasty things. > > > > If you had instead backed up the entire VM with qvm-backup, you > > would immediately know, upon trying to restore from the backup, > > that it was not the same trusted file that you had originally > > created, since Qubes would inform you that the integrity and > > authenticity check had failed when you entered your passphrase. > > > > Now, if your password manager also uses authenticated encryption > > for its database files, then that's fine, but as far as I know, > > most don't. > > > >>>> And yes "rendering it useless by changing every password". > >>>> We are talking of the times you suspect it, have a hunch, if > >>>> you think you can never tell when you are compromised then > >>>> what else is there to go on? > > > > There's nothing wrong with acting on a hunch. In some cases, it may > > be obvious that a VM or whole system has been compromised, but > > there's no way to know for certain that a VM or whole system has > > *not* been compromised. > > > >>>> and what else can be done? > >>>> > > > > Use Qubes OS. Compartmentalize. Use Paranoid Mode. :) > > > > > > So you are saying qvm-backup will know if an attacker has switched > > up the backup file, which is well and good. But I'm assuming the vm > > or file is already compromised before backing it up in the first > > place. > > > > Oh, that's a quite a different scenario from what I had in mind, then. > > > Also apparently qvm-backup has not taken every file into account or > > there would be no need for paranoid mode. > > I think you might be misunderstanding Paranoid Mode. VMs that you > restore using Paranoid Mode may (still) be compromised. > > > I still believe having to only verify the integrity of a single > > file is better then a whole vm. > > > > Well, the backup is itself a single file. > > > Although this discussion makes me think maybe when loading the > > possibly compromised keepassx file I should load it in a disposable > > just to get the passwords, but not open it in the new vault vm I'm > > going to create. But then I uess I als can't copy and paste what > > to do about passwords 100 characters long? lol > > > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJZG6fvAAoJENtN07w5UDAw6AoQAL6fnfWaRFSy3hSg2lZypLk1 > e7ypb/OmuYgCJD8zlYI+JjJdSW4ocsIoyRN6+tQXrCsTDSYpU6z6OX1jeyZb1XLR > Jsfh4Bx8ie2dfZi4bGzdhPcXF/LFgB4NlBB4HTq8OaaDyYFaCOOyu6ANfSVFAUal > R77koWT4O5/cpjt3RrkWJRI9ssv6pHm1jJZzN5T2HeKSkzwIjeB+r+dZkWmtGUzt > TuZPsziXlPkIbCGwAwMb9qT9sz3Oeu0cl7x1nIhXXpVWEo0ovO09uowcUPUxr8Z5 > ekvkXzvkgpi6hmGquaUKv6bG7aiDJD1xCW8b74jfExbcQPBHD4sMVWKF3k5MUh39 > GsXd5XlgxiYjjUz2cPfME/9w154BFVtuH5S4/daq2PchqhYexHhnUqG217iv0UQU > VY4c0M82IZubew1/73DDTJ7cRADCsJ1Aw2DOO8h8SAKkdg4XQ/p2iBnG4xgvSQxX > mfKuWIF6S9z7X2P39fSn42IhcQC+vhcb70oqoWZ3CFkpZGVKOEiazZuJ2L2RAOYn > DNEvUJ/U2Sp2QUQ1lNyG1CfypR0eGftVopWGrQc2Zodw2P8DNnxygLrlJMFuJ+MY > +BUA3c273WxDxkJ4U4crOQGSl1g4jhqtGiWSr23fzsUIZoOE42o8Vmh9gSl5tnGb > fSo7rrA30ux2TyxtsI5B > =N4TQ > -----END PGP SIGNATURE-----
well I thought paranoid mode just disabled copying of some non user data executables and mayb some other stuff? And yes would have to assume it might still be infected. Sounds good to me Definitely something to think about though. Yes qvm-backup is one file but after extracted, like an iso, is alot more. But with paranoid mode then we can just treat it as hostile but it is less capable to extract data we need. If a data vm maybe even just keep the paranoid vm for like pictures and stuff right? -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d3b20830-0c2c-403d-8cc0-7b2b034d0d93%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
