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, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/4f38ca89-d77f-0253-cba1-ebd2a0bf9cb1%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to