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

2021-06-19 Thread Rusty Bird
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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.

https://www.qubes-os.org/doc/doc-guidelines/#how-to-contribute :)

> 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
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmDN4+hfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt+f0BAAhcWwf+7Ch3fR1qabYxGP0uVbbyvODNa+V8ipHcBS2Nyl7QedxL0BZgTt
8HGIoTlngD4jALNDq3Sl5Btv62aEM0Gel3VuozeJeUOpzuvE1eMOrxxPhMQRexNw
rW08pZQM6ILojYndnJZpTCr9Rfa4cuYJ9Ie0V+CWpITutiZZLzhF8cYIDORVynND
wrrNnP2BdClRU2caH39qRpW5JNYuwT+bIITiZQbTFoWQFICRrasD2zkcQQgNZFdt
f8O2nFgmtCHHBwDXzYuSLYdUKp/gTztawqFDBv8exANiQykW19WqZLG1rcha8Wyt
PnyuN3DZhu8NWMVFF3DNQZ6T+TqeG8G+V1VTiDFX2t5CfUaE04zS6vzKMxs4dpNs
Ce81P3DMu9iqG7oxAqASFHw/Ud0FtDej8FZfeiQVZKtadcbYu09seLllc7QtQDUO
tqDgBX2ZEcuN/Ssp4t5p1PHFPfBV3bLzkQYv3cJgqD68maybVgrPXhxvP6NwSmOe
zmW8WW6zv/PI8c2+WAnI4zQdUoxv/ImXDgAXbQ65HueKISlr3mSNxdwPkccngg61
nf4OR8L8/74XPV5WbQmFXMGf7m5e48CsdD7+YQiTqiO9Vm3YWiufDaxh7Wv4D7Ux
ifH75jzOEWE3y+bakbL1wAp9+UJe8t0wtneHVJeQ5SZ3n1CCjyE=
=m4iy
-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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/YM3j6FQAdHWkZZEV%40mutt.


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

2021-06-19 Thread Rusty Bird
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Rusty Bird:
> 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.
> 
> https://www.qubes-os.org/doc/doc-guidelines/#how-to-contribute :)
> 
> > 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
https://github.com/rustybird/qubes-split-dm-crypt/blob/master/vm/rules.d/00-blockdev-parsing-disabled.rules
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
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmDN6ldfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt9jHRAAh9DijI2gvJMrJuV8Cfoqvh/ue17I/YMwpF4JxAXup8Z5LsQDKLmwJHHZ
4l6DOoI9dAwn5tdviCpjmP0B46cFWPeqJ7bcLsRbFxywr7A9Kl1lug9sUgCUwaDN
zFhBb37X7LuG/YxaW1+eavE6r3f/wqEVZjC4+oGHMLMXR9wZPlmkCA5WcUxONl6G
1X8coDNOAyeVl1RGu+wA1ExhPJlPJJosM56zy15dtanEZx4egb7E5WKwN0HMm73x
ao5eiriPKXSmvIq5puy6wJbW0t0WHqU1f7UM2R25At0qWNEhAMtGiLzwA8wL2e3A
J3yZcP2ZV/5uAhrPYjY7i3h5LDXWY6vO8P4IJds2QdpYBGZV6EC3PfadYguRpAJQ
SGJQmzJqYncjvmMpLDiMLD9wNvGf/ExTObcwWN9n7G4yh4PFMGH0KL4Gp9vi8gcV
k41zIswW51lGwiieYgQT+AW0z3eM31sghp69ojQk9Vcvzj5GIDtbNmtYGKkzC85X
VCE7EpkMcTARIijOrntL8ykQGGEv8agpLISVk8iENLM48HgVutQfSG5okSdAD2x6
LWauik0j3WvvJnqoGHK56OvvTCOrf21lYgFuCakH5GvSO11oSgMr1VH5cwiuYnds
2L2qJ948Z0IhHI+AH557VGEUS95XEe5yJGqyW0XLRnYNwKP61HE=
=+Zl/
-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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/YM3qV1X9wMRelfc9%40mutt.