Re: [qubes-users] The safest way to search in files on an external hard drive

Mailing Lists qubes-users
1

Michael Singer:

I am looking for a really secure way to use Qubes for searching not
only a hard drive for file names, but for text that is in files.

The goal is to avoid an exploit in the searched files leading to a
takeover of the hard drive by malware.

The total size of all my files is too large for me to put them all
in one qube before searching for text in them.

Would it perhaps be possible to mount only a single partition of the
hard drive into a qube, but not with write permissions, only read
permissions?

Yes, e.g. like this:

$ qvm-block attach --ro destinationvm sys-usb:sda1

Then you can decrypt and mount the read-only /dev/xvdi in the
destination VM.

I would do the search on command line, using "grep" for plain text
files, "pdfgrep" for PDFs, and something for table files, databases,
etc.

Is my idea feasible? And how secure would it be?

Sounds fine to me. But malicious content could still exploit the
destination VM, so consider attaching to a DisposableVM (after
switching off its networking).

If your partition is LUKS1[1] encrypted, Split dm-crypt[2] might be
convenient. Its default behavior is to attach the decrypted partition
to an offline DisposableVM:

$ qvm-block-split attach --ro sys-usb:sda1

[1] TODO: LUKS2 support
[2] GitHub - rustybird/qubes-split-dm-crypt: Isolate secondary storage dm-crypt and LUKS1 header processing to Qubes DisposableVMs

>

Dear Rusty Bird,

thank you very much for your advice. I had to find a way to mount the read-only volume in the destination qube. I discovered the page Redirecting… But it doesn't say how to mount it either. The normal way with "$ sudo mount /dev/xvdi /mnt" does not seem to work for read-only. You have to tell the mount tool that it is a read-only device: "$ sudo mount -o ro,noload /dev/xvdi /mnt" This way it works. Perhaps this should be added to the documentation.

I read the notes about your split-dmcrypt-tool. Good work! Let's assume I would not work with LUKS. Suppose I mount sda1 with read-only option set in a DispVM (after switching off its network), decrypt it there and search in the files. An exploit bug occurs and the VM is taken. Now it could happen that someone leaks the partition password to the internet via a covered channel. So would it be safer to mount the decrypted volume again in another DispVM before we search it? And how would that be done? With the loopdevice method? What commands would you use in the terminal?

Many thanks
Michael Singer

2

Rusty Bird:

Michael Singer:
> I had to find a way to mount the read-only volume in the destination
> qube. I discovered the page
> Redirecting… But it doesn't say how
> to mount it either. The normal way with "$ sudo mount /dev/xvdi
> /mnt" does not seem to work for read-only. You have to tell the
> mount tool that it is a read-only device: "$ sudo mount -o ro,noload
> /dev/xvdi /mnt" This way it works.

'mount' without any options generally works for read-only devices -
but not if the filesystem is in a dirty state, like after sudden
power-off. In that case 'noload' is needed so the kernel doesn't
attempt to recover the newest data by replaying the journal, which
would fail without write access.

> Perhaps this should be added to the documentation.

Redirecting… :slight_smile:

> I read the notes about your split-dmcrypt-tool. Good work! Let's
> assume I would not work with LUKS. Suppose I mount sda1 with
> read-only option set in a DispVM (after switching off its network),
> decrypt it there and search in the files. An exploit bug occurs and
> the VM is taken. Now it could happen that someone leaks the
> partition password to the internet via a covered channel. So would
> it be safer to mount the decrypted volume again in another DispVM
> before we search it?

Yes, assuming that the exploit is inside the *decrypted* data. Then
that second offline DisposableVM would not have access to the (tiny)
password, so it would only be able to slowly transmit the (huge)
decrypted data over such a hypothetical covert channel.

> And how would that be done? With the loopdevice method? What
> commands would you use in the terminal?

[dom0]# qvm-block attach --ro disp1 sys-usb:sda1

[disp1]# echo Y >/sys/module/block/parameters/no_part_scan

I just remembered, this is only a partial solution unless

from Split dm-crypt has also been installed.

The point of this step is, if the decrypted data blocks are malicious
then the intermediary decryption VM (which knows the password) should
not parse them in any way at all. So no_part_scan=Y disables the
kernel partition parsers; the .rules file also disables udev
filesystem type etc. parsers when no_part_scan==Y.

OTOH if the exploit is merely in a *file* inside the decrypted
filesystem, but you know that the decrypted "outer" data structures
(such as the filesystem itself) are not malicious, then it's fine to
skip this whole step.

[disp1]# (somehow decrypt /dev/xvdi, yielding a device /dev/mapper/something)
[disp1]# readlink /dev/mapper/something
../dm-0

[dom0]# qvm-block attach --ro disp2 disp1:dm-0

[disp2]# (mount /dev/mapper/xvdi)

Rusty

3

Michael Singer:

I had to find a way to mount the read-only volume in the destination
qube. I discovered the page
Redirecting… But it doesn't say how
to mount it either. The normal way with "$ sudo mount /dev/xvdi
/mnt" does not seem to work for read-only. You have to tell the
mount tool that it is a read-only device: "$ sudo mount -o ro,noload
/dev/xvdi /mnt" This way it works.

'mount' without any options generally works for read-only devices -
but not if the filesystem is in a dirty state, like after sudden
power-off. In that case 'noload' is needed so the kernel doesn't
attempt to recover the newest data by replaying the journal, which
would fail without write access.

Perhaps this should be added to the documentation.

Redirecting… :slight_smile:

I read the notes about your split-dmcrypt-tool. Good work! Let's
assume I would not work with LUKS. Suppose I mount sda1 with
read-only option set in a DispVM (after switching off its network),
decrypt it there and search in the files. An exploit bug occurs and
the VM is taken. Now it could happen that someone leaks the
partition password to the internet via a covered channel. So would
it be safer to mount the decrypted volume again in another DispVM
before we search it?

Yes, assuming that the exploit is inside the *decrypted* data. Then
that second offline DisposableVM would not have access to the (tiny)
password, so it would only be able to slowly transmit the (huge)
decrypted data over such a hypothetical covert channel.

And how would that be done? With the loopdevice method? What
commands would you use in the terminal?

[dom0]# qvm-block attach --ro disp1 sys-usb:sda1

[disp1]# echo Y >/sys/module/block/parameters/no_part_scan
[disp1]# (somehow decrypt /dev/xvdi, yielding a device /dev/mapper/something)
[disp1]# readlink /dev/mapper/something
../dm-0

[dom0]# qvm-block attach --ro disp2 disp1:dm-0

[disp2]# (mount /dev/mapper/xvdi)

Rusty

4

Dear Rusty Bird,

thank you for your help. I tried to get it done, but there is a problem:

After decryption, my file system presents itself to me as an ordinary directory that I find somewhere under /media/xy. The encryption program used works in a way that the device in /dev/xvdi is always encrypted. Only what is currently accessed in the /media/xy folder is decrypted. Consequently, it does not work if I use the following command to create a loop that I then mount in another qube, because it will not be decrypted there:

$disp1: sudo losetup -r /dev/loop0 /dev/xvdi

Unfortunately, I have not been able to mount or loop a directory to another qube via dom0 and the qvm-block command. I can mount a directory somewhere in the same qube using the mount tool, but I cannot make it available to dom0:
sudo mount -r -o bind /media/xy /home/user/xy

How could I solve this? What commands are necessary in disp1?

Best regards
Michael Singer

5

Why not

     sudo losetup -r /dev/loop0 /media/xy

?? That is what I do alwys, at works fine. After that, the widget (for
example) allows to attach /dev/loop0 to other qubes. Best