linux-ima-user — Q&A for users of IMA

Re: [Linux-ima-user] IMA overwrites xattr even if it has got correct signature

[Dmitry R. <dmi...@li...>]

On Fri, 2016-02-26 at 06:48 -0500, Mimi Zohar wrote:
> On Fri, 2016-02-26 at 08:52 +0100, Patrick Ohly wrote:
> > On Thu, 2016-02-25 at 11:09 -0500, Mimi Zohar wrote:
> > > On Thu, 2016-02-25 at 15:29 +0200, Dmitry Rozhkov wrote:
> > > > On Thu, 2016-02-25 at 07:43 -0500, Mimi Zohar wrote:
> > > 
> > > > > 
> > > > > If security.ima isn't being written because the file is not
> > > > > in policy,
> > > > > that is a different problem.   Perhaps try writing a file
> > > > > that is in the
> > > > > IMA-appraisal policy.
> > > > 
> > > > Didn't get it. The file is in the IMA-appraisal policy.
> > > > 
> > > > AFAIU upon file closing ima_inode_setxattr()
> > > > calls ima_reset_appraise_flags() where IMA_DIGSIG is supposed
> > > > to be
> > > > set. But right before setting the flag there's the condition
> > > > 
> > > > 	iint = integrity_iint_find(inode);
> > > > 	if (!iint)
> > > > 		return;
> > > > 
> > > > which is true for newly created (and never closed yet) files.
> > > 
> > > There needs to be a FILE_CHECK rule for the iint to be created
> > > for a new
> > > file.
> > 
> > The policy is essentially just:
> > 
> > appraise fowner=0
> > measure fowner=0
> > 
> > with some dont_appraise/measure entries earlier for some special
> > filesystems.
> 
> This policy measures and appraises everything owned by root.  So as
> long
> as the file is owned by root, the file will be in the file open
> (FILE_CHECK) policy.
> 

In other words with the policy like

appraise fowner=0
measure fowner=0 

the FILE_CHECK rule is implied for all files and iint is guarantied to
be created. Then something else is missing for IMA_DIGSIG to be set. I
run out of ideas on what it could be.

BR,
Dima

Re: [Linux-ima-user] IMA overwrites xattr even if it has got correct signature

[Mimi Z. <zo...@li...>]

On Fri, 2016-02-26 at 08:52 +0100, Patrick Ohly wrote:
> On Thu, 2016-02-25 at 11:09 -0500, Mimi Zohar wrote:
> > On Thu, 2016-02-25 at 15:29 +0200, Dmitry Rozhkov wrote:
> > > On Thu, 2016-02-25 at 07:43 -0500, Mimi Zohar wrote:
> > 
> > > > 
> > > > If security.ima isn't being written because the file is not in policy,
> > > > that is a different problem.   Perhaps try writing a file that is in the
> > > > IMA-appraisal policy.
> > > 
> > > Didn't get it. The file is in the IMA-appraisal policy.
> > > 
> > > AFAIU upon file closing ima_inode_setxattr()
> > > calls ima_reset_appraise_flags() where IMA_DIGSIG is supposed to be
> > > set. But right before setting the flag there's the condition
> > > 
> > > 	iint = integrity_iint_find(inode);
> > > 	if (!iint)
> > > 		return;
> > > 
> > > which is true for newly created (and never closed yet) files.
> > 
> > There needs to be a FILE_CHECK rule for the iint to be created for a new
> > file.
> 
> The policy is essentially just:
> 
> appraise fowner=0
> measure fowner=0
> 
> with some dont_appraise/measure entries earlier for some special
> filesystems.

This policy measures and appraises everything owned by root.  So as long
as the file is owned by root, the file will be in the file open
(FILE_CHECK) policy.

> How does this have to be extended to have a "FILE_CHECK rule"?

The FILE_CHECK rule would be needed if, for example, you wanted to
appraise all executables, not only those executed by root.   So you add
func=BPRM_CHECK rules.  In that case, the files not owned by root would
not be included in the file open policy. The problem is in identifying
just those files being executed and nothing else to include in the
FILE_CHECK rule.

> My understanding was that adding a "func" attribute just further limits
> the scope of a rule. But to be honest, the exact meaning of the various
> keywords remain a black art to me. I'm aware of the syntax definition in
> the kernel doc, but that document does not explain the semantic.

When we first started working on IMA, there was the classic debate of
safety over performance.  In this case, the debate was over how much or
how little to measure and appraise.   The thinking was the more you
measured and appraised the safer the system would be, but performance
would be impacted.  So, the ima_tcb/ima_appraise_tcb, that we have
today, attempts to include all files in the tcb.  It is a compromise
between measuring and appraising too much or too little.

Work still needs to be done on defining measurement and appraisal
policies.  Last year Greg Wettstein identified some files that should
have been measured, but were not included in the ima_tcb.  The newer
"ima_policy=tcb" includes those files.  Going forward, we should start
defining and sharing policies. 

Mimi

Re: [Linux-ima-user] IMA overwrites xattr even if it has got correct signature

[Patrick O. <pat...@in...>]

On Thu, 2016-02-25 at 11:09 -0500, Mimi Zohar wrote:
> On Thu, 2016-02-25 at 15:29 +0200, Dmitry Rozhkov wrote:
> > On Thu, 2016-02-25 at 07:43 -0500, Mimi Zohar wrote:
> 
> > > 
> > > If security.ima isn't being written because the file is not in policy,
> > > that is a different problem.   Perhaps try writing a file that is in the
> > > IMA-appraisal policy.
> > 
> > Didn't get it. The file is in the IMA-appraisal policy.
> > 
> > AFAIU upon file closing ima_inode_setxattr()
> > calls ima_reset_appraise_flags() where IMA_DIGSIG is supposed to be
> > set. But right before setting the flag there's the condition
> > 
> > 	iint = integrity_iint_find(inode);
> > 	if (!iint)
> > 		return;
> > 
> > which is true for newly created (and never closed yet) files.
> 
> There needs to be a FILE_CHECK rule for the iint to be created for a new
> file.

The policy is essentially just:

appraise fowner=0
measure fowner=0

with some dont_appraise/measure entries earlier for some special
filesystems.

How does this have to be extended to have a "FILE_CHECK rule"?

My understanding was that adding a "func" attribute just further limits
the scope of a rule. But to be honest, the exact meaning of the various
keywords remain a black art to me. I'm aware of the syntax definition in
the kernel doc, but that document does not explain the semantic.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] IMA overwrites xattr even if it has got correct signature

[Mimi Z. <zo...@li...>]

On Thu, 2016-02-25 at 15:29 +0200, Dmitry Rozhkov wrote:
> On Thu, 2016-02-25 at 07:43 -0500, Mimi Zohar wrote:

> > 
> > If security.ima isn't being written because the file is not in policy,
> > that is a different problem.   Perhaps try writing a file that is in the
> > IMA-appraisal policy.
> 
> Didn't get it. The file is in the IMA-appraisal policy.
> 
> AFAIU upon file closing ima_inode_setxattr()
> calls ima_reset_appraise_flags() where IMA_DIGSIG is supposed to be
> set. But right before setting the flag there's the condition
> 
> 	iint = integrity_iint_find(inode);
> 	if (!iint)
> 		return;
> 
> which is true for newly created (and never closed yet) files.

There needs to be a FILE_CHECK rule for the iint to be created for a new
file.

Mimi

Re: [Linux-ima-user] IMA overwrites xattr even if it has got correct signature

[Dmitry R. <dmi...@li...>]

On Thu, 2016-02-25 at 08:33 -0500, Mimi Zohar wrote:
> On Thu, 2016-02-25 at 15:29 +0200, Dmitry Rozhkov wrote:
> 
> > Thanks! I've just patched bsdtar to set xattrs after file closing
> > and
> > it fixes my problem.
> 
> It would be nice if this was fixed for others as well.  Are you
> planning
> on upstreaming the patch?
> 

I'v made this patch [1]. But I'm a bit reluctant to submit it as PR,
because with this patch IMA would spend CPU cycles for no good reason
on calculating useless hashes (which would be immediately overwritten
by tar).

[1] https://github.com/libarchive/libarchive/commit/911c6c0fb4870e20aa5
f88949408e4b349908036

BR,
Dima

Re: [Linux-ima-user] IMA overwrites xattr even if it has got correct signature

[Mimi Z. <zo...@li...>]

On Thu, 2016-02-25 at 15:29 +0200, Dmitry Rozhkov wrote:

> Thanks! I've just patched bsdtar to set xattrs after file closing and
> it fixes my problem.

It would be nice if this was fixed for others as well.  Are you planning
on upstreaming the patch?

Mimi

Re: [Linux-ima-user] IMA overwrites xattr even if it has got correct signature

[Dmitry R. <dmi...@li...>]

On Thu, 2016-02-25 at 07:43 -0500, Mimi Zohar wrote:
> On Thu, 2016-02-25 at 12:30 +0200, Dmitry Rozhkov wrote:
> > On Wed, 2016-02-24 at 11:31 -0500, Mimi Zohar wrote:
> > > On Wed, 2016-02-24 at 15:23 +0200, Dmitry Rozhkov wrote:
> > > > Hi!
> > > > 
> > > > I'm working on integrating IMA and swupd (Clear Linux software
> > > > updates)
> > > > and I'm experiencing problems with updating or installing new
> > > > files
> > > > on
> > > > systems with IMA enabled.
> > > > 
> > > > The problem comes from the fact that the IMA kernel module
> > > > unconditionally overwrites the security.ima extended attribute
> > > > upon
> > > > closing a file:
> > > > 1. the swupd client downloads a tarball with updates to
> > > > /var/lib/swupd;
> > > > 2. then unpacks the updated files preserving xattrs including
> > > > security.ima with file signatures;
> > > > 3. as soon as tar closes the unpacked files the kernel wipes
> > > > out
> > > > the
> > > > content of security.ima and puts new value (files' hashes
> > > > without
> > > > signatures).
> > > > 
> > > > AFAIU this happens in the kernel hook ima_file_free() called as
> > > > a
> > > > final
> > > > step of __dput() upon closing a file handle and freeing its
> > > > structure.
> > > > So there is no way to intervene and to prevent this xattr
> > > > reset.
> > > > 
> > > > As result I can't use software updates together with an IMA
> > > > policy
> > > > where all executables must be signed.
> > > > 
> > > > Is it possible not to overwrite a file's security.ima if upon
> > > > closing
> > > > the file its security.ima contains a correct signed hash
> > > > already? I
> > > > saw
> > > > Mimi mentioned the patch doing exactly that a month ago.
> > > 
> > > Commit c68ed80 "ima: limit file hash setting by user to fix and
> > > log
> > > modes" prevents writing a file hash as the security.ima xattr,
> > > which
> > > is
> > > a bit different than the use case that you described.  In that
> > > case,
> > > userspace is attempting to write the xattr.
> > > 
> > > In your usecase scenario, ima_check_last_writer() calls
> > > ima_update_xattr() to write the xattr.  It should prevent writing
> > > a
> > > hash, when the IMA_DIGSIG flag is set.  
> > > 
> > > Some questions for debugging this.  setxattr sets the IMA_DIGSIG
> > > flag.
> > > How is swupd writing out security.ima?   Why isn't IMA_DIGSIG
> > > being
> > > set?
> > 
> > swupd just untars files from a tarball to a staging direcotry.
> > Currently I'm using the libarchive-based bsdtar as tar replacement:
> > it
> > opens a file for writing, writes its content, then sets its
> > attributes
> > including xattrs and finaly closes the file (NB: GNU tar works
> > differently - creates an empty file, sets attributes, closes it,
> > tries
> > to reopen for writing its content, but fails because of failing
> > appraisal).
> 
> True, the xattrs are written first and then the file data, but at
> least
> as of a couple of years ago the file wasn't re-opened in between
> writing
> the xattrs and the file data.  I posted a patch to defer writing the
> security.ima xattr.*   With the IMA_NEW_FILE flag it might not be
> needed. 
> 

Thanks! I've just patched bsdtar to set xattrs after file closing and
it fixes my problem.

> > I suspect that the newly created file's inode doesn't have S_IMA
> > flag
> > since the file hasn't been measured yet (neither it has iint
> > associated
> > with the inode). So setting IMA_DIGSIG is never reached for the
> > file.
> 
> If security.ima isn't being written because the file is not in
> policy,
> that is a different problem.   Perhaps try writing a file that is in
> the
> IMA-appraisal policy.
> 

Didn't get it. The file is in the IMA-appraisal policy.

AFAIU upon file closing ima_inode_setxattr()
calls ima_reset_appraise_flags() where IMA_DIGSIG is supposed to be
set. But right before setting the flag there's the condition

	iint = integrity_iint_find(inode);
	if (!iint)
		return;

which is true for newly created (and never closed yet) files.

BR,
Dima

Re: [Linux-ima-user] IMA overwrites xattr even if it has got correct signature

[Mimi Z. <zo...@li...>]

On Thu, 2016-02-25 at 12:30 +0200, Dmitry Rozhkov wrote:
> On Wed, 2016-02-24 at 11:31 -0500, Mimi Zohar wrote:
> > On Wed, 2016-02-24 at 15:23 +0200, Dmitry Rozhkov wrote:
> > > Hi!
> > > 
> > > I'm working on integrating IMA and swupd (Clear Linux software
> > > updates)
> > > and I'm experiencing problems with updating or installing new files
> > > on
> > > systems with IMA enabled.
> > > 
> > > The problem comes from the fact that the IMA kernel module
> > > unconditionally overwrites the security.ima extended attribute upon
> > > closing a file:
> > > 1. the swupd client downloads a tarball with updates to
> > > /var/lib/swupd;
> > > 2. then unpacks the updated files preserving xattrs including
> > > security.ima with file signatures;
> > > 3. as soon as tar closes the unpacked files the kernel wipes out
> > > the
> > > content of security.ima and puts new value (files' hashes without
> > > signatures).
> > > 
> > > AFAIU this happens in the kernel hook ima_file_free() called as a
> > > final
> > > step of __dput() upon closing a file handle and freeing its
> > > structure.
> > > So there is no way to intervene and to prevent this xattr reset.
> > > 
> > > As result I can't use software updates together with an IMA policy
> > > where all executables must be signed.
> > > 
> > > Is it possible not to overwrite a file's security.ima if upon
> > > closing
> > > the file its security.ima contains a correct signed hash already? I
> > > saw
> > > Mimi mentioned the patch doing exactly that a month ago.
> > 
> > Commit c68ed80 "ima: limit file hash setting by user to fix and log
> > modes" prevents writing a file hash as the security.ima xattr, which
> > is
> > a bit different than the use case that you described.  In that case,
> > userspace is attempting to write the xattr.
> > 
> > In your usecase scenario, ima_check_last_writer() calls
> > ima_update_xattr() to write the xattr.  It should prevent writing a
> > hash, when the IMA_DIGSIG flag is set.  
> > 
> > Some questions for debugging this.  setxattr sets the IMA_DIGSIG
> > flag.
> > How is swupd writing out security.ima?   Why isn't IMA_DIGSIG being
> > set?
> 
> swupd just untars files from a tarball to a staging direcotry.
> Currently I'm using the libarchive-based bsdtar as tar replacement: it
> opens a file for writing, writes its content, then sets its attributes
> including xattrs and finaly closes the file (NB: GNU tar works
> differently - creates an empty file, sets attributes, closes it, tries
> to reopen for writing its content, but fails because of failing
> appraisal).

True, the xattrs are written first and then the file data, but at least
as of a couple of years ago the file wasn't re-opened in between writing
the xattrs and the file data.  I posted a patch to defer writing the
security.ima xattr.*   With the IMA_NEW_FILE flag it might not be
needed. 

> I suspect that the newly created file's inode doesn't have S_IMA flag
> since the file hasn't been measured yet (neither it has iint associated
> with the inode). So setting IMA_DIGSIG is never reached for the file.

If security.ima isn't being written because the file is not in policy,
that is a different problem.   Perhaps try writing a file that is in the
IMA-appraisal policy.

* http://lists.gnu.org/archive/html/bug-tar/2014-03/msg00029.html

Mimi

Re: [Linux-ima-user] IMA overwrites xattr even if it has got correct signature

[Dmitry R. <dmi...@li...>]

On Wed, 2016-02-24 at 11:31 -0500, Mimi Zohar wrote:
> On Wed, 2016-02-24 at 15:23 +0200, Dmitry Rozhkov wrote:
> > Hi!
> > 
> > I'm working on integrating IMA and swupd (Clear Linux software
> > updates)
> > and I'm experiencing problems with updating or installing new files
> > on
> > systems with IMA enabled.
> > 
> > The problem comes from the fact that the IMA kernel module
> > unconditionally overwrites the security.ima extended attribute upon
> > closing a file:
> > 1. the swupd client downloads a tarball with updates to
> > /var/lib/swupd;
> > 2. then unpacks the updated files preserving xattrs including
> > security.ima with file signatures;
> > 3. as soon as tar closes the unpacked files the kernel wipes out
> > the
> > content of security.ima and puts new value (files' hashes without
> > signatures).
> > 
> > AFAIU this happens in the kernel hook ima_file_free() called as a
> > final
> > step of __dput() upon closing a file handle and freeing its
> > structure.
> > So there is no way to intervene and to prevent this xattr reset.
> > 
> > As result I can't use software updates together with an IMA policy
> > where all executables must be signed.
> > 
> > Is it possible not to overwrite a file's security.ima if upon
> > closing
> > the file its security.ima contains a correct signed hash already? I
> > saw
> > Mimi mentioned the patch doing exactly that a month ago.
> 
> Commit c68ed80 "ima: limit file hash setting by user to fix and log
> modes" prevents writing a file hash as the security.ima xattr, which
> is
> a bit different than the use case that you described.  In that case,
> userspace is attempting to write the xattr.
> 
> In your usecase scenario, ima_check_last_writer() calls
> ima_update_xattr() to write the xattr.  It should prevent writing a
> hash, when the IMA_DIGSIG flag is set.  
> 
> Some questions for debugging this.  setxattr sets the IMA_DIGSIG
> flag.
> How is swupd writing out security.ima?   Why isn't IMA_DIGSIG being
> set?

swupd just untars files from a tarball to a staging direcotry.
Currently I'm using the libarchive-based bsdtar as tar replacement: it
opens a file for writing, writes its content, then sets its attributes
including xattrs and finaly closes the file (NB: GNU tar works
differently - creates an empty file, sets attributes, closes it, tries
to reopen for writing its content, but fails because of failing
appraisal).

I suspect that the newly created file's inode doesn't have S_IMA flag
since the file hasn't been measured yet (neither it has iint associated
with the inode). So setting IMA_DIGSIG is never reached for the file.

BR,
Dima 

Re: [Linux-ima-user] IMA overwrites xattr even if it has got correct signature

[Mimi Z. <zo...@li...>]

On Wed, 2016-02-24 at 15:23 +0200, Dmitry Rozhkov wrote:
> Hi!
> 
> I'm working on integrating IMA and swupd (Clear Linux software updates)
> and I'm experiencing problems with updating or installing new files on
> systems with IMA enabled.
>
> The problem comes from the fact that the IMA kernel module
> unconditionally overwrites the security.ima extended attribute upon
> closing a file:
> 1. the swupd client downloads a tarball with updates to /var/lib/swupd;
> 2. then unpacks the updated files preserving xattrs including
> security.ima with file signatures;
> 3. as soon as tar closes the unpacked files the kernel wipes out the
> content of security.ima and puts new value (files' hashes without
> signatures).
> 
> AFAIU this happens in the kernel hook ima_file_free() called as a final
> step of __dput() upon closing a file handle and freeing its structure.
> So there is no way to intervene and to prevent this xattr reset.
> 
> As result I can't use software updates together with an IMA policy
> where all executables must be signed.
> 
> Is it possible not to overwrite a file's security.ima if upon closing
> the file its security.ima contains a correct signed hash already? I saw
> Mimi mentioned the patch doing exactly that a month ago.

Commit c68ed80 "ima: limit file hash setting by user to fix and log
modes" prevents writing a file hash as the security.ima xattr, which is
a bit different than the use case that you described.  In that case,
userspace is attempting to write the xattr.

In your usecase scenario, ima_check_last_writer() calls
ima_update_xattr() to write the xattr.  It should prevent writing a
hash, when the IMA_DIGSIG flag is set.  

Some questions for debugging this.  setxattr sets the IMA_DIGSIG flag.
How is swupd writing out security.ima?   Why isn't IMA_DIGSIG being set?

Mimi

[Linux-ima-user] IMA overwrites xattr even if it has got correct signature

[Dmitry R. <dmi...@li...>]

Hi!

I'm working on integrating IMA and swupd (Clear Linux software updates)
and I'm experiencing problems with updating or installing new files on
systems with IMA enabled.

The problem comes from the fact that the IMA kernel module
unconditionally overwrites the security.ima extended attribute upon
closing a file:
1. the swupd client downloads a tarball with updates to /var/lib/swupd;
2. then unpacks the updated files preserving xattrs including
security.ima with file signatures;
3. as soon as tar closes the unpacked files the kernel wipes out the
content of security.ima and puts new value (files' hashes without
signatures).

AFAIU this happens in the kernel hook ima_file_free() called as a final
step of __dput() upon closing a file handle and freeing its structure.
So there is no way to intervene and to prevent this xattr reset.

As result I can't use software updates together with an IMA policy
where all executables must be signed.

Is it possible not to overwrite a file's security.ima if upon closing
the file its security.ima contains a correct signed hash already? I saw
Mimi mentioned the patch doing exactly that a month ago.

BR,
Dmitry

Re: [Linux-ima-user] IMA hash update

[Mimi Z. <zo...@li...>]

On Thu, 2016-02-18 at 20:23 +0100, Patrick Ohly wrote:
> On Thu, 2016-02-18 at 13:34 -0500, Mimi Zohar wrote:
> > Hi Patrick,
> > 
> > On Thu, 2016-02-18 at 12:32 -0500, Mimi Zohar wrote:
> > > On Thu, 2016-02-18 at 15:41 +0100, Patrick Ohly wrote:
> > > > On Thu, 2016-02-18 at 07:32 -0500, Mimi Zohar wrote:
> > > > If anyone has suggestions for debugging the long delay until data gets
> > > > flushed, then I am open for suggestions. I'm still seeing that even with
> > > > "data=journal", it's only that the effect is less drastic.
> > > 
> > > Currently, S_SYNC isn't set.  Setting it looks like it would resolve the
> > > problem.
> > > fs/ext4/xattr.c:
> > >                 if (IS_SYNC(inode))
> > >                         ext4_handle_sync(handle);
> > 
> > Changing  'if (IS_SYNC(inode))" to  "if (IS_SYNC(inode)  ||
> > IS_IMA(inode))" in both places should fix the problem.
> 
> What is the expected effect of this change?
> 
> I've added the change to my kernel. When running with data=ordered and
> cutting power a few seconds after writing /etc/machine-id without
> fsync(), I still get an empty file with a security.ima for the non-empty
> file.
> 
> I also tried with a wait time of 10 seconds (i.e. more than the default
> five second commit delay), but still no luck.

I'm not sure why that didn't work.

Mike had suggested making the file system inode size larger, so that the
xattrs would be stored in the inode and not in the extra block
(i_file_acl).  Perhaps then the xattrs and the filedata would be updated
at the same time.

from mkfs.ext4 manpage:
       -I inode-size
              Specify the size of each inode in bytes.  The  inode-size  value
              must  be  a  power  of 2 larger or equal to 128.  The larger the
              inode-size the more space the inode table will consume, and this
              reduces  the  usable  space in the filesystem and can also nega‐
              tively impact performance.  It is not possible  to  change  this
              value after the filesystem is created.

              In  kernels  after  2.6.10 and some earlier vendor kernels it is
              possible to utilize  inodes  larger  than  128  bytes  to  store
              extended   attributes   for   improved   performance.   Extended
              attributes stored in large inodes are  not  visible  with  older
              kernels,  and  such  filesystems  will not be mountable with 2.4
              kernels at all.

              The default inode size is controlled by the mke2fs.conf(5) file.
              In  the  mke2fs.conf  file  shipped  with e2fsprogs, the default
              inode size is 256 bytes for most file systems, except for  small
              file systems where the inode size will be 128 bytes.

Mimi

Re: [Linux-ima-user] IMA hash update

[Mimi Z. <zo...@li...>]

Hi Ted,

On Thu, 2016-02-18 at 15:41 +0100, Patrick Ohly wrote:
> On Thu, 2016-02-18 at 07:32 -0500, Mimi Zohar wrote:
> > On Mon, 2016-02-15 at 11:27 +0100, Patrick Ohly wrote:
> > > On Tue, 2015-09-22 at 20:10 +0200, Patrick Ohly wrote:
> > > > On Tue, 2015-09-22 at 09:04 -0400, Mimi Zohar wrote:
> > > > > On Tue, 2015-09-22 at 14:58 +0200, Patrick Ohly wrote:
> > > > > > Would it be possible to intercept the in-kernel implementation of
> > > > > > fdatasync() and trigger a hash update *and* a flushing of the xattr?
> > > > > 
> > > > > That sounds like a good compromise, but would it be enough to resolve
> > > > > the problem?
> > > > 
> > > > I suspect that there's still a time window where a file content change
> > > > has hit the disk while the corresponding xattr change has not, for
> > > > example between writes and the fdatasync(). It would be much better, but
> > > > probably not good enough.
> > > > 
> > > > Primarily I wanted to raise the problem here and get opinions. My
> > > > conclusion is that writing databases probably should be done where it is
> > > > not in the IMA policy, even if the risk was reduced by also updating the
> > > > hash on fdatasync().
> > > 
> > > Let me come back to this.
> > > 
> > > I noticed that even for simple files, like /etc/machine-id, it is very
> > > easy to corrupt the system. /etc/machine-id contains a 32 byte unique
> > > ID, written by systemd in machine_id_commit() [1]. That code does a
> > > normal close(), i.e. no explicit fdatasync() and no fsync().
> > > 
> > > [1] https://github.com/systemd/systemd/blob/master/src/core/machine-id-setup.c
> > > 
> > > When using on-device hashing and ext4, the new file and its data are
> > > stored by ext4 right away (at least in the journal), but the
> > > corresponding security.ima remains cached in memory for surprisingly
> > > long periods of time (minutes or longer - haven't tried to determine
> > > that more precisely).
> > > 
> > > Power off during that time and the system becomes unusable due to the
> > > "permission denied" on a core system file.
> > > 
> > > Any recommendations for addressing the problem, not just
> > > for /etc/machine-id, but also in general?
> > 
> > The first question is whether the xattr not being saved/restored is
> > limited to those stored in the extra block (i_file_acl) or in the inode
> > as well.   Defining EXT4_XATTR_DEBUG in fs/ext4/xattr.c will show where
> > the xattrs are being stored.  I assume they are being stored in the
> > extra block.
> 
> While testing this, I noticed that my earlier comment about xattr not
> getting flushed is wrong: it is the other way around. File *content*
> isn't getting flushed to disk, whereas the modified xattr is.
> 
> That also explains why adding fsync() helps: it forces the content to
> disk, so content and xattr match after a powerloss.
> 
> But the underlying problem remains the same: with IMA, it is much more
> important that meta data and file content remain in sync than it is
> without, and that's currently not working well.
> 
> > > For machine-id, I can add an explicit "sync" shell command invocation
> > > after writing the file, but that's not a general solution.
> > > 
> > > Implementing the enhanced fdatasync() mentioned before and relying on
> > > programs to call fdatasync() would help somewhat, but not all programs
> > > call it. Would calling fsync() in systemd have helped?
> > > 
> > > ext4 mount options also don't look promising. commit=nrsec flushes data
> > > after 5 seconds by default, but does not seem to include xattrs.
> > > 
> > > Journaling is already using data=ordered, so meta data should be as safe
> > > as it can be, and yet it still doesn't include the modified xattr.
> 
> Given these settings, it is surprising that the data does not get
> flushed to disk even after minutes.
> 
> Could this be a result of running under qemu? I kill the qemu process
> instead of properly shutting down the virtual machine. No, that's not it
> either. Even when resetting with "system_reset", I get the same failure.
> 
> "data=journal" helps. It avoids the problem completely and might be the
> best solution despite the impact ("disables delayed allocation and
> O_DIRECT").
> 
> If anyone has suggestions for debugging the long delay until data gets
> flushed, then I am open for suggestions. I'm still seeing that even with
> "data=journal", it's only that the effect is less drastic.

Any suggestions on how to force the filedata to be flushed to disk as
soon as the security xattrs are written.

Thanks!

Mimi

Re: [Linux-ima-user] IMA hash update

[Patrick O. <pat...@in...>]

On Thu, 2016-02-18 at 13:34 -0500, Mimi Zohar wrote:
> Hi Patrick,
> 
> On Thu, 2016-02-18 at 12:32 -0500, Mimi Zohar wrote:
> > On Thu, 2016-02-18 at 15:41 +0100, Patrick Ohly wrote:
> > > On Thu, 2016-02-18 at 07:32 -0500, Mimi Zohar wrote:
> > > If anyone has suggestions for debugging the long delay until data gets
> > > flushed, then I am open for suggestions. I'm still seeing that even with
> > > "data=journal", it's only that the effect is less drastic.
> > 
> > Currently, S_SYNC isn't set.  Setting it looks like it would resolve the
> > problem.
> > fs/ext4/xattr.c:
> >                 if (IS_SYNC(inode))
> >                         ext4_handle_sync(handle);
> 
> Changing  'if (IS_SYNC(inode))" to  "if (IS_SYNC(inode)  ||
> IS_IMA(inode))" in both places should fix the problem.

What is the expected effect of this change?

I've added the change to my kernel. When running with data=ordered and
cutting power a few seconds after writing /etc/machine-id without
fsync(), I still get an empty file with a security.ima for the non-empty
file.

I also tried with a wait time of 10 seconds (i.e. more than the default
five second commit delay), but still no luck.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] IMA hash update

[Mimi Z. <zo...@li...>]

Hi Patrick,

On Thu, 2016-02-18 at 12:32 -0500, Mimi Zohar wrote:
> On Thu, 2016-02-18 at 15:41 +0100, Patrick Ohly wrote:
> > On Thu, 2016-02-18 at 07:32 -0500, Mimi Zohar wrote:
> > If anyone has suggestions for debugging the long delay until data gets
> > flushed, then I am open for suggestions. I'm still seeing that even with
> > "data=journal", it's only that the effect is less drastic.
> 
> Currently, S_SYNC isn't set.  Setting it looks like it would resolve the
> problem.
> fs/ext4/xattr.c:
>                 if (IS_SYNC(inode))
>                         ext4_handle_sync(handle);

Changing  'if (IS_SYNC(inode))" to  "if (IS_SYNC(inode)  ||
IS_IMA(inode))" in both places should fix the problem.

Mimi

Re: [Linux-ima-user] IMA hash update

[Mimi Z. <zo...@li...>]

On Thu, 2016-02-18 at 15:41 +0100, Patrick Ohly wrote:
> On Thu, 2016-02-18 at 07:32 -0500, Mimi Zohar wrote:
> > On Mon, 2016-02-15 at 11:27 +0100, Patrick Ohly wrote:
> > > On Tue, 2015-09-22 at 20:10 +0200, Patrick Ohly wrote:
> > > > On Tue, 2015-09-22 at 09:04 -0400, Mimi Zohar wrote:
> > > > > On Tue, 2015-09-22 at 14:58 +0200, Patrick Ohly wrote:
> > > > > > Would it be possible to intercept the in-kernel implementation of
> > > > > > fdatasync() and trigger a hash update *and* a flushing of the xattr?
> > > > > 
> > > > > That sounds like a good compromise, but would it be enough to resolve
> > > > > the problem?
> > > > 
> > > > I suspect that there's still a time window where a file content change
> > > > has hit the disk while the corresponding xattr change has not, for
> > > > example between writes and the fdatasync(). It would be much better, but
> > > > probably not good enough.
> > > > 
> > > > Primarily I wanted to raise the problem here and get opinions. My
> > > > conclusion is that writing databases probably should be done where it is
> > > > not in the IMA policy, even if the risk was reduced by also updating the
> > > > hash on fdatasync().
> > > 
> > > Let me come back to this.
> > > 
> > > I noticed that even for simple files, like /etc/machine-id, it is very
> > > easy to corrupt the system. /etc/machine-id contains a 32 byte unique
> > > ID, written by systemd in machine_id_commit() [1]. That code does a
> > > normal close(), i.e. no explicit fdatasync() and no fsync().
> > > 
> > > [1] https://github.com/systemd/systemd/blob/master/src/core/machine-id-setup.c
> > > 
> > > When using on-device hashing and ext4, the new file and its data are
> > > stored by ext4 right away (at least in the journal), but the
> > > corresponding security.ima remains cached in memory for surprisingly
> > > long periods of time (minutes or longer - haven't tried to determine
> > > that more precisely).
> > > 
> > > Power off during that time and the system becomes unusable due to the
> > > "permission denied" on a core system file.
> > > 
> > > Any recommendations for addressing the problem, not just
> > > for /etc/machine-id, but also in general?
> > 
> > The first question is whether the xattr not being saved/restored is
> > limited to those stored in the extra block (i_file_acl) or in the inode
> > as well.   Defining EXT4_XATTR_DEBUG in fs/ext4/xattr.c will show where
> > the xattrs are being stored.  I assume they are being stored in the
> > extra block.
> 
> While testing this, I noticed that my earlier comment about xattr not
> getting flushed is wrong: it is the other way around. File *content*
> isn't getting flushed to disk, whereas the modified xattr is.
> 
> That also explains why adding fsync() helps: it forces the content to
> disk, so content and xattr match after a powerloss.
> 
> But the underlying problem remains the same: with IMA, it is much more
> important that meta data and file content remain in sync than it is
> without, and that's currently not working well.
> 
> > > For machine-id, I can add an explicit "sync" shell command invocation
> > > after writing the file, but that's not a general solution.
> > > 
> > > Implementing the enhanced fdatasync() mentioned before and relying on
> > > programs to call fdatasync() would help somewhat, but not all programs
> > > call it. Would calling fsync() in systemd have helped?
> > > 
> > > ext4 mount options also don't look promising. commit=nrsec flushes data
> > > after 5 seconds by default, but does not seem to include xattrs.
> > > 
> > > Journaling is already using data=ordered, so meta data should be as safe
> > > as it can be, and yet it still doesn't include the modified xattr.
> 
> Given these settings, it is surprising that the data does not get
> flushed to disk even after minutes.
> 
> Could this be a result of running under qemu? I kill the qemu process
> instead of properly shutting down the virtual machine. No, that's not it
> either. Even when resetting with "system_reset", I get the same failure.
> 
> "data=journal" helps. It avoids the problem completely and might be the
> best solution despite the impact ("disables delayed allocation and
> O_DIRECT").
> 
> If anyone has suggestions for debugging the long delay until data gets
> flushed, then I am open for suggestions. I'm still seeing that even with
> "data=journal", it's only that the effect is less drastic.

Currently, S_SYNC isn't set.  Setting it looks like it would resolve the
problem.
fs/ext4/xattr.c:
                if (IS_SYNC(inode))
                        ext4_handle_sync(handle);

Mimi

Re: [Linux-ima-user] IMA hash update

[Patrick O. <pat...@in...>]

On Thu, 2016-02-18 at 07:32 -0500, Mimi Zohar wrote:
> On Mon, 2016-02-15 at 11:27 +0100, Patrick Ohly wrote:
> > On Tue, 2015-09-22 at 20:10 +0200, Patrick Ohly wrote:
> > > On Tue, 2015-09-22 at 09:04 -0400, Mimi Zohar wrote:
> > > > On Tue, 2015-09-22 at 14:58 +0200, Patrick Ohly wrote:
> > > > > Would it be possible to intercept the in-kernel implementation of
> > > > > fdatasync() and trigger a hash update *and* a flushing of the xattr?
> > > > 
> > > > That sounds like a good compromise, but would it be enough to resolve
> > > > the problem?
> > > 
> > > I suspect that there's still a time window where a file content change
> > > has hit the disk while the corresponding xattr change has not, for
> > > example between writes and the fdatasync(). It would be much better, but
> > > probably not good enough.
> > > 
> > > Primarily I wanted to raise the problem here and get opinions. My
> > > conclusion is that writing databases probably should be done where it is
> > > not in the IMA policy, even if the risk was reduced by also updating the
> > > hash on fdatasync().
> > 
> > Let me come back to this.
> > 
> > I noticed that even for simple files, like /etc/machine-id, it is very
> > easy to corrupt the system. /etc/machine-id contains a 32 byte unique
> > ID, written by systemd in machine_id_commit() [1]. That code does a
> > normal close(), i.e. no explicit fdatasync() and no fsync().
> > 
> > [1] https://github.com/systemd/systemd/blob/master/src/core/machine-id-setup.c
> > 
> > When using on-device hashing and ext4, the new file and its data are
> > stored by ext4 right away (at least in the journal), but the
> > corresponding security.ima remains cached in memory for surprisingly
> > long periods of time (minutes or longer - haven't tried to determine
> > that more precisely).
> > 
> > Power off during that time and the system becomes unusable due to the
> > "permission denied" on a core system file.
> > 
> > Any recommendations for addressing the problem, not just
> > for /etc/machine-id, but also in general?
> 
> The first question is whether the xattr not being saved/restored is
> limited to those stored in the extra block (i_file_acl) or in the inode
> as well.   Defining EXT4_XATTR_DEBUG in fs/ext4/xattr.c will show where
> the xattrs are being stored.  I assume they are being stored in the
> extra block.

While testing this, I noticed that my earlier comment about xattr not
getting flushed is wrong: it is the other way around. File *content*
isn't getting flushed to disk, whereas the modified xattr is.

That also explains why adding fsync() helps: it forces the content to
disk, so content and xattr match after a powerloss.

But the underlying problem remains the same: with IMA, it is much more
important that meta data and file content remain in sync than it is
without, and that's currently not working well.

> > For machine-id, I can add an explicit "sync" shell command invocation
> > after writing the file, but that's not a general solution.
> > 
> > Implementing the enhanced fdatasync() mentioned before and relying on
> > programs to call fdatasync() would help somewhat, but not all programs
> > call it. Would calling fsync() in systemd have helped?
> > 
> > ext4 mount options also don't look promising. commit=nrsec flushes data
> > after 5 seconds by default, but does not seem to include xattrs.
> > 
> > Journaling is already using data=ordered, so meta data should be as safe
> > as it can be, and yet it still doesn't include the modified xattr.

Given these settings, it is surprising that the data does not get
flushed to disk even after minutes.

Could this be a result of running under qemu? I kill the qemu process
instead of properly shutting down the virtual machine. No, that's not it
either. Even when resetting with "system_reset", I get the same failure.

"data=journal" helps. It avoids the problem completely and might be the
best solution despite the impact ("disables delayed allocation and
O_DIRECT").

If anyone has suggestions for debugging the long delay until data gets
flushed, then I am open for suggestions. I'm still seeing that even with
"data=journal", it's only that the effect is less drastic.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] IMA hash update

[Mimi Z. <zo...@li...>]

On Mon, 2016-02-15 at 11:27 +0100, Patrick Ohly wrote:
> On Tue, 2015-09-22 at 20:10 +0200, Patrick Ohly wrote:
> > On Tue, 2015-09-22 at 09:04 -0400, Mimi Zohar wrote:
> > > On Tue, 2015-09-22 at 14:58 +0200, Patrick Ohly wrote:
> > > > Would it be possible to intercept the in-kernel implementation of
> > > > fdatasync() and trigger a hash update *and* a flushing of the xattr?
> > > 
> > > That sounds like a good compromise, but would it be enough to resolve
> > > the problem?
> > 
> > I suspect that there's still a time window where a file content change
> > has hit the disk while the corresponding xattr change has not, for
> > example between writes and the fdatasync(). It would be much better, but
> > probably not good enough.
> > 
> > Primarily I wanted to raise the problem here and get opinions. My
> > conclusion is that writing databases probably should be done where it is
> > not in the IMA policy, even if the risk was reduced by also updating the
> > hash on fdatasync().
> 
> Let me come back to this.
> 
> I noticed that even for simple files, like /etc/machine-id, it is very
> easy to corrupt the system. /etc/machine-id contains a 32 byte unique
> ID, written by systemd in machine_id_commit() [1]. That code does a
> normal close(), i.e. no explicit fdatasync() and no fsync().
> 
> [1] https://github.com/systemd/systemd/blob/master/src/core/machine-id-setup.c
> 
> When using on-device hashing and ext4, the new file and its data are
> stored by ext4 right away (at least in the journal), but the
> corresponding security.ima remains cached in memory for surprisingly
> long periods of time (minutes or longer - haven't tried to determine
> that more precisely).
> 
> Power off during that time and the system becomes unusable due to the
> "permission denied" on a core system file.
> 
> Any recommendations for addressing the problem, not just
> for /etc/machine-id, but also in general?

The first question is whether the xattr not being saved/restored is
limited to those stored in the extra block (i_file_acl) or in the inode
as well.   Defining EXT4_XATTR_DEBUG in fs/ext4/xattr.c will show where
the xattrs are being stored.  I assume they are being stored in the
extra block.

Mimi

> For machine-id, I can add an explicit "sync" shell command invocation
> after writing the file, but that's not a general solution.
> 
> Implementing the enhanced fdatasync() mentioned before and relying on
> programs to call fdatasync() would help somewhat, but not all programs
> call it. Would calling fsync() in systemd have helped?
> 
> ext4 mount options also don't look promising. commit=nrsec flushes data
> after 5 seconds by default, but does not seem to include xattrs.
> 
> Journaling is already using data=ordered, so meta data should be as safe
> as it can be, and yet it still doesn't include the modified xattr.
> 

Re: [Linux-ima-user] IMA hash update

[Mimi Z. <zo...@li...>]

> > It sounds like the same methods for preserving the file data need to be
> > extended to preserve the file metadata.  I haven't looked at the kernel
> > code (yet), so I don't know how hard it would be to implement.
> 
> I'm not a kernel expert, so any guidance would be welcome.

Look at it as an opportunity.  It's a matter of code digging and more
code digging, which just takes time.  :/

Mimi

Re: [Linux-ima-user] IMA hash update

[Patrick O. <pat...@in...>]

On Mon, 2016-02-15 at 10:45 -0500, Mimi Zohar wrote:
> On Mon, 2016-02-15 at 11:27 +0100, Patrick Ohly wrote:
> > Implementing the enhanced fdatasync() mentioned before and relying on
> > programs to call fdatasync() would help somewhat, but not all programs
> > call it. Would calling fsync() in systemd have helped?

I tried it and fsync() before close() seems to have helped. Does that
make sense, considering that it was said earlier that security.ima only
gets calculated on close()?

> > ext4 mount options also don't look promising. commit=nrsec flushes data
> > after 5 seconds by default, but does not seem to include xattrs.
> > 
> > Journaling is already using data=ordered, so meta data should be as safe
> > as it can be, and yet it still doesn't include the modified xattr.
> 
> It sounds like the same methods for preserving the file data need to be
> extended to preserve the file metadata.  I haven't looked at the kernel
> code (yet), so I don't know how hard it would be to implement.

I'm not a kernel expert, so any guidance would be welcome.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] IMA hash update

[Mimi Z. <zo...@li...>]

On Mon, 2016-02-15 at 11:27 +0100, Patrick Ohly wrote:
> On Tue, 2015-09-22 at 20:10 +0200, Patrick Ohly wrote:
> > On Tue, 2015-09-22 at 09:04 -0400, Mimi Zohar wrote:
> > > On Tue, 2015-09-22 at 14:58 +0200, Patrick Ohly wrote:
> > > > Would it be possible to intercept the in-kernel implementation of
> > > > fdatasync() and trigger a hash update *and* a flushing of the xattr?
> > > 
> > > That sounds like a good compromise, but would it be enough to resolve
> > > the problem?
> > 
> > I suspect that there's still a time window where a file content change
> > has hit the disk while the corresponding xattr change has not, for
> > example between writes and the fdatasync(). It would be much better, but
> > probably not good enough.
> > 
> > Primarily I wanted to raise the problem here and get opinions. My
> > conclusion is that writing databases probably should be done where it is
> > not in the IMA policy, even if the risk was reduced by also updating the
> > hash on fdatasync().
> 
> Let me come back to this.
> 
> I noticed that even for simple files, like /etc/machine-id, it is very
> easy to corrupt the system. /etc/machine-id contains a 32 byte unique
> ID, written by systemd in machine_id_commit() [1]. That code does a
> normal close(), i.e. no explicit fdatasync() and no fsync().
> 
> [1] https://github.com/systemd/systemd/blob/master/src/core/machine-id-setup.c
> 
> When using on-device hashing and ext4, the new file and its data are
> stored by ext4 right away (at least in the journal), but the
> corresponding security.ima remains cached in memory for surprisingly
> long periods of time (minutes or longer - haven't tried to determine
> that more precisely).
> 
> Power off during that time and the system becomes unusable due to the
> "permission denied" on a core system file.
> 
> Any recommendations for addressing the problem, not just
> for /etc/machine-id, but also in general?
> 
> For machine-id, I can add an explicit "sync" shell command invocation
> after writing the file, but that's not a general solution.
> 
> Implementing the enhanced fdatasync() mentioned before and relying on
> programs to call fdatasync() would help somewhat, but not all programs
> call it. Would calling fsync() in systemd have helped?
> 
> ext4 mount options also don't look promising. commit=nrsec flushes data
> after 5 seconds by default, but does not seem to include xattrs.
> 
> Journaling is already using data=ordered, so meta data should be as safe
> as it can be, and yet it still doesn't include the modified xattr.

It sounds like the same methods for preserving the file data need to be
extended to preserve the file metadata.  I haven't looked at the kernel
code (yet), so I don't know how hard it would be to implement.

Mimi

Re: [Linux-ima-user] IMA hash update

[Patrick O. <pat...@in...>]

On Tue, 2015-09-22 at 20:10 +0200, Patrick Ohly wrote:
> On Tue, 2015-09-22 at 09:04 -0400, Mimi Zohar wrote:
> > On Tue, 2015-09-22 at 14:58 +0200, Patrick Ohly wrote:
> > > Would it be possible to intercept the in-kernel implementation of
> > > fdatasync() and trigger a hash update *and* a flushing of the xattr?
> > 
> > That sounds like a good compromise, but would it be enough to resolve
> > the problem?
> 
> I suspect that there's still a time window where a file content change
> has hit the disk while the corresponding xattr change has not, for
> example between writes and the fdatasync(). It would be much better, but
> probably not good enough.
> 
> Primarily I wanted to raise the problem here and get opinions. My
> conclusion is that writing databases probably should be done where it is
> not in the IMA policy, even if the risk was reduced by also updating the
> hash on fdatasync().

Let me come back to this.

I noticed that even for simple files, like /etc/machine-id, it is very
easy to corrupt the system. /etc/machine-id contains a 32 byte unique
ID, written by systemd in machine_id_commit() [1]. That code does a
normal close(), i.e. no explicit fdatasync() and no fsync().

[1] https://github.com/systemd/systemd/blob/master/src/core/machine-id-setup.c

When using on-device hashing and ext4, the new file and its data are
stored by ext4 right away (at least in the journal), but the
corresponding security.ima remains cached in memory for surprisingly
long periods of time (minutes or longer - haven't tried to determine
that more precisely).

Power off during that time and the system becomes unusable due to the
"permission denied" on a core system file.

Any recommendations for addressing the problem, not just
for /etc/machine-id, but also in general?

For machine-id, I can add an explicit "sync" shell command invocation
after writing the file, but that's not a general solution.

Implementing the enhanced fdatasync() mentioned before and relying on
programs to call fdatasync() would help somewhat, but not all programs
call it. Would calling fsync() in systemd have helped?

ext4 mount options also don't look promising. commit=nrsec flushes data
after 5 seconds by default, but does not seem to include xattrs.

Journaling is already using data=ordered, so meta data should be as safe
as it can be, and yet it still doesn't include the modified xattr.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Linux-ima-user] [RFC] i.MX6 CAAM blob generator for IMA/EVM initialization

[Jan L. <jl...@pe...>]

Hi!

On Do, 2016-01-28 at 10:41 -0500, Mimi Zohar wrote:
> On Wed, 2016-01-27 at 11:04 +0100, Steffen Trumtrar wrote:
> > Can I somehow use the keyring framework as an abstraction around my
> > blobbing/deblobbing functionality?
> > So that the "keyring" calls into the crypto driver to decrypt the data
> > and uses the crypto driver to encrypt the keys when I want to "dump"
> > them?
> 
> Definitely.   It sounds like you want the equivalent functionality as
> the TPM based trusted keys using OTP on the CAAM.
> 
> From Documentation/security/keys-trusted-encrypted.txt:
> 
> "Trusted Keys use a TPM both to generate and to seal the keys.  Keys are
> sealed under a 2048 bit RSA key in the TPM, and optionally sealed to specified
> PCR (integrity measurement) values, and only unsealed by the TPM, if PCRs
> and blob integrity verifications match."

OK. The implementation is in security/keys/trusted.c, right? This talks
directly to the TPM. Also the code in security/keys/encrypted-keys/
explicitly uses the interface in keys/trusted-type.h.

Now I'm not sure how to best allow using the CAAM as an alternative to a
TPM. Would we have different "backends" in the trusted keys
implementation so that for example encrypted keys don't need to know
about the difference?

Otherwise we would need to add another key type ("trusted-caam?"). Then
we'd need to add code to support trusted-caam keys wherever we already
support trusted(-tpm) keys?

Do you have a suggestion on how we should proceed?

Best regards,
Jan Lübbe
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [Linux-ima-user] [RFC] i.MX6 CAAM blob generator for IMA/EVM initialization

[Mimi Z. <zo...@li...>]

On Wed, 2016-01-27 at 11:04 +0100, Steffen Trumtrar wrote:
> Hi!
> 
> Mimi Zohar writes:
> 
> > On Mon, 2015-11-09 at 16:18 +0100, Steffen Trumtrar wrote:
> >> Hi!
> >> 
> >> The RFC Patch attached after this cover letter is mostly for illustration
> >> purposes, so please don't waste too much time reviewing the code ;-)
> >> 
> >> For context I'll try to describe the problem that this patch tries to solve.
> >> 
> >> I need to be able to boot an EVM signed (and dongled) rootfs. The CAAM on
> >> the i.MX6 has support for an OTP key and can en/decrypt data.
> >> It also has a feature for generating red blobs: basically a chunk of data,
> >> that is encrypted with the OTP key, which can be saved on some medium as a
> >> secret to decrypt the EVM HMAC secret for one specific device.
> >> 
> >> To open the rootfs, the secret is handed from the bootloader to the kernel
> >> as a base64 encoded string via the cmdline to an initramfs.
> >> In the initramfs the sysfs file "modifier" is set to something starting with
> >> "kernel:evm" and the base64 string is written to the sysfs file "blob".
> >> The CAAM than decodes the red blob and, in case of "kernel:evm", initializes
> >> the EVM or otherwise writes the result to "payload" if the modifier starts
> >> with "user:". Therefore a blob that was generated for EVM never leaves the
> >> kernel on decryption.
> >> Generation of blobs goes like: echoing "modifier" to something and echoing
> >> the payload to "payload". The red blob can than be read from "blob".
> >> 
> >> 
> >> So, the sysfs interface is not the best option, I guess. The question is:
> >> What is the right approach for a setup like this?
> >> I need to:
> >>   - be able to encrypt the secret and store it somewhere
> >>   - to load the stored secret and decrypt it later
> >>   - initialize IMA/EVM with the secret
> >> 
> >> Would something like
> >>   - security/keys/encrypted-keys/encrypted.c
> >> be the correct approach?
> >
> > Instead of using the CAAM for OTP encrypting/decrypting, can it be used
> > to load the EVM key directly?  Dmitry's patches, which will be
> > upstreamed in 4.5
> >
> https://git.kernel.org/cgit/linux/kernel/git/zohar/linux-integrity.git/log/?h=for-next-4.5?   adds support for a crypto device to directly load the EVM key.
> >
> 
> The patches look good and I use them for loading the EVM key from the
> CAAM driver. But I still need the OTP decryption functionality.

> The key data that I hand to evm_set_key must be device specific but I
> don't want to use the fused OTP in the CAAM directly.
> The OTP is used to protect multiple random keys. Therefore I need to
> generate encrypted blobs that I can store on some unsecure memory
> (EEPROM, NAND,...) and be able to hand that later back to the CAAM
> module, to then get back an IMA/EVM, ecryptfs, $something key.
> 
> > FYI, the EVM key is an encrypted key, which encrypts/decrypts either a
> > trusted or user type key.
> >
> So the normal approach would be to have a key in the kernel keyring
> and decrypt it with the key loaded with evm_set_key?

Sorry, I should have said the encrypted key is encrypted/decrypted using
the trusted or user type key.

> Can I somehow use the keyring framework as an abstraction around my
> blobbing/deblobbing functionality?
> So that the "keyring" calls into the crypto driver to decrypt the data
> and uses the crypto driver to encrypt the keys when I want to "dump"
> them?

Definitely.   It sounds like you want the equivalent functionality as
the TPM based trusted keys using OTP on the CAAM.

>From Documentation/security/keys-trusted-encrypted.txt:

"Trusted Keys use a TPM both to generate and to seal the keys.  Keys are
sealed
under a 2048 bit RSA key in the TPM, and optionally sealed to specified
PCR
(integrity measurement) values, and only unsealed by the TPM, if PCRs
and blob
integrity verifications match."

Mimi

Re: [Linux-ima-user] [RFC] i.MX6 CAAM blob generator for IMA/EVM initialization

[Steffen T. <s.t...@pe...>]

Hi!

Mimi Zohar writes:

> On Mon, 2015-11-09 at 16:18 +0100, Steffen Trumtrar wrote:
>> Hi!
>> 
>> The RFC Patch attached after this cover letter is mostly for illustration
>> purposes, so please don't waste too much time reviewing the code ;-)
>> 
>> For context I'll try to describe the problem that this patch tries to solve.
>> 
>> I need to be able to boot an EVM signed (and dongled) rootfs. The CAAM on
>> the i.MX6 has support for an OTP key and can en/decrypt data.
>> It also has a feature for generating red blobs: basically a chunk of data,
>> that is encrypted with the OTP key, which can be saved on some medium as a
>> secret to decrypt the EVM HMAC secret for one specific device.
>> 
>> To open the rootfs, the secret is handed from the bootloader to the kernel
>> as a base64 encoded string via the cmdline to an initramfs.
>> In the initramfs the sysfs file "modifier" is set to something starting with
>> "kernel:evm" and the base64 string is written to the sysfs file "blob".
>> The CAAM than decodes the red blob and, in case of "kernel:evm", initializes
>> the EVM or otherwise writes the result to "payload" if the modifier starts
>> with "user:". Therefore a blob that was generated for EVM never leaves the
>> kernel on decryption.
>> Generation of blobs goes like: echoing "modifier" to something and echoing
>> the payload to "payload". The red blob can than be read from "blob".
>> 
>> 
>> So, the sysfs interface is not the best option, I guess. The question is:
>> What is the right approach for a setup like this?
>> I need to:
>>   - be able to encrypt the secret and store it somewhere
>>   - to load the stored secret and decrypt it later
>>   - initialize IMA/EVM with the secret
>> 
>> Would something like
>>   - security/keys/encrypted-keys/encrypted.c
>> be the correct approach?
>
> Instead of using the CAAM for OTP encrypting/decrypting, can it be used
> to load the EVM key directly?  Dmitry's patches, which will be
> upstreamed in 4.5
> https://git.kernel.org/cgit/linux/kernel/git/zohar/linux-integrity.git/log/?h=for-next-4.5?   adds support for a crypto device to directly load the EVM key.
>

The patches look good and I use them for loading the EVM key from the
CAAM driver. But I still need the OTP decryption functionality.

The key data that I hand to evm_set_key must be device specific but I
don't want to use the fused OTP in the CAAM directly.
The OTP is used to protect multiple random keys. Therefore I need to
generate encrypted blobs that I can store on some unsecure memory
(EEPROM, NAND,...) and be able to hand that later back to the CAAM
module, to then get back an IMA/EVM, ecryptfs, $something key.

> FYI, the EVM key is an encrypted key, which encrypts/decrypts either a
> trusted or user type key.
>
So the normal approach would be to have a key in the kernel keyring
and decrypt it with the key loaded with evm_set_key?

Can I somehow use the keyring framework as an abstraction around my
blobbing/deblobbing functionality?
So that the "keyring" calls into the crypto driver to decrypt the data
and uses the crypto driver to encrypt the keys when I want to "dump"
them?


Thanks,
Steffen

-- 
Pengutronix e.K.                           | Steffen Trumtrar            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |