On Wed, 2020-05-13 at 16:34 -0700, Kees Cook wrote:
On Wed, May 13, 2020 at 07:00:43PM -0400, Mimi Zohar wrote:
On Wed, 2020-05-13 at 15:48 -0700, Scott Branden wrote:
On 2020-05-13 3:12 p.m., Mimi Zohar wrote:
On Wed, 2020-05-13 at 21:28 +0000, Luis Chamberlain wrote:
On Wed, May 13, 2020 at 05:20:14PM -0400, Mimi Zohar wrote:
On Wed, 2020-05-13 at 12:41 -0700, Scott Branden wrote: > On 2020-05-13 12:39 p.m., Mimi Zohar wrote: >> On Wed, 2020-05-13 at 12:18 -0700, Scott Branden wrote: >>> On 2020-05-13 12:03 p.m., Mimi Zohar wrote: >>>> On Wed, 2020-05-13 at 11:53 -0700, Scott Branden wrote: >>> Even if the kernel successfully verified the firmware file signature it >>> would just be wasting its time. The kernel in these use cases is not always >>> trusted. The device needs to authenticate the firmware image itself. >> There are also environments where the kernel is trusted and limits the >> firmware being provided to the device to one which they signed. >> >>>> The device firmware is being downloaded piecemeal from somewhere and >>>> won't be measured? >>> It doesn't need to be measured for current driver needs. >> Sure the device doesn't need the kernel measuring the firmware, but >> hardened environments do measure firmware. >> >>> If someone has such need the infrastructure could be added to the kernel >>> at a later date. Existing functionality is not broken in any way by >>> this patch series. >> Wow! You're saying that your patch set takes precedence over the >> existing expectations and can break them. > Huh? I said existing functionality is NOT broken by this patch series. Assuming a system is configured to measure and appraise firmware (rules below), with this change the firmware file will not be properly measured and will fail signature verification.
So no existing functionality has been broken.
Sample IMA policy rules: measure func=FIRMWARE_CHECK appraise func=FIRMWARE_CHECK appraise_type=imasig
Would a pre and post lsm hook for pread do it?
IMA currently measures and verifies the firmware file signature on the post hook. The file is read once into a buffer. With this change, IMA would need to be on the pre hook, to read the entire file, calculating the file hash and verifying the file signature. Basically the firmware would be read once for IMA and again for the device.
The entire file may not fit into available memory to measure and verify. Hence the reason for a partial read.
Previously, IMA pre-read the file in page size chunks in order to calculate the file hash. To avoid reading the file twice, the file is now read into a buffer.
Can the VFS be locked in some way and then using the partial reads would trigger the "read twice" mode? I.e. something like:
open first partial read: lock file contents (?) perform full page-at-a-time-read-and-measure rewind, read partial other partial reads final partial read unlock
The security_kernel_read_file(), the pre-hook, would need to be moved after getting the file size, but yes that's exactly what would be done in the pre-hook, when the current offset is 0 and the file size and buffer size aren't the same.
Mimi