On Tue, 2 Jun 2020 at 12:12, Vladimir 'phcoder' Serbinenko
<phcoder@gmail.com> wrote:
>
>
>
> On Mon, Jun 1, 2020, 15:21 Chris Coulson <chris.coulson@canonical.com> wrote:
>>
>> When a file is verified, the entire contents of the verified file are
>> loaded in to memory and retained until the file handle is closed. A
>> consequence of this is that opening a loopback image can incur a
>> significant memory cost.
>>
>> As loopback devices are just another disk implementation, don't treat
>> loopback images any differently to physical disk images, and skip
>> verification of them. Files opened from the filesystem within a loopback
>> image will still be passed to verifier modules where required.
>>
>> Signed-off-by: Chris Coulson <chris.coulson@canonical.com>
>> ---
>> grub-core/disk/loopback.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/grub-core/disk/loopback.c b/grub-core/disk/loopback.c
>> index cdf9123fa..01267e577 100644
>> --- a/grub-core/disk/loopback.c
>> +++ b/grub-core/disk/loopback.c
>> @@ -93,7 +93,8 @@ grub_cmd_loopback (grub_extcmd_context_t ctxt, int argc, char **args)
>> return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("filename expected"));
>>
>> file = grub_file_open (args[1], GRUB_FILE_TYPE_LOOPBACK
>> - | GRUB_FILE_TYPE_NO_DECOMPRESS);
>> + | GRUB_FILE_TYPE_NO_DECOMPRESS |
>> + GRUB_FILE_TYPE_SKIP_SIGNATURE);
>
> Maybe the verifier should rather decide to skip verification if fuller type is loopback?
How would it be used then? For example, I imagine one can gpg sign the
.iso or a .squashfs and then assume everything inside it is trusted
(even if things inside are not signed).
However, I don't believe any verifier works this way today, nor not
sure it is desired versus signing individual things inside the
loopback device.
At the moment, without this patch, a lot of things break. It is common
to loopback mount .iso which currently eats all the RAM and machines
crash with out of memory. (I.e. loopback mounting 2.5GB .iso).
Similarly it is common to use things like WUBI, where .raw image file
is loopback mounted from NTFS. If one is doing secureboot and tpm is
present that again results in out of memory.
Taking the measurement / checksum / verifying the loopback device is
not a problem, but keeping it all in RAM is. And imho trusting
unsigned things inside verified loopback device is dubious too.
So yeah, probably it's something that verifiers should be able to
decide upon and perform intelligently. But at the moment, the only
practical answer for all of them is to skip.
GPG one can read the file in chunks and then keep in memory only hash of every chunk to prevent TOCTOU.
But then the question is when is our makes sense versus signing individual files. I can see uses like signing squashfs.
We probably need a "secure device" flag somewhere long term
Preventing TOCTOU is nice.
And "secure device" is a nice concept.
For example a policy can consider contents of LUKS2 encrypted or dmverity sealed /boot to be trusted. Because encryption prevents tampering with that filesystem. Especially if it is not decrypted or mounted at runtime.
Do we need to add comments here to explain the design thinking for future improvements? Or should we change verifiers with a link to a TODO comment explaining what could be done to make this better?
Or should we hide this flag behind an argument
--skip-sig of the loopback command to give scripting flexibility?