lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 6 Jul 2020 20:08:35 -0700
From:   Kees Cook <>
To:     Scott Branden <>
Cc:     Luis Chamberlain <>,
        Wolfram Sang <>,
        Greg Kroah-Hartman <>,
        David Brown <>,
        Alexander Viro <>,
        Shuah Khan <>,,
        Shuah Khan <>,
        Arnd Bergmann <>,
        Mimi Zohar <>,
        "Rafael J . Wysocki" <>,,,,
        BCM Kernel Feedback <>,
        Olof Johansson <>,
        Andrew Morton <>,
        Dan Carpenter <>,
        Colin Ian King <>,
        Takashi Iwai <>,,
        Andy Gross <>,,
Subject: Re: [PATCH v10 9/9] ima: add FIRMWARE_PARTIAL_READ support

On Mon, Jul 06, 2020 at 04:23:09PM -0700, Scott Branden wrote:
> Add FIRMWARE_PARTIAL_READ support for integrity
> measurement on partial reads of firmware files.


Several versions ago I'd suggested that the LSM infrastructure handle
the "full read" semantics so that individual LSMs don't need to each
duplicate the same efforts. As it happens, only IMA is impacted (SELinux
ignores everything except modules, and LoadPin only cares about origin
not contents).

Next is the problem that enum kernel_read_file_id is an object
TYPE enum, not a HOW enum. (And it seems I missed the addition of
READING_FIRMWARE_PREALLOC_BUFFER, which may share a similar problem.)
That it's a partial read doesn't change _what_ you're reading: that's an
internal API detail. What happens when I attempt to do a partial read of
a kexec image? I'll use kernel_pread_file() and pass READING_KEXEC_IMAGE,
but the LSMs will have no idea it's a partial read.

Finally, what keeps the contents of the file from changing between the
first call (which IMA will read the entire file for) and the next reads
which will bypass IMA? I'd suggested that the open file must have writes
disabled on it (as execve() does).

So, please redesign this:
- do not add an enum
- make the file unwritable for the life of having the handle open
- make the "full read" happen as part of the first partial read so the
  LSMs don't have to reimplement everything


Kees Cook

Powered by blists - more mailing lists