[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-users
Subject:    [qubes-users] Re: [qubes-devel] Compromise recovery on Qubes OS
From:       Chris Laprise <tasket () openmailbox ! org>
Date:       2017-04-26 13:27:01
Message-ID: 4f38ca89-d77f-0253-cba1-ebd2a0bf9cb1 () openmailbox ! org
[Download RAW message or body]

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, tasket@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+unsubscribe@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.


[prev in list] [next in list] [prev in thread] [next in thread]