Linux-Integrity Archive on lore.kernel.org
 help / color / Atom feed
* Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
       [not found] ` <20200508002739.19360-2-scott.branden@broadcom.com>
@ 2020-05-13 18:39   ` Mimi Zohar
  2020-05-13 18:53     ` Scott Branden
  0 siblings, 1 reply; 14+ messages in thread
From: Mimi Zohar @ 2020-05-13 18:39 UTC (permalink / raw)
  To: Scott Branden, Luis Chamberlain, Greg Kroah-Hartman, David Brown,
	Alexander Viro, Shuah Khan, bjorn.andersson, Shuah Khan,
	Arnd Bergmann
  Cc: Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson, Andrew Morton,
	Dan Carpenter, Colin Ian King, Kees Cook, Takashi Iwai,
	linux-kselftest, Andy Gross, linux-security-module,
	linux-integrity

[Cc'ing linux-security-module, linux-integrity]

On Thu, 2020-05-07 at 17:27 -0700, Scott Branden wrote:
> Add kernel_pread_file* support to kernel to allow for partial read
> of files with an offset into the file.  Existing kernel_read_file
> functions call new kernel_pread_file functions with offset=0 and
> flags=KERNEL_PREAD_FLAG_WHOLE.
> 
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> ---

<snip>

> @@ -941,14 +955,16 @@ int kernel_read_file(struct file *file, void **buf, loff_t *size,
>  
>  		if (bytes == 0)
>  			break;
> +
> +		buf_pos += bytes;
>  	}
>  
> -	if (pos != i_size) {
> +	if (pos != read_end) {
>  		ret = -EIO;
>  		goto out_free;
>  	}
>  
> -	ret = security_kernel_post_read_file(file, *buf, i_size, id);
> +	ret = security_kernel_post_read_file(file, *buf, alloc_size, id);
>  	if (!ret)
>  		*size = pos;

Prior to the patch set that introduced this security hook, firmware
would be read twice, once for measuring/appraising the firmware and
again reading the file contents into memory.  Partial reads will break
both IMA's measuring the file and appraising the file signatures.

Mimi

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
  2020-05-13 18:39   ` [PATCH v5 1/7] fs: introduce kernel_pread_file* support Mimi Zohar
@ 2020-05-13 18:53     ` Scott Branden
  2020-05-13 18:57       ` Scott Branden
  2020-05-13 19:03       ` Mimi Zohar
  0 siblings, 2 replies; 14+ messages in thread
From: Scott Branden @ 2020-05-13 18:53 UTC (permalink / raw)
  To: Mimi Zohar, Luis Chamberlain, Greg Kroah-Hartman, David Brown,
	Alexander Viro, Shuah Khan, bjorn.andersson, Shuah Khan,
	Arnd Bergmann
  Cc: Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson, Andrew Morton,
	Dan Carpenter, Colin Ian King, Kees Cook, Takashi Iwai,
	linux-kselftest, Andy Gross, linux-security-module,
	linux-integrity

Hi Mimi,

On 2020-05-13 11:39 a.m., Mimi Zohar wrote:
> [Cc'ing linux-security-module, linux-integrity]
>
> On Thu, 2020-05-07 at 17:27 -0700, Scott Branden wrote:
>> Add kernel_pread_file* support to kernel to allow for partial read
>> of files with an offset into the file.  Existing kernel_read_file
>> functions call new kernel_pread_file functions with offset=0 and
>> flags=KERNEL_PREAD_FLAG_WHOLE.
>>
>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>> ---
> <snip>
>
>> @@ -941,14 +955,16 @@ int kernel_read_file(struct file *file, void **buf, loff_t *size,
The checkpatch shows this as kernel_read_file when it is actually the 
new function kernel_pread_file.
Please see the call to kernel_pread_file from kernel_read_file in the 
complete patch rather this snippet.
>>   
>>   		if (bytes == 0)
>>   			break;
>> +
>> +		buf_pos += bytes;
>>   	}
>>   
>> -	if (pos != i_size) {
>> +	if (pos != read_end) {
>>   		ret = -EIO;
>>   		goto out_free;
>>   	}
>>   
>> -	ret = security_kernel_post_read_file(file, *buf, i_size, id);
>> +	ret = security_kernel_post_read_file(file, *buf, alloc_size, id);
>>   	if (!ret)
>>   		*size = pos;
> Prior to the patch set that introduced this security hook, firmware
> would be read twice, once for measuring/appraising the firmware and
> again reading the file contents into memory.  Partial reads will break
> both IMA's measuring the file and appraising the file signatures.
The partial file read support is needed for request_firmware_into_buf 
from drivers.  The EXPORT_SYMBOL_GPL is being removed so that
there can be no abuse of the partial file read support.  Such file 
integrity checks are not needed for this use case.  The partial file 
(firmware image) is actually downloaded in portions and verified on the 
device it is loaded to.

Regards,
  Scott

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
  2020-05-13 18:53     ` Scott Branden
@ 2020-05-13 18:57       ` Scott Branden
  2020-05-13 19:03       ` Mimi Zohar
  1 sibling, 0 replies; 14+ messages in thread
From: Scott Branden @ 2020-05-13 18:57 UTC (permalink / raw)
  To: Mimi Zohar, Luis Chamberlain, Greg Kroah-Hartman, David Brown,
	Alexander Viro, Shuah Khan, bjorn.andersson, Shuah Khan,
	Arnd Bergmann
  Cc: Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson, Andrew Morton,
	Dan Carpenter, Colin Ian King, Kees Cook, Takashi Iwai,
	linux-kselftest, Andy Gross, linux-security-module,
	linux-integrity



On 2020-05-13 11:53 a.m., Scott Branden wrote:
> Hi Mimi,
>
> On 2020-05-13 11:39 a.m., Mimi Zohar wrote:
>> [Cc'ing linux-security-module, linux-integrity]
>>
>> On Thu, 2020-05-07 at 17:27 -0700, Scott Branden wrote:
>>> Add kernel_pread_file* support to kernel to allow for partial read
>>> of files with an offset into the file.  Existing kernel_read_file
>>> functions call new kernel_pread_file functions with offset=0 and
>>> flags=KERNEL_PREAD_FLAG_WHOLE.
>>>
>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>> ---
>> <snip>
>>
>>> @@ -941,14 +955,16 @@ int kernel_read_file(struct file *file, void 
>>> **buf, loff_t *size,
> The checkpatch shows this as kernel_read_file when it is actually the 
> new function kernel_pread_file.
typo: "checkpatch" should be "patch diff"
> Please see the call to kernel_pread_file from kernel_read_file in the 
> complete patch rather this snippet.
>>>             if (bytes == 0)
>>>               break;
>>> +
>>> +        buf_pos += bytes;
>>>       }
>>>   -    if (pos != i_size) {
>>> +    if (pos != read_end) {
>>>           ret = -EIO;
>>>           goto out_free;
>>>       }
>>>   -    ret = security_kernel_post_read_file(file, *buf, i_size, id);
>>> +    ret = security_kernel_post_read_file(file, *buf, alloc_size, id);
>>>       if (!ret)
>>>           *size = pos;
>> Prior to the patch set that introduced this security hook, firmware
>> would be read twice, once for measuring/appraising the firmware and
>> again reading the file contents into memory.  Partial reads will break
>> both IMA's measuring the file and appraising the file signatures.
> The partial file read support is needed for request_firmware_into_buf 
> from drivers.  The EXPORT_SYMBOL_GPL is being removed so that
> there can be no abuse of the partial file read support.  Such file 
> integrity checks are not needed for this use case.  The partial file 
> (firmware image) is actually downloaded in portions and verified on 
> the device it is loaded to.
>
> Regards,
>  Scott


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
  2020-05-13 18:53     ` Scott Branden
  2020-05-13 18:57       ` Scott Branden
@ 2020-05-13 19:03       ` Mimi Zohar
  2020-05-13 19:18         ` Scott Branden
  1 sibling, 1 reply; 14+ messages in thread
From: Mimi Zohar @ 2020-05-13 19:03 UTC (permalink / raw)
  To: Scott Branden, Luis Chamberlain, Greg Kroah-Hartman, David Brown,
	Alexander Viro, Shuah Khan, bjorn.andersson, Shuah Khan,
	Arnd Bergmann
  Cc: Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson, Andrew Morton,
	Dan Carpenter, Colin Ian King, Kees Cook, Takashi Iwai,
	linux-kselftest, Andy Gross, linux-security-module,
	linux-integrity

On Wed, 2020-05-13 at 11:53 -0700, Scott Branden wrote:
> Hi Mimi,
> 
> On 2020-05-13 11:39 a.m., Mimi Zohar wrote:
> > [Cc'ing linux-security-module, linux-integrity]
> >
> > On Thu, 2020-05-07 at 17:27 -0700, Scott Branden wrote:
> >> Add kernel_pread_file* support to kernel to allow for partial read
> >> of files with an offset into the file.  Existing kernel_read_file
> >> functions call new kernel_pread_file functions with offset=0 and
> >> flags=KERNEL_PREAD_FLAG_WHOLE.
> >>
> >> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> >> ---
> > <snip>
> >
> >> @@ -941,14 +955,16 @@ int kernel_read_file(struct file *file, void **buf, loff_t *size,
> The checkpatch shows this as kernel_read_file when it is actually the 
> new function kernel_pread_file.
> Please see the call to kernel_pread_file from kernel_read_file in the 
> complete patch rather this snippet.
> >>   
> >>   		if (bytes == 0)
> >>   			break;
> >> +
> >> +		buf_pos += bytes;
> >>   	}
> >>   
> >> -	if (pos != i_size) {
> >> +	if (pos != read_end) {
> >>   		ret = -EIO;
> >>   		goto out_free;
> >>   	}
> >>   
> >> -	ret = security_kernel_post_read_file(file, *buf, i_size, id);
> >> +	ret = security_kernel_post_read_file(file, *buf, alloc_size, id);
> >>   	if (!ret)
> >>   		*size = pos;
> > Prior to the patch set that introduced this security hook, firmware
> > would be read twice, once for measuring/appraising the firmware and
> > again reading the file contents into memory.  Partial reads will break
> > both IMA's measuring the file and appraising the file signatures.
> The partial file read support is needed for request_firmware_into_buf 
> from drivers.  The EXPORT_SYMBOL_GPL is being removed so that
> there can be no abuse of the partial file read support.  Such file 
> integrity checks are not needed for this use case.  The partial file 
> (firmware image) is actually downloaded in portions and verified on the 
> device it is loaded to.

It's all fine that the device will verify the firmware, but shouldn't
the kernel be able to also verify the firmware file signature it is
providing to the device, before providing it?

The device firmware is being downloaded piecemeal from somewhere and
won't be measured?

Mimi

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
  2020-05-13 19:03       ` Mimi Zohar
@ 2020-05-13 19:18         ` Scott Branden
  2020-05-13 19:39           ` Mimi Zohar
  0 siblings, 1 reply; 14+ messages in thread
From: Scott Branden @ 2020-05-13 19:18 UTC (permalink / raw)
  To: Mimi Zohar, Luis Chamberlain, Greg Kroah-Hartman, David Brown,
	Alexander Viro, Shuah Khan, bjorn.andersson, Shuah Khan,
	Arnd Bergmann
  Cc: Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson, Andrew Morton,
	Dan Carpenter, Colin Ian King, Kees Cook, Takashi Iwai,
	linux-kselftest, Andy Gross, linux-security-module,
	linux-integrity



On 2020-05-13 12:03 p.m., Mimi Zohar wrote:
> On Wed, 2020-05-13 at 11:53 -0700, Scott Branden wrote:
>> Hi Mimi,
>>
>> On 2020-05-13 11:39 a.m., Mimi Zohar wrote:
>>> [Cc'ing linux-security-module, linux-integrity]
>>>
>>> On Thu, 2020-05-07 at 17:27 -0700, Scott Branden wrote:
>>>> Add kernel_pread_file* support to kernel to allow for partial read
>>>> of files with an offset into the file.  Existing kernel_read_file
>>>> functions call new kernel_pread_file functions with offset=0 and
>>>> flags=KERNEL_PREAD_FLAG_WHOLE.
>>>>
>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>> ---
>>> <snip>
>>>
>>>> @@ -941,14 +955,16 @@ int kernel_read_file(struct file *file, void **buf, loff_t *size,
>> The checkpatch shows this as kernel_read_file when it is actually the
>> new function kernel_pread_file.
>> Please see the call to kernel_pread_file from kernel_read_file in the
>> complete patch rather this snippet.
>>>>    
>>>>    		if (bytes == 0)
>>>>    			break;
>>>> +
>>>> +		buf_pos += bytes;
>>>>    	}
>>>>    
>>>> -	if (pos != i_size) {
>>>> +	if (pos != read_end) {
>>>>    		ret = -EIO;
>>>>    		goto out_free;
>>>>    	}
>>>>    
>>>> -	ret = security_kernel_post_read_file(file, *buf, i_size, id);
>>>> +	ret = security_kernel_post_read_file(file, *buf, alloc_size, id);
>>>>    	if (!ret)
>>>>    		*size = pos;
>>> Prior to the patch set that introduced this security hook, firmware
>>> would be read twice, once for measuring/appraising the firmware and
>>> again reading the file contents into memory.  Partial reads will break
>>> both IMA's measuring the file and appraising the file signatures.
>> The partial file read support is needed for request_firmware_into_buf
>> from drivers.  The EXPORT_SYMBOL_GPL is being removed so that
>> there can be no abuse of the partial file read support.  Such file
>> integrity checks are not needed for this use case.  The partial file
>> (firmware image) is actually downloaded in portions and verified on the
>> device it is loaded to.
> It's all fine that the device will verify the firmware, but shouldn't
> the kernel be able to also verify the firmware file signature it is
> providing to the device, before providing it?
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.
>
> 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.
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.
>
> Mimi


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
  2020-05-13 19:18         ` Scott Branden
@ 2020-05-13 19:39           ` Mimi Zohar
  2020-05-13 19:41             ` Scott Branden
  0 siblings, 1 reply; 14+ messages in thread
From: Mimi Zohar @ 2020-05-13 19:39 UTC (permalink / raw)
  To: Scott Branden, Luis Chamberlain, Greg Kroah-Hartman, David Brown,
	Alexander Viro, Shuah Khan, bjorn.andersson, Shuah Khan,
	Arnd Bergmann
  Cc: Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson, Andrew Morton,
	Dan Carpenter, Colin Ian King, Kees Cook, Takashi Iwai,
	linux-kselftest, Andy Gross, linux-security-module,
	linux-integrity

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.

Mimi

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
  2020-05-13 19:39           ` Mimi Zohar
@ 2020-05-13 19:41             ` Scott Branden
  2020-05-13 21:20               ` Mimi Zohar
  0 siblings, 1 reply; 14+ messages in thread
From: Scott Branden @ 2020-05-13 19:41 UTC (permalink / raw)
  To: Mimi Zohar, Luis Chamberlain, Greg Kroah-Hartman, David Brown,
	Alexander Viro, Shuah Khan, bjorn.andersson, Shuah Khan,
	Arnd Bergmann
  Cc: Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson, Andrew Morton,
	Dan Carpenter, Colin Ian King, Kees Cook, Takashi Iwai,
	linux-kselftest, Andy Gross, linux-security-module,
	linux-integrity



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.
>
> Mimi


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
  2020-05-13 19:41             ` Scott Branden
@ 2020-05-13 21:20               ` Mimi Zohar
  2020-05-13 21:28                 ` Luis Chamberlain
  0 siblings, 1 reply; 14+ messages in thread
From: Mimi Zohar @ 2020-05-13 21:20 UTC (permalink / raw)
  To: Scott Branden, Luis Chamberlain, Greg Kroah-Hartman, David Brown,
	Alexander Viro, Shuah Khan, bjorn.andersson, Shuah Khan,
	Arnd Bergmann
  Cc: Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson, Andrew Morton,
	Dan Carpenter, Colin Ian King, Kees Cook, Takashi Iwai,
	linux-kselftest, Andy Gross, linux-security-module,
	linux-integrity

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.

Sample IMA policy rules:
measure func=FIRMWARE_CHECK
appraise func=FIRMWARE_CHECK appraise_type=imasig

Mimi

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
  2020-05-13 21:20               ` Mimi Zohar
@ 2020-05-13 21:28                 ` Luis Chamberlain
  2020-05-13 22:12                   ` Mimi Zohar
  0 siblings, 1 reply; 14+ messages in thread
From: Luis Chamberlain @ 2020-05-13 21:28 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: Scott Branden, Greg Kroah-Hartman, David Brown, Alexander Viro,
	Shuah Khan, bjorn.andersson, Shuah Khan, Arnd Bergmann,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson, Andrew Morton,
	Dan Carpenter, Colin Ian King, Kees Cook, Takashi Iwai,
	linux-kselftest, Andy Gross, linux-security-module,
	linux-integrity

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.
> 
> 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?

  Luis

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
  2020-05-13 21:28                 ` Luis Chamberlain
@ 2020-05-13 22:12                   ` Mimi Zohar
  2020-05-13 22:48                     ` Scott Branden
  0 siblings, 1 reply; 14+ messages in thread
From: Mimi Zohar @ 2020-05-13 22:12 UTC (permalink / raw)
  To: Luis Chamberlain
  Cc: Scott Branden, Greg Kroah-Hartman, David Brown, Alexander Viro,
	Shuah Khan, bjorn.andersson, Shuah Khan, Arnd Bergmann,
	Rafael J . Wysocki, linux-kernel, linux-arm-msm, linux-fsdevel,
	BCM Kernel Feedback, Olof Johansson, Andrew Morton,
	Dan Carpenter, Colin Ian King, Kees Cook, Takashi Iwai,
	linux-kselftest, Andy Gross, linux-security-module,
	linux-integrity

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.
> > 
> > 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.

Mimi

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
  2020-05-13 22:12                   ` Mimi Zohar
@ 2020-05-13 22:48                     ` Scott Branden
  2020-05-13 23:00                       ` Mimi Zohar
  0 siblings, 1 reply; 14+ messages in thread
From: Scott Branden @ 2020-05-13 22:48 UTC (permalink / raw)
  To: Mimi Zohar, Luis Chamberlain
  Cc: Greg Kroah-Hartman, David Brown, Alexander Viro, Shuah Khan,
	bjorn.andersson, Shuah Khan, Arnd Bergmann, Rafael J . Wysocki,
	linux-kernel, linux-arm-msm, linux-fsdevel, BCM Kernel Feedback,
	Olof Johansson, Andrew Morton, Dan Carpenter, Colin Ian King,
	Kees Cook, Takashi Iwai, linux-kselftest, Andy Gross,
	linux-security-module, linux-integrity



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.

Is there some way we could add a flag when calling the 
request_firmware_into_buf to indicate it is ok that the data requested 
does not need to be measured?
> Mimi


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
  2020-05-13 22:48                     ` Scott Branden
@ 2020-05-13 23:00                       ` Mimi Zohar
  2020-05-13 23:34                         ` Kees Cook
  0 siblings, 1 reply; 14+ messages in thread
From: Mimi Zohar @ 2020-05-13 23:00 UTC (permalink / raw)
  To: Scott Branden, Luis Chamberlain
  Cc: Greg Kroah-Hartman, David Brown, Alexander Viro, Shuah Khan,
	bjorn.andersson, Shuah Khan, Arnd Bergmann, Rafael J . Wysocki,
	linux-kernel, linux-arm-msm, linux-fsdevel, BCM Kernel Feedback,
	Olof Johansson, Andrew Morton, Dan Carpenter, Colin Ian King,
	Kees Cook, Takashi Iwai, linux-kselftest, Andy Gross,
	linux-security-module, linux-integrity

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.

> 
> Is there some way we could add a flag when calling the 
> request_firmware_into_buf to indicate it is ok that the data requested 
> does not need to be measured?

The decision as to what needs to be measured is a policy decision left
up to the system owner, which they express by loading an IMA policy.

Mimi

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
  2020-05-13 23:00                       ` Mimi Zohar
@ 2020-05-13 23:34                         ` Kees Cook
  2020-05-13 23:58                           ` Mimi Zohar
  0 siblings, 1 reply; 14+ messages in thread
From: Kees Cook @ 2020-05-13 23:34 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: Scott Branden, Luis Chamberlain, Greg Kroah-Hartman, David Brown,
	Alexander Viro, Shuah Khan, bjorn.andersson, Shuah Khan,
	Arnd Bergmann, Rafael J . Wysocki, linux-kernel, linux-arm-msm,
	linux-fsdevel, BCM Kernel Feedback, Olof Johansson,
	Andrew Morton, Dan Carpenter, Colin Ian King, Takashi Iwai,
	linux-kselftest, Andy Gross, linux-security-module,
	linux-integrity

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

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v5 1/7] fs: introduce kernel_pread_file* support
  2020-05-13 23:34                         ` Kees Cook
@ 2020-05-13 23:58                           ` Mimi Zohar
  0 siblings, 0 replies; 14+ messages in thread
From: Mimi Zohar @ 2020-05-13 23:58 UTC (permalink / raw)
  To: Kees Cook
  Cc: Scott Branden, Luis Chamberlain, Greg Kroah-Hartman, David Brown,
	Alexander Viro, Shuah Khan, bjorn.andersson, Shuah Khan,
	Arnd Bergmann, Rafael J . Wysocki, linux-kernel, linux-arm-msm,
	linux-fsdevel, BCM Kernel Feedback, Olof Johansson,
	Andrew Morton, Dan Carpenter, Colin Ian King, Takashi Iwai,
	linux-kselftest, Andy Gross, linux-security-module,
	linux-integrity

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, back to index

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20200508002739.19360-1-scott.branden@broadcom.com>
     [not found] ` <20200508002739.19360-2-scott.branden@broadcom.com>
2020-05-13 18:39   ` [PATCH v5 1/7] fs: introduce kernel_pread_file* support Mimi Zohar
2020-05-13 18:53     ` Scott Branden
2020-05-13 18:57       ` Scott Branden
2020-05-13 19:03       ` Mimi Zohar
2020-05-13 19:18         ` Scott Branden
2020-05-13 19:39           ` Mimi Zohar
2020-05-13 19:41             ` Scott Branden
2020-05-13 21:20               ` Mimi Zohar
2020-05-13 21:28                 ` Luis Chamberlain
2020-05-13 22:12                   ` Mimi Zohar
2020-05-13 22:48                     ` Scott Branden
2020-05-13 23:00                       ` Mimi Zohar
2020-05-13 23:34                         ` Kees Cook
2020-05-13 23:58                           ` Mimi Zohar

Linux-Integrity Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-integrity/0 linux-integrity/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-integrity linux-integrity/ https://lore.kernel.org/linux-integrity \
		linux-integrity@vger.kernel.org
	public-inbox-index linux-integrity

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-integrity


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git