On Wednesday, April 26, 2017 at 9:27:11 AM UTC-4, Chris Laprise wrote: > On 04/26/2017 07:40 AM, Joanna Rutkowska wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Hello, > > > > Just a FYI that we have recently implemented a so called "Paranoid Mode" > > backup > > recovery for Qubes OS. Arguably this is a new approach to dealing with full > > system compromises (thanks to Qubes architecture (TM)). > > > > The packages for Qubes 3.2 that bring this functionality are currently in > > the > > qubes-dom0-current-testing repository [1]. Note that you need these > > packages on > > a fresh system where you want to restore to, and only there. > > > > I also wrote a post [2] explaining the rationale for this, as well as how > > it is > > implemented, and what are still the limitation in 3.2, and how these will > > gone > > in 4.0. The post also touches on AppVM compromise recovery challenges and > > how > > Qubes OS might help here also. > > > > Of course I wish we all didn't have to use this feature too often... :/ > > > > Cheers, > > joanna. > > > > [1] https://github.com/QubesOS/qubes-issues/issues/2737 > > [2] https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/ > > > Its good to see a detailed exploration of recovery from compromised > state. As News items go, its a doozy (quite large)! Maybe the document > could be migrated to docs? > > Some initial thoughts about paranoid mode and recovery: > > 1. Its not clear from the news item whether TemplateVMs are restored (I > would guess they are not). > > 2. Dom0 files could be restored into a 'quarantine' or 'old' > subdirectory. I always wanted restore to do this for dom0 anyway, by > default or via an option. > > 3. Good that forensics VM is shown as a thing that's potentially > worthwhile. Of course, I half expected the usual warning about > corrupted/exploited filesystem. > > 4. A more accurate term for the option would be 'precaution' mode or > similar. 'Paranoid' is a loaded word. > > > On Prevention: > > Its worth noting the uncertainties that exist in #3 (cleaning scripts) > largely apply to #2 (qvm-copy then analyze). This is because > clean/protect scripts such as in Qubes-VM-hardening [1] are a natural > place to run verification procedures as well -- and I expect to have > this implemented in Qubes-VM-hardening by next week. The user will be > able to create file lists with SHA hashes, and mismatch will trigger > popup and log events. Of course, a manual analysis can utilize a wider > array of tools vs what can be used inside of a startup service. > > Also note the prevention issue is not limited to the home directory.... > If an attacker succeeds in privilege escalation, then they can alter > /rw/config and other root-owned parts of the private.img volume. In that > case, it could be advantageous to have some/most VMs automatically > disable or even reset /rw files, assuming those VMs don't need special > configuration. Unlike home scripts protection, such a countermeasure is > a leveraging of templates' non-persistence. > > Lastly, there is some distinction between whatever apps could > (inadvertently) launch malware code /sometime/ in the runtime of the VM, > and what apps could launch malware when a VM has just finished booting. > In the latter case, an aware user knows the attack surface expands > greatly once more apps are run. > > > 'Qubes OS vs conventional systems?' ...could have mentioned that Qubes > holds out the promise of being able to sanitize at least some data > formats after a restore. > > > In the FAQ, it seems like AEM could be mentioned as firmware protection. > IIUC, AEM should be especially effective against remote attacks (against > BIOS/firmware) and I think remote is what most of the document is > addressing. > > -- > > Chris Laprise, [email protected] > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
only templates I ever backup are cloned ones. I wouldn't even mind default templates being disposable lol. I wouldn't even know what programs to "clean" anything with anymore. Is anyone really going to use a virus scan? What is even out there for linux thats worth anything thats not enterprise? I think only secure boot is going to stop any remote attacks on bios, still think it would be nice to have to add to trust chain measure and compliment AEM, which only notifies if attack happened, hopefully. I don't see them as two diff things I see them as completing more of the whole picture together. -- 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/2e33c25d-d542-4ed0-a6cb-090c65a25a85%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
