[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:       cooloutac <raahelps () gmail ! com>
Date:       2017-04-27 6:56:42
Message-ID: 2e33c25d-d542-4ed0-a6cb-090c65a25a85 () googlegroups ! com
[Download RAW message or body]


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, tasket@openmailbox.org
> 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 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/2e33c25d-d542-4ed0-a6cb-090c65a25a85%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.



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