Linux-Integrity Archive on lore.kernel.org
 help / color / Atom feed
* Measure data again even when it has not changed
@ 2020-07-29 17:17 Lakshmi Ramasubramanian
  2020-07-30  3:23 ` Mimi Zohar
  0 siblings, 1 reply; 6+ messages in thread
From: Lakshmi Ramasubramanian @ 2020-07-29 17:17 UTC (permalink / raw)
  To: Mimi Zohar, linux-integrity; +Cc: Tyler Hicks

Hi Mimi,

I have a query related to measuring data (by IMA subsystem) when that 
data has been already been measured.

Consider the following sequence of events:

=> At time T0 IMA hook is called by another subsystem to measure data 
"foo". IMA measures it.

=> At time T1 data is "bar". IMA measures it.

=> At time T2 data is "foo" again. But IMA doesn't measure it since it 
is already in the measured list.

But for the subsystem making the call to IMA, the state has changed and 
"foo" has to be measured again.

One way to address the above is to use unique "event name" in each call 
so that IMA measures the given data every time.

Is there a better way to address the above?

thanks,
  -lakshmi


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

* Re: Measure data again even when it has not changed
  2020-07-29 17:17 Measure data again even when it has not changed Lakshmi Ramasubramanian
@ 2020-07-30  3:23 ` Mimi Zohar
  2020-07-30  3:41   ` Lakshmi Ramasubramanian
  0 siblings, 1 reply; 6+ messages in thread
From: Mimi Zohar @ 2020-07-30  3:23 UTC (permalink / raw)
  To: Lakshmi Ramasubramanian, linux-integrity; +Cc: Tyler Hicks

On Wed, 2020-07-29 at 10:17 -0700, Lakshmi Ramasubramanian wrote:
> Hi Mimi,
> 
> I have a query related to measuring data (by IMA subsystem) when that 
> data has been already been measured.
> 
> Consider the following sequence of events:
> 
> => At time T0 IMA hook is called by another subsystem to measure data 
> "foo". IMA measures it.
> 
> => At time T1 data is "bar". IMA measures it.
> 
> => At time T2 data is "foo" again. But IMA doesn't measure it since it 
> is already in the measured list.
> 
> But for the subsystem making the call to IMA, the state has changed and 
> "foo" has to be measured again.
> 
> One way to address the above is to use unique "event name" in each call 
> so that IMA measures the given data every time.
> 
> Is there a better way to address the above?

Most likely the file is being re-measured, but the new value already exists in
the hash table so it isn't being added to the IMA measurement list or extending
the TPM.  When IMA was upstreamed, there was concern about TPM performance and
the number of measurements being extended.  We've improved TPM performance quite
a bit.  If you're not concerned about TPM performance, I would define a new
template data field based on i_version.

Mimi





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

* Re: Measure data again even when it has not changed
  2020-07-30  3:23 ` Mimi Zohar
@ 2020-07-30  3:41   ` Lakshmi Ramasubramanian
  2020-07-30 12:05     ` Mimi Zohar
  0 siblings, 1 reply; 6+ messages in thread
From: Lakshmi Ramasubramanian @ 2020-07-30  3:41 UTC (permalink / raw)
  To: Mimi Zohar, linux-integrity; +Cc: Tyler Hicks

On 7/29/20 8:23 PM, Mimi Zohar wrote:

> On Wed, 2020-07-29 at 10:17 -0700, Lakshmi Ramasubramanian wrote:
>> Hi Mimi,
>>
>> I have a query related to measuring data (by IMA subsystem) when that
>> data has been already been measured.
>>
>> Consider the following sequence of events:
>>
>> => At time T0 IMA hook is called by another subsystem to measure data
>> "foo". IMA measures it.
>>
>> => At time T1 data is "bar". IMA measures it.
>>
>> => At time T2 data is "foo" again. But IMA doesn't measure it since it
>> is already in the measured list.
>>
>> But for the subsystem making the call to IMA, the state has changed and
>> "foo" has to be measured again.
>>
>> One way to address the above is to use unique "event name" in each call
>> so that IMA measures the given data every time.
>>
>> Is there a better way to address the above?
> 
> Most likely the file is being re-measured, but the new value already exists in
> the hash table so it isn't being added to the IMA measurement list or extending
> the TPM.  When IMA was upstreamed, there was concern about TPM performance and
> the number of measurements being extended.  We've improved TPM performance quite
> a bit.  If you're not concerned about TPM performance, I would define a new
> template data field based on i_version.

In the use case I am considering the entity being measured is not a 
file, but a memory buffer - it is for measuring an LSM's data 
constructs. So i_version is not available in this case.

When LSM's data changes from A to B and then back to A, hash(A) already 
exists in IMA's hash table. So A is not measured again.

Since LSM state change is not expected to be frequent, TPM performance 
shouldn't be a concern.

thanks,
  -lakshmi



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

* Re: Measure data again even when it has not changed
  2020-07-30  3:41   ` Lakshmi Ramasubramanian
@ 2020-07-30 12:05     ` Mimi Zohar
  2020-07-30 13:12       ` Lakshmi Ramasubramanian
  0 siblings, 1 reply; 6+ messages in thread
From: Mimi Zohar @ 2020-07-30 12:05 UTC (permalink / raw)
  To: Lakshmi Ramasubramanian, linux-integrity; +Cc: Tyler Hicks

On Wed, 2020-07-29 at 20:41 -0700, Lakshmi Ramasubramanian wrote:
> On 7/29/20 8:23 PM, Mimi Zohar wrote:
> 
> > On Wed, 2020-07-29 at 10:17 -0700, Lakshmi Ramasubramanian wrote:
> >> Hi Mimi,
> >>
> >> I have a query related to measuring data (by IMA subsystem) when that
> >> data has been already been measured.
> >>
> >> Consider the following sequence of events:
> >>
> >> => At time T0 IMA hook is called by another subsystem to measure data
> >> "foo". IMA measures it.
> >>
> >> => At time T1 data is "bar". IMA measures it.
> >>
> >> => At time T2 data is "foo" again. But IMA doesn't measure it since it
> >> is already in the measured list.
> >>
> >> But for the subsystem making the call to IMA, the state has changed and
> >> "foo" has to be measured again.
> >>
> >> One way to address the above is to use unique "event name" in each call
> >> so that IMA measures the given data every time.
> >>
> >> Is there a better way to address the above?
> > 
> > Most likely the file is being re-measured, but the new value already exists in
> > the hash table so it isn't being added to the IMA measurement list or extending
> > the TPM.  When IMA was upstreamed, there was concern about TPM performance and
> > the number of measurements being extended.  We've improved TPM performance quite
> > a bit.  If you're not concerned about TPM performance, I would define a new
> > template data field based on i_version.
> 
> In the use case I am considering the entity being measured is not a 
> file, but a memory buffer - it is for measuring an LSM's data 
> constructs. So i_version is not available in this case.
> 
> When LSM's data changes from A to B and then back to A, hash(A) already 
> exists in IMA's hash table. So A is not measured again.
> 
> Since LSM state change is not expected to be frequent, TPM performance 
> shouldn't be a concern.

Wouldn't a unique event name result in a new measurement every time?

Mimi

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

* Re: Measure data again even when it has not changed
  2020-07-30 12:05     ` Mimi Zohar
@ 2020-07-30 13:12       ` Lakshmi Ramasubramanian
  2020-07-30 14:05         ` Stephen Smalley
  0 siblings, 1 reply; 6+ messages in thread
From: Lakshmi Ramasubramanian @ 2020-07-30 13:12 UTC (permalink / raw)
  To: Mimi Zohar, linux-integrity, Stephen Smalley; +Cc: Tyler Hicks

On 7/30/20 5:05 AM, Mimi Zohar wrote:
> On Wed, 2020-07-29 at 20:41 -0700, Lakshmi Ramasubramanian wrote:
>> On 7/29/20 8:23 PM, Mimi Zohar wrote:
>>
>>> On Wed, 2020-07-29 at 10:17 -0700, Lakshmi Ramasubramanian wrote:
>>>> Hi Mimi,
>>>>
>>>> I have a query related to measuring data (by IMA subsystem) when that
>>>> data has been already been measured.
>>>>
>>>> Consider the following sequence of events:
>>>>
>>>> => At time T0 IMA hook is called by another subsystem to measure data
>>>> "foo". IMA measures it.
>>>>
>>>> => At time T1 data is "bar". IMA measures it.
>>>>
>>>> => At time T2 data is "foo" again. But IMA doesn't measure it since it
>>>> is already in the measured list.
>>>>
>>>> But for the subsystem making the call to IMA, the state has changed and
>>>> "foo" has to be measured again.
>>>>
>>>> One way to address the above is to use unique "event name" in each call
>>>> so that IMA measures the given data every time.
>>>>
>>>> Is there a better way to address the above?
>>>
>>> Most likely the file is being re-measured, but the new value already exists in
>>> the hash table so it isn't being added to the IMA measurement list or extending
>>> the TPM.  When IMA was upstreamed, there was concern about TPM performance and
>>> the number of measurements being extended.  We've improved TPM performance quite
>>> a bit.  If you're not concerned about TPM performance, I would define a new
>>> template data field based on i_version.
>>
>> In the use case I am considering the entity being measured is not a
>> file, but a memory buffer - it is for measuring an LSM's data
>> constructs. So i_version is not available in this case.
>>
>> When LSM's data changes from A to B and then back to A, hash(A) already
>> exists in IMA's hash table. So A is not measured again.
>>
>> Since LSM state change is not expected to be frequent, TPM performance
>> shouldn't be a concern.
> 
> Wouldn't a unique event name result in a new measurement every time?
> 

Adding Stephen.

Yes - but the LSM would call the IMA hook only when there is a change in 
the state.

I have posted a patch set for this last night -
it defines IMA hooks for measuring LSM data and uses that to measure 
SELinux data constructs. It can be used by other security modules as 
well. Please take a look.

thanks,
  -lakshmi





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

* Re: Measure data again even when it has not changed
  2020-07-30 13:12       ` Lakshmi Ramasubramanian
@ 2020-07-30 14:05         ` Stephen Smalley
  0 siblings, 0 replies; 6+ messages in thread
From: Stephen Smalley @ 2020-07-30 14:05 UTC (permalink / raw)
  To: Lakshmi Ramasubramanian; +Cc: Mimi Zohar, linux-integrity, Tyler Hicks

On Thu, Jul 30, 2020 at 9:12 AM Lakshmi Ramasubramanian
<nramas@linux.microsoft.com> wrote:
>
> On 7/30/20 5:05 AM, Mimi Zohar wrote:
> > On Wed, 2020-07-29 at 20:41 -0700, Lakshmi Ramasubramanian wrote:
> >> On 7/29/20 8:23 PM, Mimi Zohar wrote:
> >>
> >>> On Wed, 2020-07-29 at 10:17 -0700, Lakshmi Ramasubramanian wrote:
> >>>> Hi Mimi,
> >>>>
> >>>> I have a query related to measuring data (by IMA subsystem) when that
> >>>> data has been already been measured.
> >>>>
> >>>> Consider the following sequence of events:
> >>>>
> >>>> => At time T0 IMA hook is called by another subsystem to measure data
> >>>> "foo". IMA measures it.
> >>>>
> >>>> => At time T1 data is "bar". IMA measures it.
> >>>>
> >>>> => At time T2 data is "foo" again. But IMA doesn't measure it since it
> >>>> is already in the measured list.
> >>>>
> >>>> But for the subsystem making the call to IMA, the state has changed and
> >>>> "foo" has to be measured again.
> >>>>
> >>>> One way to address the above is to use unique "event name" in each call
> >>>> so that IMA measures the given data every time.
> >>>>
> >>>> Is there a better way to address the above?
> >>>
> >>> Most likely the file is being re-measured, but the new value already exists in
> >>> the hash table so it isn't being added to the IMA measurement list or extending
> >>> the TPM.  When IMA was upstreamed, there was concern about TPM performance and
> >>> the number of measurements being extended.  We've improved TPM performance quite
> >>> a bit.  If you're not concerned about TPM performance, I would define a new
> >>> template data field based on i_version.
> >>
> >> In the use case I am considering the entity being measured is not a
> >> file, but a memory buffer - it is for measuring an LSM's data
> >> constructs. So i_version is not available in this case.
> >>
> >> When LSM's data changes from A to B and then back to A, hash(A) already
> >> exists in IMA's hash table. So A is not measured again.
> >>
> >> Since LSM state change is not expected to be frequent, TPM performance
> >> shouldn't be a concern.
> >
> > Wouldn't a unique event name result in a new measurement every time?
> >
>
> Adding Stephen.
>
> Yes - but the LSM would call the IMA hook only when there is a change in
> the state.
>
> I have posted a patch set for this last night -
> it defines IMA hooks for measuring LSM data and uses that to measure
> SELinux data constructs. It can be used by other security modules as
> well. Please take a look.

To provide more context, the patch set is enabling the measurement of
LSM state variables (e.g. SELinux enabled and enforcing among others)
and LSM policy (e.g. the SELinux policy).  An appraiser may want to
know either or both of:
1) What is the current state/policy of the system, e.g. is it
currently enforcing an expected policy?
2) Has the system ever been in a state/policy that was
unexpected/unauthorized, e.g. was it switched to permissive mode at
some point earlier or did it load an unexpected/unauthorized policy
earlier?

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

end of thread, back to index

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-29 17:17 Measure data again even when it has not changed Lakshmi Ramasubramanian
2020-07-30  3:23 ` Mimi Zohar
2020-07-30  3:41   ` Lakshmi Ramasubramanian
2020-07-30 12:05     ` Mimi Zohar
2020-07-30 13:12       ` Lakshmi Ramasubramanian
2020-07-30 14:05         ` Stephen Smalley

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