On Wed, Apr 12, 2017 at 2:07 PM, Sam Hentschel <hentsche...@gmail.com> wrote:
> On Wednesday, April 12, 2017 at 4:15:08 AM UTC-4, Unman wrote:
>> On Tue, Apr 11, 2017 at 11:12:50PM -0400, Sam Hentschel wrote:
>> > I am trying to figure out a way to securely handle my encrypted drives
>> > without two things: connecting the USB directly to the Vault (as this is
>> > obviously a bad idea for security), and decrypting the USB in sys-usb
>> > (also obviously a bad idea).
>> >
>> > As an example, I have some USB that I keep encrypted backups of my
>> > important documents that I keep with me in case an emergency happens
>> > (which now that I am using Qubes will probably also be in the Vault). I
>> > have files on there that I need to move to Vault, and I need to be able
>> > to continue to put files onto it (whether from Vault or from a scan I
>> > have done. <note: I will be writing some documentation hopefully on
>> > what I did giving DispVMs the sole ability to print and scan.> Which I
>> > know is a whole different problem; so I want to focus on just the
>> > encrypted storage.
>> >
>> > Another example is my backup drives which are all encrypted, and that I
>> > would like to have access to for the standard reasons. I have been
>> > pointed to [1] a couple days ago by JPO and I believe this is part of
>> > the soution, but not the whole thing.
>> >
>> > My two solutions that I have thought through are: doing PCI patthrough
>> > directly to the Vault (which is the least favorite of my ideas), and
>> > creating a separate VM for encryption that only houses software for
>> > encrypting and decrypting (dm-crypt or veracrypt). This way the USB
>> > will be passed through to this VM and will never directly touch the
>> > Vault (except through qvm-move-to-vm).
>> >
>> > I had a third solution of adding this functionality to DispVMs, but I
>> > can't PCI pass the USB to the DispVMs when they are running. So that
>> > one is out.
>> >
>> > Thanks in advance for the help; can't wait to see what I missed!
>> >
>> > [1] https://github.com/rustybird/qubes-split-dm-crypt
>> >
>>
>> Hi Sam,
>>
>> I'm obviously missing something here.
>>
>> One of your two solutions fits completely within the current Qubes model
>> and matches exactly the specification you set; that is, qvm-block
>> attach the encrypted drive to a qube and decrypt it there.
>> Can I ask what more you are looking for?
>>
>> There's no need to do this in a separate decryptionVM - you can use a
>> disposableVM for the purpose.
>>
>> If you don't want to have the decryption software in a standard
>> template, then put it in a separate template, build a distinct
>> disposableVM from that template and use my hack to fire up that
>> disposableVM when you want to use a decrypted drive.
>>
>> unman
>
> Unman,
>
> I was just making sure I wasn't missing something or there wasn't a better
> way. Anyways, I can't set this up in a DispVM because you cannot PCI
> passthrough to a VM while it is running(?)
Your understanding is incorrect on the following details:
1) you *can* do pci passthrough to a vm while it's running. Depending
on if the device supports function-level-reset or not, you may need to
set pci_strictreset="False" for the VM in /var/lib/qubes/qubes.xml
2) qvm-block is distinct from and not implemented with pci
passthrough, it uses xen blk{front,back}. This is an entirely
different and believed to be less dangerous interface to expose than
PCI to your actual devices.
That said, you might prefer to use a normal unencrypted filesystem,
only interface with the filesystem in sys-usb, and use encrypted files
instead.
You could then use qvm-copy-to-vm to move the ciphertext from sys-usb
into your other vm, {decrypt, manipulate, re-encrypt} them there, send
back new ciphertext (again via qvm-copy-to-vm) to sys-usb, and put
them back on the flash drive from there.
This isolates your document processing from potential vulns in your
filesystem manipulation code (such as fuse-exfat which appears to be
the de-facto standard flash drive filesystem these days for maximum
interoperability).
This approach likely has a higher chance of protecting your
document-processing VM from being exploited by filesystem
vulnerabilities, which may be even easier to exploit if you consider a
malicious flash drive with compromised firmware (manipulating metadata
behind your back while the drive is mounted to potentially otherwise
"unreachable" code paths in the fs drivers) to be part of your threat
model.
Cheers,
Jean-Philippe
--
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/CABQWM_ChXGeH8fp%3DnM%3DuuLLGQGL-paK19mYJfrvCdQ3f_v%2BDDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
