Writing out EVM protected xattrs while EVM is active

Writing out EVM protected xattrs while EVM is active

[Matthew Garrett]

I'm interested in extending our use of IMA digital signatures to EVM
in order to protect security.capability (and, in the near future,
security.apparmor). However, right now this doesn't seem to quite work
in terms of allowing updates to a running system. We've discussed the
EVM siganture format's use of inode numbers and I think I've got that
sorted (I'll send a patch once I've got a last couple of things
working).

However, I'm a little confused by how EVM should be working here. Once
EVM is initialised, all EVM attributes will be protected, making it
impossible to write new values to any xattrs covered by EVM unless
IMA_NEW_FILE is set. But as far as I can tell, IMA_NEW_FILE will only
be set if there's an IMA action that covers the file in question. This
means it's possible to write out security.evm and friends on newly
created files that would be appraised, but not on any other files. Am
I missing something?

Re: Writing out EVM protected xattrs while EVM is active

[Mimi Zohar]

On Tue, 2017-10-17 at 16:12 -0700, Matthew Garrett wrote:
> I'm interested in extending our use of IMA digital signatures to EVM
> in order to protect security.capability (and, in the near future,
> security.apparmor). 

security.capability is already included in the EVM HMAC/signature.
Your security.apparmor patch is now queued in my #next branch. 

> However, right now this doesn't seem to quite work
> in terms of allowing updates to a running system.

?

> We've discussed the
> EVM siganture format's use of inode numbers and I think I've got that
> sorted (I'll send a patch once I've got a last couple of things
> working).

Ok

> 
> However, I'm a little confused by how EVM should be working here. Once
> EVM is initialised, all EVM attributes will be protected, making it
> impossible to write new values to any xattrs covered by EVM unless
> IMA_NEW_FILE is set.

Up to now, security.evm has been to detect off line changes, not to
prevent the running system's file meta-data from changing.  Before the
security.evm HMAC can be updated, the existing value must be verified.
 Otherwise any file metadata change would cause security.evm to be
updated, including any off line modifications.

Updating the security.evm HMAC is triggered by writing/updating the
file's metadata (eg. setattr, setxattr, removexattr).

> But as far as I can tell, IMA_NEW_FILE will only
> be set if there's an IMA action that covers the file in question. This
> means it's possible to write out security.evm and friends on newly
> created files that would be appraised, but not on any other files. Am
> I missing something?

Only files in the IMA policy that pass integrity verification can be
accessed.  The IMA_NEW_FILE flag overides this restriction, allowing
IMA to access new files, even if the security.ima xattr does not yet
exist.

Mimi

Re: Writing out EVM protected xattrs while EVM is active

[Matthew Garrett]

On Tue, Oct 17, 2017 at 6:49 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Tue, 2017-10-17 at 16:12 -0700, Matthew Garrett wrote:
>> I'm interested in extending our use of IMA digital signatures to EVM
>> in order to protect security.capability (and, in the near future,
>> security.apparmor).
>
> security.capability is already included in the EVM HMAC/signature.
> Your security.apparmor patch is now queued in my #next branch.

Ah, sorry, by "our" I meant "my specific use case", not upstream :)

>> But as far as I can tell, IMA_NEW_FILE will only
>> be set if there's an IMA action that covers the file in question. This
>> means it's possible to write out security.evm and friends on newly
>> created files that would be appraised, but not on any other files. Am
>> I missing something?
>
> Only files in the IMA policy that pass integrity verification can be
> accessed.  The IMA_NEW_FILE flag overides this restriction, allowing
> IMA to access new files, even if the security.ima xattr does not yet
> exist.

Is this accurate? If there's no IMA policy that covers the file in
question (eg, appraise is limited to a specific security context or
owner), will IMA_NEW ever be set? It looks like that codepath will
only be entered if there's a rule that matches. The EVM xattr
protections appear to be called regardless, which means that there's
then no way to write out attributes on them at runtime.

Re: Writing out EVM protected xattrs while EVM is active

[Mimi Zohar]

On Tue, 2017-10-17 at 19:02 -0700, Matthew Garrett wrote:

> Is this accurate? If there's no IMA policy that covers the file in
> question (eg, appraise is limited to a specific security context or
> owner), will IMA_NEW ever be set? It looks like that codepath will
> only be entered if there's a rule that matches. The EVM xattr
> protections appear to be called regardless, which means that there's
> then no way to write out attributes on them at runtime.

Updating/writing security.evm is triggered by writing or updating ANY
file metadata included in the HMAC calculation.  There is no
requirement for security.ima to exist.

Mimi

Re: Writing out EVM protected xattrs while EVM is active

[Matthew Garrett]

On Tue, Oct 17, 2017 at 7:08 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Tue, 2017-10-17 at 19:02 -0700, Matthew Garrett wrote:
>
>> Is this accurate? If there's no IMA policy that covers the file in
>> question (eg, appraise is limited to a specific security context or
>> owner), will IMA_NEW ever be set? It looks like that codepath will
>> only be entered if there's a rule that matches. The EVM xattr
>> protections appear to be called regardless, which means that there's
>> then no way to write out attributes on them at runtime.
>
> Updating/writing security.evm is triggered by writing or updating ANY
> file metadata included in the HMAC calculation.  There is no
> requirement for security.ima to exist.

In this case there's no symmetric key loaded, so security.evm won't be
updated. Here's what's happening:

1) Configure an IMA policy that only appraises a subset of files
2) Create a new file that does not match the appraisal rule.
IMA_NEW_FILE isn't set because no rule matched.
3) Attempt to write security.ima, security.capability and security.evm
on the new file. EVM blocks this because IMA_NEW_FILE isn't set.

I may be misdiagnosing this, but as far as I can tell IMA_NEW_FILE is
only set in ima_appraise_measurement() if action is set to something,
and if ima_match_rules() doesn't match then this will never be the
case?

Re: Writing out EVM protected xattrs while EVM is active

[Mimi Zohar]

On Tue, 2017-10-17 at 19:13 -0700, Matthew Garrett wrote:
> On Tue, Oct 17, 2017 at 7:08 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Tue, 2017-10-17 at 19:02 -0700, Matthew Garrett wrote:
> >
> >> Is this accurate? If there's no IMA policy that covers the file in
> >> question (eg, appraise is limited to a specific security context or
> >> owner), will IMA_NEW ever be set? It looks like that codepath will
> >> only be entered if there's a rule that matches. The EVM xattr
> >> protections appear to be called regardless, which means that there's
> >> then no way to write out attributes on them at runtime.
> >
> > Updating/writing security.evm is triggered by writing or updating ANY
> > file metadata included in the HMAC calculation.  There is no
> > requirement for security.ima to exist.
> 
> In this case there's no symmetric key loaded, so security.evm won't be
> updated. Here's what's happening:
> 
> 1) Configure an IMA policy that only appraises a subset of files
> 2) Create a new file that does not match the appraisal rule.
> IMA_NEW_FILE isn't set because no rule matched.
> 3) Attempt to write security.ima, security.capability and security.evm
> on the new file. EVM blocks this because IMA_NEW_FILE isn't set. 

Are you writing these xattrs before or after you closed the file?
 Once the file is closed, even if the IMA_NEW_FILE flag had been set,
it would be removed.

This normally works because the file would have been hashed and
written out as security.ima, causing security.evm to be written out as
well.

> I may be misdiagnosing this, but as far as I can tell IMA_NEW_FILE is
> only set in ima_appraise_measurement() if action is set to something,
> and if ima_match_rules() doesn't match then this will never be the
> case?

True, but having IMA_NEW_FILE set would only help with writing the
first xattr, not subsequent ones.

Re: Writing out EVM protected xattrs while EVM is active

[Matthew Garrett]

On Tue, Oct 17, 2017 at 7:53 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Tue, 2017-10-17 at 19:13 -0700, Matthew Garrett wrote:
>> On Tue, Oct 17, 2017 at 7:08 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
>> In this case there's no symmetric key loaded, so security.evm won't be
>> updated. Here's what's happening:
>>
>> 1) Configure an IMA policy that only appraises a subset of files
>> 2) Create a new file that does not match the appraisal rule.
>> IMA_NEW_FILE isn't set because no rule matched.
>> 3) Attempt to write security.ima, security.capability and security.evm
>> on the new file. EVM blocks this because IMA_NEW_FILE isn't set.
>
> Are you writing these xattrs before or after you closed the file?
>  Once the file is closed, even if the IMA_NEW_FILE flag had been set,
> it would be removed.

Yes, I've fixed up my implementation to make the calls while the file
is still open.

>> I may be misdiagnosing this, but as far as I can tell IMA_NEW_FILE is
>> only set in ima_appraise_measurement() if action is set to something,
>> and if ima_match_rules() doesn't match then this will never be the
>> case?
>
> True, but having IMA_NEW_FILE set would only help with writing the
> first xattr, not subsequent ones.

Ok. I'm not sure this is easily fixable to handle my use-case without
breaking assumptions made in yours, so I'm wondering if a different
approach would be better here. For us, there's no problem with
updating any of the EVM-protected xattrs at runtime as long as doing
so invalidates the iint cache entry (hmm, does setting an xattr bump
the iversion? If so, we already get this behaviour). How would you
feel about a runtime controllable flag that enabled this, possibly
tied into the /sys/kernel/security/evm write? We'd end up with:

1: Enable HMAC
2: Enable RSA
4: Permit extended attribute writes

Existing behaviour would be preserved since 1 would lock down the
interface, and we could reject cases where 1 and 4 are set
simultaneously.

Re: Writing out EVM protected xattrs while EVM is active

[Mimi Zohar]

> >> I may be misdiagnosing this, but as far as I can tell IMA_NEW_FILE is
> >> only set in ima_appraise_measurement() if action is set to something,
> >> and if ima_match_rules() doesn't match then this will never be the
> >> case?
> >
> > True, but having IMA_NEW_FILE set would only help with writing the
> > first xattr, not subsequent ones.
> 
> Ok. I'm not sure this is easily fixable to handle my use-case without
> breaking assumptions made in yours, so I'm wondering if a different
> approach would be better here. For us, there's no problem with
> updating any of the EVM-protected xattrs at runtime as long as doing
> so invalidates the iint cache entry (hmm, does setting an xattr bump
> the iversion? If so, we already get this behaviour). How would you
> feel about a runtime controllable flag that enabled this, possibly
> tied into the /sys/kernel/security/evm write? We'd end up with:
> 
> 1: Enable HMAC
> 2: Enable RSA
> 4: Permit extended attribute writes
> 
> Existing behaviour would be preserved since 1 would lock down the
> interface, and we could reject cases where 1 and 4 are set
> simultaneously.

Here's an alternative, though admittedly one that is more difficult to
implement and dependent on having a portable EVM signature type.

Define the equivalent of listxattr that allows writing multiple
xattrs.  Change option 4 above to "Permit writing a group of extended
attributes, including an EVM signature, when none currently exist."

Then option 1 and 4 won't need to be mutually exclusive.

Mimi

Re: Writing out EVM protected xattrs while EVM is active

[Matthew Garrett]

On Wed, Oct 18, 2017 at 10:51 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
>> Ok. I'm not sure this is easily fixable to handle my use-case without
>> breaking assumptions made in yours, so I'm wondering if a different
>> approach would be better here. For us, there's no problem with
>> updating any of the EVM-protected xattrs at runtime as long as doing
>> so invalidates the iint cache entry (hmm, does setting an xattr bump
>> the iversion? If so, we already get this behaviour). How would you
>> feel about a runtime controllable flag that enabled this, possibly
>> tied into the /sys/kernel/security/evm write? We'd end up with:
>>
>> 1: Enable HMAC
>> 2: Enable RSA
>> 4: Permit extended attribute writes
>>
>> Existing behaviour would be preserved since 1 would lock down the
>> interface, and we could reject cases where 1 and 4 are set
>> simultaneously.
>
> Here's an alternative, though admittedly one that is more difficult to
> implement and dependent on having a portable EVM signature type.
>
> Define the equivalent of listxattr that allows writing multiple
> xattrs.  Change option 4 above to "Permit writing a group of extended
> attributes, including an EVM signature, when none currently exist."

This would require adding a new syscall (including glibc support), and
I think that's probably a hard sell for a single usecase. Looking at
the code a bit more, are you sure about this? I thought IMA_NEW_FILE
would only be cleared once the last writer closes the fd, so it ought
to be possible to do multiple fsetxattr()s with the same file
descriptor until the last writer closes it?

Re: Writing out EVM protected xattrs while EVM is active

[Matthew Garrett]

On Wed, Oct 18, 2017 at 11:16 AM, Dmitry Kasatkin
<dmitry.kasatkin@gmail.com> wrote:
> Hi,
>
> I have not read thread in detail so sorry if I will repeat something.
>
> EVM support signatures.
> https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git/tree/security/integrity/evm/evm_main.c?h=next#n166
>
> They can be mutable or immutable if I not is marked immutables
> Mutable signature will be replaced on the first verification.
>
> And ima-evm-utils has support to generate evm signatures
>
> https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/master/tree/src/evmctl.c#l1549
>
> Also there is concept of EVM signatures not bound to inode unique data like
> ino and generation

That's fine - the problem is how to write these out. If EVM is enabled
there's no way to write security.evm on a new file unless the iint
entry has an IMA_NEW_FILE flag, and this will only be set if there's
an IMA policy that covers that file.

Re: Writing out EVM protected xattrs while EVM is active

[Dmitry Kasatkin]

Hi,

(previous email was sent by mistake incompleted)

I have not read thread in detail so sorry if I will repeat something.

EVM support signatures.
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git/tree/security/integrity/evm/evm_main.c?h=next#n166

They can be mutable or immutable if I not is marked immutables
Mutable signature will be replaced on the first verification.

And ima-evm-utils has support to generate evm signatures

https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/master/tree/src/evmctl.c#l1549

Also there is concept of EVM signatures not bound to inode unique data
like ino and generation..

Also there are patches I made 2 years ago

2015-10-22  ima: limit capabilities for unsigned executable
2015-10-22  evm: load EVM key from the kernel
2015-10-22  evm: require EVM signature based appraisal
2015-10-22  ima: provide appraise_type=evmsig
2015-10-22  evm: provide immutable EVM signature

They are on the top here

https://git.kernel.org/pub/scm/linux/kernel/git/kasatkin/linux-digsig.git/log/?h=evm-next

Have you seen it?

Dmitry

On Wed, Oct 18, 2017 at 9:16 PM, Dmitry Kasatkin
<dmitry.kasatkin@gmail.com> wrote:
> Hi,
>
> I have not read thread in detail so sorry if I will repeat something.
>
> EVM support signatures.
> https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git/tree/security/integrity/evm/evm_main.c?h=next#n166
>
> They can be mutable or immutable if I not is marked immutables
> Mutable signature will be replaced on the first verification.
>
> And ima-evm-utils has support to generate evm signatures
>
> https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/master/tree/src/evmctl.c#l1549
>
> Also there is concept of EVM signatures not bound to inode unique data like
> ino and generation
>
>
> On Wed, Oct 18, 2017 at 8:51 PM, Mimi Zohar <zohar@linux.vnet.ibm.com>
> wrote:
>>
>> > >> I may be misdiagnosing this, but as far as I can tell IMA_NEW_FILE is
>> > >> only set in ima_appraise_measurement() if action is set to something,
>> > >> and if ima_match_rules() doesn't match then this will never be the
>> > >> case?
>> > >
>> > > True, but having IMA_NEW_FILE set would only help with writing the
>> > > first xattr, not subsequent ones.
>> >
>> > Ok. I'm not sure this is easily fixable to handle my use-case without
>> > breaking assumptions made in yours, so I'm wondering if a different
>> > approach would be better here. For us, there's no problem with
>> > updating any of the EVM-protected xattrs at runtime as long as doing
>> > so invalidates the iint cache entry (hmm, does setting an xattr bump
>> > the iversion? If so, we already get this behaviour). How would you
>> > feel about a runtime controllable flag that enabled this, possibly
>> > tied into the /sys/kernel/security/evm write? We'd end up with:
>> >
>> > 1: Enable HMAC
>> > 2: Enable RSA
>> > 4: Permit extended attribute writes
>> >
>> > Existing behaviour would be preserved since 1 would lock down the
>> > interface, and we could reject cases where 1 and 4 are set
>> > simultaneously.
>>
>> Here's an alternative, though admittedly one that is more difficult to
>> implement and dependent on having a portable EVM signature type.
>>
>> Define the equivalent of listxattr that allows writing multiple
>> xattrs.  Change option 4 above to "Permit writing a group of extended
>> attributes, including an EVM signature, when none currently exist."
>>
>> Then option 1 and 4 won't need to be mutually exclusive.
>>
>> Mimi
>>
>
>
>
> --
> Thanks,
> Dmitry



-- 
Thanks,
Dmitry

Re: Writing out EVM protected xattrs while EVM is active

[Mimi Zohar]

On Wed, 2017-10-18 at 11:08 -0700, Matthew Garrett wrote:
> On Wed, Oct 18, 2017 at 10:51 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> >> Ok. I'm not sure this is easily fixable to handle my use-case without
> >> breaking assumptions made in yours, so I'm wondering if a different
> >> approach would be better here. For us, there's no problem with
> >> updating any of the EVM-protected xattrs at runtime as long as doing
> >> so invalidates the iint cache entry (hmm, does setting an xattr bump
> >> the iversion? If so, we already get this behaviour). How would you
> >> feel about a runtime controllable flag that enabled this, possibly
> >> tied into the /sys/kernel/security/evm write? We'd end up with:
> >>
> >> 1: Enable HMAC
> >> 2: Enable RSA
> >> 4: Permit extended attribute writes
> >>
> >> Existing behaviour would be preserved since 1 would lock down the
> >> interface, and we could reject cases where 1 and 4 are set
> >> simultaneously.
> >
> > Here's an alternative, though admittedly one that is more difficult to
> > implement and dependent on having a portable EVM signature type.
> >
> > Define the equivalent of listxattr that allows writing multiple
> > xattrs.  Change option 4 above to "Permit writing a group of extended
> > attributes, including an EVM signature, when none currently exist."
> 
> This would require adding a new syscall (including glibc support), and
> I think that's probably a hard sell for a single usecase. Looking at
> the code a bit more, are you sure about this? I thought IMA_NEW_FILE
> would only be cleared once the last writer closes the fd, so it ought
> to be possible to do multiple fsetxattr()s with the same file
> descriptor until the last writer closes it?

The IMA_NEW_FILE check is applicable only when there are no security
xattrs (INTEGRITY_NOXATTRS), which would not be the case after writing
the first security xattr.  The return result in that case is
INTEGRITY_NOLABEL, meaning no security.evm.
 
Mimi

Re: Writing out EVM protected xattrs while EVM is active

[Matthew Garrett]

On Wed, Oct 18, 2017 at 11:19 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> The IMA_NEW_FILE check is applicable only when there are no security
> xattrs (INTEGRITY_NOXATTRS), which would not be the case after writing
> the first security xattr.  The return result in that case is
> INTEGRITY_NOLABEL, meaning no security.evm.

Ah, of course. Ok, how about going with my proposal with an intention
to relax the restriction around it and HMAC support once we have a
mechanism for setting multiple xattrs at once?

Re: Writing out EVM protected xattrs while EVM is active

[Mimi Zohar]

On Wed, 2017-10-18 at 11:23 -0700, Matthew Garrett wrote:
> On Wed, Oct 18, 2017 at 11:19 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > The IMA_NEW_FILE check is applicable only when there are no security
> > xattrs (INTEGRITY_NOXATTRS), which would not be the case after writing
> > the first security xattr.  The return result in that case is
> > INTEGRITY_NOLABEL, meaning no security.evm.
> 
> Ah, of course. Ok, how about going with my proposal with an intention
> to relax the restriction around it and HMAC support once we have a
> mechanism for setting multiple xattrs at once?

Sure.  We really need some way of keeping track of things needing to
be done.  And of course, putting a name with it.

[I'm still hoping someone will add the CPIO xattr support.  Any
takers?  It's really a self contained project, lots of impact.  A
really small, minor problem is reading and understanding the
undocumented state table in order to make the change.]

I assume you received, earlier today, the linux-next documentation
conflict and resolution from Mark Brown.  Hopefully, he'll be willing
to carry this change as well.

Mimi

Re: Writing out EVM protected xattrs while EVM is active

[Dmitry Kasatkin]

On Wed, Oct 18, 2017 at 2:12 AM, Matthew Garrett <mjg59@google.com> wrote:
> I'm interested in extending our use of IMA digital signatures to EVM
> in order to protect security.capability (and, in the near future,
> security.apparmor). However, right now this doesn't seem to quite work
> in terms of allowing updates to a running system. We've discussed the
> EVM siganture format's use of inode numbers and I think I've got that
> sorted (I'll send a patch once I've got a last couple of things
> working).
>
> However, I'm a little confused by how EVM should be working here. Once
> EVM is initialised, all EVM attributes will be protected, making it
> impossible to write new values to any xattrs covered by EVM unless
> IMA_NEW_FILE is set.


Sorry, why it is not possible to set xattrs?
system can change xattrs and hmac will be recalculated...


> But as far as I can tell, IMA_NEW_FILE will only
> be set if there's an IMA action that covers the file in question. This
> means it's possible to write out security.evm and friends on newly
> created files that would be appraised, but not on any other files. Am
> I missing something?



-- 
Thanks,
Dmitry

Re: Writing out EVM protected xattrs while EVM is active

[Dmitry Kasatkin]

On Wed, Oct 18, 2017 at 9:18 PM, Matthew Garrett <mjg59@google.com> wrote:
> On Wed, Oct 18, 2017 at 11:16 AM, Dmitry Kasatkin
> <dmitry.kasatkin@gmail.com> wrote:
>> Hi,
>>
>> I have not read thread in detail so sorry if I will repeat something.
>>
>> EVM support signatures.
>> https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git/tree/security/integrity/evm/evm_main.c?h=next#n166
>>
>> They can be mutable or immutable if I not is marked immutables
>> Mutable signature will be replaced on the first verification.
>>
>> And ima-evm-utils has support to generate evm signatures
>>
>> https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/master/tree/src/evmctl.c#l1549
>>
>> Also there is concept of EVM signatures not bound to inode unique data like
>> ino and generation
>
> That's fine - the problem is how to write these out. If EVM is enabled
> there's no way to write security.evm on a new file unless the iint
> entry has an IMA_NEW_FILE flag, and this will only be set if there's
> an IMA policy that covers that file.

Why??

It is possible to set digital signature..

int evm_inode_setxattr(struct dentry *dentry, const char *xattr_name,
       const void *xattr_value, size_t xattr_value_len)
{
         const struct evm_ima_xattr_data *xattr_data = xattr_value;

            if (strcmp(xattr_name, XATTR_NAME_EVM) == 0) {
                  if (!xattr_value_len)
                          return -EINVAL;
                  if (xattr_data->type != EVM_IMA_XATTR_DIGSIG)
                        return -EPERM;
               }
            return evm_protect_xattr(dentry, xattr_name, xattr_value,
xattr_value_len);
}



-- 
Thanks,
Dmitry

Re: Writing out EVM protected xattrs while EVM is active

[Matthew Garrett]

On Thu, Oct 19, 2017 at 4:00 AM, Dmitry Kasatkin
<dmitry.kasatkin@gmail.com> wrote:
> On Wed, Oct 18, 2017 at 2:12 AM, Matthew Garrett <mjg59@google.com> wrote:
>> I'm interested in extending our use of IMA digital signatures to EVM
>> in order to protect security.capability (and, in the near future,
>> security.apparmor). However, right now this doesn't seem to quite work
>> in terms of allowing updates to a running system. We've discussed the
>> EVM siganture format's use of inode numbers and I think I've got that
>> sorted (I'll send a patch once I've got a last couple of things
>> working).
>>
>> However, I'm a little confused by how EVM should be working here. Once
>> EVM is initialised, all EVM attributes will be protected, making it
>> impossible to write new values to any xattrs covered by EVM unless
>> IMA_NEW_FILE is set.
>
>
> Sorry, why it is not possible to set xattrs?
> system can change xattrs and hmac will be recalculated...

Because there's no symmetric key loaded in this case.