The safest way to search in files on an external hard drive
33 views
Skip to first unread message
Michael Singer
May 31, 2021, 10:55:18 AM5/31/21
to qubes...@googlegroups.com
Dear Qubes community,
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?
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?
Best regards
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?
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?
Best regards
Michael Singer
Rusty Bird
Jun 3, 2021, 9:29:11 AM6/3/21
to Michael Singer, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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] https://github.com/rustybird/qubes-split-dm-crypt
Rusty
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmC41rFfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt/Lyw//cZIGHFtGNqEbBSIoNlWgNuxQxpfbaNrgkfnRyzqRQgJ99qgZU7rCJmTq
OygfKEE+Iwgnn6MdYDjvIG1JSAAW6hBonAYDpIGRNWFdJGHppJvxOvVSH7zlni/8
xwQjrn2X3NnMhlEBLNMibyx5Sc7GpId+/nEaz3UXhb1g7METBk1AVzLc20HOT5Ga
5zeaBz+6BoXi7YUoBYkCgU2GbuiOK6ZGgTJ5ekCP+iT0tTbZ8s97XNmmBe2oPHgP
IHpPBgezjnG8az7Z7uRC1BHYQQx4mKEC2K9LOSUmWkqZiPFmJ+OYgdAt4GSzJjka
TvJQK17rNuFy3+vvfipmI94IhBClV0PnT55YKQgE1KBEyxi5Rs179wIY5Jx68emp
BgpFUdsUK1CPxbdPixUESLf2jzkgQwN9h1GtFiX5sFWdldAUXqyHEmKobnyxAQEG
Hz6S2d2SiR88USW1D4f/dFsRSi3ef1EcCKI6nzTISnJ+vHWFG6r6gzTSN4pHWpI0
irbGR4KfI1rAwk9fk4YV+BFSXhHI8af17mvU3ot9qB2lI1JfIljMBG6se7ad2YDd
FdMJVwtkuJmRCf9PfG3InB2wqX71eIwKFlb+oviAcyGJZHvEH2wdmeiQCj6jhPCw
hHUtGl0eVHrVGV4hw34oCzjoaM1V+8TU5msvxd6lTIgAcrUqFZ8=
=7/h+
-----END PGP SIGNATURE-----
Hash: SHA512
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?
$ 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?
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] https://github.com/rustybird/qubes-split-dm-crypt
Rusty
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmC41rFfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt/Lyw//cZIGHFtGNqEbBSIoNlWgNuxQxpfbaNrgkfnRyzqRQgJ99qgZU7rCJmTq
OygfKEE+Iwgnn6MdYDjvIG1JSAAW6hBonAYDpIGRNWFdJGHppJvxOvVSH7zlni/8
xwQjrn2X3NnMhlEBLNMibyx5Sc7GpId+/nEaz3UXhb1g7METBk1AVzLc20HOT5Ga
5zeaBz+6BoXi7YUoBYkCgU2GbuiOK6ZGgTJ5ekCP+iT0tTbZ8s97XNmmBe2oPHgP
IHpPBgezjnG8az7Z7uRC1BHYQQx4mKEC2K9LOSUmWkqZiPFmJ+OYgdAt4GSzJjka
TvJQK17rNuFy3+vvfipmI94IhBClV0PnT55YKQgE1KBEyxi5Rs179wIY5Jx68emp
BgpFUdsUK1CPxbdPixUESLf2jzkgQwN9h1GtFiX5sFWdldAUXqyHEmKobnyxAQEG
Hz6S2d2SiR88USW1D4f/dFsRSi3ef1EcCKI6nzTISnJ+vHWFG6r6gzTSN4pHWpI0
irbGR4KfI1rAwk9fk4YV+BFSXhHI8af17mvU3ot9qB2lI1JfIljMBG6se7ad2YDd
FdMJVwtkuJmRCf9PfG3InB2wqX71eIwKFlb+oviAcyGJZHvEH2wdmeiQCj6jhPCw
hHUtGl0eVHrVGV4hw34oCzjoaM1V+8TU5msvxd6lTIgAcrUqFZ8=
=7/h+
-----END PGP SIGNATURE-----
Ulrich Windl
Jun 9, 2021, 4:46:54 PM6/9/21
to qubes...@googlegroups.com
On 5/31/21 4:55 PM, Michael Singer wrote:
> Dear Qubes community,
>
> 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.
If your app is working on the disk device and the app only has read
> Dear Qubes community,
>
> 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.
access to it, it'll be quite unlikely that the disk device will be changed.
Likewise if you mount the filesystem read-only, and the user running the
app is unable to re-mount, it's also quite unlikely that the disk will
be changed. You could even try to combine both methods (read-only mount
a read-only block device). However not all filesystems work on a
write-protected block device.
You could also try to find a hardware solution setting the drive read-only.
haaber
Jun 9, 2021, 5:02:46 PM6/9/21
to qubes...@googlegroups.com
On 6/9/21 10:46 PM, Ulrich Windl wrote:
> On 5/31/21 4:55 PM, Michael Singer wrote:
>> Dear Qubes community,
>>
>> 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.
>
> If your app is working on the disk device and the app only has read
> access to it, it'll be quite unlikely that the disk device will be changed.
> Likewise if you mount the filesystem read-only, and the user running the
> app is unable to re-mount, it's also quite unlikely that the disk will
> be changed. You could even try to combine both methods (read-only mount
> a read-only block device). However not all filesystems work on a
> write-protected block device.
A variant: mount it RO in AppVM1, then attach it to AppVM2 (which by no
> On 5/31/21 4:55 PM, Michael Singer wrote:
>> Dear Qubes community,
>>
>> 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.
>
> If your app is working on the disk device and the app only has read
> access to it, it'll be quite unlikely that the disk device will be changed.
> Likewise if you mount the filesystem read-only, and the user running the
> app is unable to re-mount, it's also quite unlikely that the disk will
> be changed. You could even try to combine both methods (read-only mount
> a read-only block device). However not all filesystems work on a
> write-protected block device.
means can "remount -rw" it unless interVM-barriers are breached (and
game is over anyways).
Michael Singer
Jun 17, 2021, 5:50:26 AM6/17/21
to Rusty Bird, qubes...@googlegroups.com
> Michael Singer:
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 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. 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
>
>> 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.
>
>> 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?
>
>> 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.
>
>
> $ 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?
>
>> 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] https://github.com/rustybird/qubes-split-dm-crypt
>
> Rusty>
Dear Rusty Bird,
> 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] https://github.com/rustybird/qubes-split-dm-crypt
>
> Rusty>
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 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. 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
Rusty Bird
Jun 19, 2021, 10:02:54 AM6/19/21
to Michael Singer, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rusty Bird:
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 -
> > 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.
>
> 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 :)
> > 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
> > 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?
>
> 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
> > And how would that be done? With the loopdevice method? What
> > commands would you use in the terminal?
>
>
> [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/hsG0ERp149HqvKt8FAmDN6ldfFIAAAAAALgAo
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-----
Rusty Bird
Jun 19, 2021, 10:02:54 AM6/19/21
to Michael Singer, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Michael Singer:
Hash: SHA512
> 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.
> 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.
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.
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?
> 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]# 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+hfFIAAAAAALgAo
[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-----
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-----
Michael Singer
Jul 9, 2021, 6:01:46 AM7/9/21
to qubes...@googlegroups.com, Rusty Bird
Am 19.06.21 um 15:00 schrieb 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
>
>> [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
>
Dear Rusty Bird,
>> [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
>
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
haaber
Jul 9, 2021, 9:04:52 AM7/9/21
to qubes...@googlegroups.com
On 7/9/21 12:01 PM, Michael Singer wrote:
>
> 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
Why not
>
> 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
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
Michael Singer
Jul 12, 2021, 7:02:52 AM7/12/21
to qubes...@googlegroups.com
On 7/9/21 12:01 PM, Michael Singer wrote:
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
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
On 7/9/21 18:04 PM, haaber wrote:
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
Dear Bernhard,
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
this way it works only, if /media/xy would be a device. But it is an ordinary directory
and losetup says: invalid argument.
Best regards
Michael Singer
Reply all
Reply to author
Forward
0 new messages