-----BEGIN PGP SIGNED MESSAGE-----
> Michael Singer:
> > I had to find a way to mount the read-only volume in the destination
> > qube. I discovered the page
> > https://www.qubes-os.org/doc/block-devices/
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.
> > 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
> [dom0]# qvm-block attach --ro disp2 disp1:dm-0
> [disp2]# (mount /dev/mapper/xvdi)
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----