-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2016-05-26 13:51, Chris Laprise wrote: > > > On 05/23/2016 06:57 PM, Andrew David Wong wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> On 2016-05-23 12:49, Chris Laprise wrote: >>> >>> On 05/23/2016 12:06 AM, Andrew David Wong wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >>>> >>>> On 2016-05-22 11:52, [email protected] wrote: >>>>> I tooled around in 3.1 and got the basic understanding >>>>> that you arent running OS VMs like vmware but instead app >>>>> VM's, but im not familiar with how these work in respect to >>>>> isolation. >>>>> >>>>> If i am running two app vms under the same template and >>>>> one app gets infected, does everything in that template >>>>> get infected? >>>>> >>>> No, each AppVM has only read-only access to its TemplateVM. >>>> A compromised TemplateVM can compromise all AppVMs based on >>>> it, but not vice versa. Furthermore, two AppVMs do not pose >>>> any risk to each other merely in virtue of sharing the same >>>> TemplateVM. >>>> >>>> More information: >>>> >>>> https://www.qubes-os.org/doc/software-update-vm/#tocAnchor-1-1-3 >>>> >>>>> >>>> I am running a disposable app vm and i assume its infected, is >>>>> it possible to retrieve files from it without cross >>>>> contamination? Where are the instructions on how to do >>>>> this? >>>>> >>>> It's not really possible to answer that question in the >>>> abstract. It always depends on the situation, and in general >>>> it is difficult to do and almost always impossible to >>>> verify. >>> Suspect files can be safely handled with qvm-copy between vms, >>> as long as no attempts are made to open them (even parsing them >>> can be risky). But the act of retrieval itself should be >>> considered safe. >>> >>> This is in contrast to something like a USB drive that gets >>> mounted in different vms to move/retrieve data: The filesystem >>> itself poses a risk in that case. >>> >>> >>> >>> Chris >>> >> IIUC: >> >> 1. We have to trust the compromised VM to qvm-copy the same file >> we ask it to. It may appear to comply but in reality copy a >> malicious file to the destination VM. > > No, we don't have to trust a compromised vm in that way. The copy > operation itself is still safe. >
Are you sure about that? What prevents a compromised VM from feeding different data to its qrexec-agent or modifying the target file before it's copied to the destination VM? >> 2. Since the copied file may have been modified to be or replaced >> with a malicious file, opening it in the new, clean VM could >> result in cross-contamination. > > Right. That's why copying and archiving files is fundamentally > different from opening them. > Sure, but as a practical matter, what are the odds that boromirsbeard (or anyone in the same position) just wants to copy the file out of the compromised VM but not open it in the destination VM? Pretty low, so I think point 2 is worth mentioning here. > I think before long Qubes will get some additional 'sanitizing' > tools... for images and text files not just pdfs. That will make > the prospect of opening/examining files from untrusted sources far > safer. > > OTOH, if one wants to use a relatively trusted vm to quarantine > and catalog files from suspect sources, for example, the current > Qubes tools allow us to do that safely (i.e. operations are limited > to copying and storing). That's the reason why Qubes isolation in > the same computer is often considered safer than running multiple > air-gapped computers... the latter are not useful without data, so > copying any data to them requires using layers of complex drivers > and formats (USB drive, optical disc, etc.). In comparison, > qvm-copy is ultra simple and very safe. > > Chris > - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXR8mXAAoJENtN07w5UDAwNPgQAMdwOL8fCzm0dKzdvYQahgLH FTaKPs+9VMXkbT/shZdMf+mlVieDRPptkFf1nYI+F109T/GDh9tcM78oLQVI8uNJ kFi3DMELHiXA9StYlU+9AVbPPbz6pkdXdIw3O3eYCSlnSMv3rFl7RG7O9dKG4YA3 8IjawfVV9qih1MLW7WsWUcdm73NCP9lXSm7nko3o/2qqjVoTXmRoZuF2uf/6wVOT 2W/9XPT9POQ5h9O+aDPLmMG/xiuZkRE4ZeqiXvo6eNkmMN89sHWG5tlr0cISRZG7 kfIgWI2GRrlRe6jAvi4hVGkVxeNHCDSh7uad46UF01MfJrtHWDKj1wDwhoXuKXa+ egaStuo4aJ8Kmf9r2jeHvQNABqs4D9rn+Nc1BQGJ3B7OUDrKhjD1G/sbhE9BrvS0 Jg/afmbtjxb0mh1UvYKMZURxqhltrwsI8zmdtLfo0HsQGSwCTTUR1RfNY5ndmpxm FVXIk3CqOJw1olbhi35lTQsS0QnqcUst3nIovZTtHEBotIKBJ2QOEuVUuns7DB+M h72x8xGJnQBLRUmfT8QZ/w75IcIsUMp8K+Jj/YNTdIj+3XVBQkhOFASK5gM+0/Ot yNBlF8IQspz1VvXiaBeU9EKbBNtLiE64wn8fyGz48Tno+o3QxeUfxOzDONTTobW1 82HjM+PGyJyNNGojHal7 =rw7o -----END PGP SIGNATURE----- -- 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/0f9a885a-d951-9bae-8e00-c131e8cfc1c6%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
