[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 7:11:22
Message-ID: d62aa5b4-fc23-4588-b93d-25e34a6e7f83 () 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
Here is what would be awesome for linux \
https://software.intel.com/en-us/forums/intel-trusted-execution-technology-intel-txt/topic/391211 \
I mean I know how TXT is nothing to brag about but, This intel employee says you \
need 3 things, secure boot, trusted boot, and measured boot. And throw some malware \
detection in there too.
This is why guys like Brad Spengler use windows lol.
--
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/d62aa5b4-fc23-4588-b93d-25e34a6e7f83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic