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

Re: [Linux-ima-user] [PATCH] IMA: fix non-ANSI declaration of ima_check_policy()

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

On Wed, 2016-01-20 at 11:13 +0000, Colin King wrote:
> From: Colin Ian King <col...@ca...>
> 
> ima_check_policy() has no parameters, so use the normal void
> parameter convention to make it match the prototype in the header file
> security/integrity/ima/ima.h
> 
> Signed-off-by: Colin Ian King <col...@ca...>

Thank you.

Mimi

> ---
>  security/integrity/ima/ima_policy.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> index 0a3b781..e0e18cc 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -417,7 +417,7 @@ void __init ima_init_policy(void)
>  }
> 
>  /* Make sure we have a valid policy, at least containing some rules. */
> -int ima_check_policy()
> +int ima_check_policy(void)
>  {
>  	if (list_empty(&ima_temp_rules))
>  		return -EINVAL;

[Linux-ima-user] [PATCH] IMA: fix non-ANSI declaration of ima_check_policy()

[Colin K. <col...@ca...>]

From: Colin Ian King <col...@ca...>

ima_check_policy() has no parameters, so use the normal void
parameter convention to make it match the prototype in the header file
security/integrity/ima/ima.h

Signed-off-by: Colin Ian King <col...@ca...>
---
 security/integrity/ima/ima_policy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index 0a3b781..e0e18cc 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -417,7 +417,7 @@ void __init ima_init_policy(void)
 }
 
 /* Make sure we have a valid policy, at least containing some rules. */
-int ima_check_policy()
+int ima_check_policy(void)
 {
 	if (list_empty(&ima_temp_rules))
 		return -EINVAL;
-- 
2.7.0.rc3

Re: [Linux-ima-user] IMA appraisal with signature issue

[Baal Su <baa...@gm...>]

> On 12 Jan 2016, at 16:55, Mimi Zohar <zo...@li...> wrote:
> 
> On Tue, 2016-01-12 at 16:16 +0100, Baal Su wrote:
>>> On 12 Jan 2016, at 14:32, Mimi Zohar <zo...@li...> wrote:
>>> 
>>> On Tue, 2016-01-12 at 13:16 +0100, Baal Su wrote:
>>>>> On 11 Jan 2016, at 20:53, Mimi Zohar <zo...@li...> wrote:
>>>>> 
>>>>> On Mon, 2016-01-11 at 16:58 +0100, Baal Su wrote:
>>> 
>>>> But when I try to read this file, which belongs to another user whose
>>>> files are appraised, it still shows the same error as the following.
>>>> 
>>>> Following Mark’s suggestion, I try to show the keys belonging to the
>>>> keyring of global .ima, there is no key under it. 
>>> 
>>> If CONFIG_IMA_TRUSTED_KERYING is enabled, the IMA keyring name is .ima,
>>> otherwise it is _ima.
>> 
>> I checked the config file in the boot directory, the “CONFIG_IMA_TRUSTED_KEYRING” is enabled.
>> 
>> I tried to change the keyring from _ima to .ima, in this command:
>> 
>> 	ima_id=`keyctl newring .ima @u`
>> 
>> The result is:
>> 
>> 	add_key: Operation not permitted
> 
> Userspace can not create dot prefixed keyrings, only the kernel can
> create trusted keyrings.   Keys added to the .ima keyring need to be
> signed by a key on the system keyring.   There are a couple of ways of
> doing that:
> 
> - build your CA key into the kernel
> - On systems with RedHat's UEFI/MOK patches, Install your CA key into
> the UEFI MoK db
> - Mehmet Kalyaap posted a patch for reserving memory in the kernel for
> additional keys.  This patch has not yet been upstreamed.

Thank you Mimi, I will try these methods and let you know the results. 

Best wishes!
Tao

> 
> Mimi

Re: [Linux-ima-user] IMA appraisal with signature issue

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

On Tue, 2016-01-12 at 16:16 +0100, Baal Su wrote:
> > On 12 Jan 2016, at 14:32, Mimi Zohar <zo...@li...> wrote:
> > 
> > On Tue, 2016-01-12 at 13:16 +0100, Baal Su wrote:
> >>> On 11 Jan 2016, at 20:53, Mimi Zohar <zo...@li...> wrote:
> >>> 
> >>> On Mon, 2016-01-11 at 16:58 +0100, Baal Su wrote:
> > 
> >> But when I try to read this file, which belongs to another user whose
> >> files are appraised, it still shows the same error as the following.
> >> 
> >> Following Mark’s suggestion, I try to show the keys belonging to the
> >> keyring of global .ima, there is no key under it. 
> > 
> > If CONFIG_IMA_TRUSTED_KERYING is enabled, the IMA keyring name is .ima,
> > otherwise it is _ima.
> 
> I checked the config file in the boot directory, the “CONFIG_IMA_TRUSTED_KEYRING” is enabled.
> 
> I tried to change the keyring from _ima to .ima, in this command:
> 
> 	ima_id=`keyctl newring .ima @u`
> 
> The result is:
> 
> 	add_key: Operation not permitted

Userspace can not create dot prefixed keyrings, only the kernel can
create trusted keyrings.   Keys added to the .ima keyring need to be
signed by a key on the system keyring.   There are a couple of ways of
doing that:

- build your CA key into the kernel
- On systems with RedHat's UEFI/MOK patches, Install your CA key into
the UEFI MoK db
- Mehmet Kalyaap posted a patch for reserving memory in the kernel for
additional keys.  This patch has not yet been upstreamed.

Mimi

Re: [Linux-ima-user] Root can always modify xattrs

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

On Thu, 2015-12-24 at 15:13 -0500, Mimi Zohar wrote:
> On Thu, 2015-12-24 at 15:06 -0500, Kevin Sullivan wrote:
> > On Tue, Dec 22, 2015 at 2:05 PM, Mimi Zohar <zo...@li...>
> > wrote:
> > 
> > > On Tue, 2015-12-22 at 08:56 -0500, Kevin Sullivan wrote:
> > > > Is there a way to prevent the root user from modifying the `security.ima`
> > > > extended attribute on files?
> > > >
> > > > I am attempting to setup an IMA policy that only measures and appraises
> > > > executables. I am able to do this by adding the following to my policy:
> > > >
> > > >     measure func=BPRM_CHECK mask=MAY_EXEC
> > > >     measure func=FILE_MMAP       mask=MAY_EXEC
> > > >
> > > >     appraise func=BPRM_CHECK mask=MAY_EXEC
> > > >     appraise func=FILE_MMAP       mask=MAY_EXEC
> > > >
> > > >     dont_appraise func=FILE_CHECK
> > > >
> > > > However, I am noticing that the root user can always change the value of
> > > > the `security.ima` extended attribute for any file, even when I'm not in
> > > > `ima_appraise=fix` mode. For example, I can successfully run:
> > > >
> > > >     # setfattr -n 'security.ima' -v 'FOO' /path/to/file
> > > >
> > > > Is there something that I can put in my policy to prevent the changing of
> > > > extended attributes? I am not using EVM or SELinux, would these help?
> > > >
> > > > I am running a 3.10 kernel on RHEL7.
> > >
> > > Yes, if the xattr contains a file signature, then the file is considered
> > > "immutable" and is prevented from being modified.   Commit c68ed80 "ima:
> > > limit file hash setting by user to fix and log modes" added this
> > > support.  Unfortunately, this commit is relatively recent and appears in
> > > more recent kernels.
> > >

I stand corrected.  Patrick Callaghan, a colleague, pointed it out.
That patch prevents writing a hash to security.ima, not a signature.  We
need the ability to write file signatures in order to label the file
system.  I have a patch somewhere that prevents writing security.ima if
it already has a signature.  I need to dig it out. 

Mimi

> > >
> > >
> > Thank you for the prompt response Mimi! This is exactly what I was looking
> > for.
> > 
> > Just to be clear, by 'file signature', do you mean a hash or digital
> > signature?
> 
> When security.ima is a file signature, as generated by evmctl, even root
> can not modify the xattr.
> 
> > Also, it looks like RHEL 7 doesn't have a kernel that has incorporated this
> > commit, so I am out of luck for now.
> > 
> > Thank you!
> 
> You're welcome. 
> 
> Mimi
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Linux-ima-user mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-ima-user
> 

Re: [Linux-ima-user] IMA appraisal with signature issue

[Baal Su <baa...@gm...>]

> On 12 Jan 2016, at 14:32, Mimi Zohar <zo...@li...> wrote:
> 
> On Tue, 2016-01-12 at 13:16 +0100, Baal Su wrote:
>>> On 11 Jan 2016, at 20:53, Mimi Zohar <zo...@li...> wrote:
>>> 
>>> On Mon, 2016-01-11 at 16:58 +0100, Baal Su wrote:
> 
>> But when I try to read this file, which belongs to another user whose
>> files are appraised, it still shows the same error as the following.
>> 
>> Following Mark’s suggestion, I try to show the keys belonging to the
>> keyring of global .ima, there is no key under it. 
> 
> If CONFIG_IMA_TRUSTED_KERYING is enabled, the IMA keyring name is .ima,
> otherwise it is _ima.

I checked the config file in the boot directory, the “CONFIG_IMA_TRUSTED_KEYRING” is enabled.

I tried to change the keyring from _ima to .ima, in this command:

	ima_id=`keyctl newring .ima @u`

The result is:

	add_key: Operation not permitted

> 
>>>> 
>>>> 	But when I want to read from a file under appraisal with enforce mode, it still shows:
>>>> 
>>>> 		[   358.334856] digsig: key not found, id: 821C0DFD4C617DA
>>>> 		cat: file: Permission denied
>>> 
>>> Only asymmetric keys should be on the IMA keyring, not user.
>> 
>> I follow the instructions in the wiki page
>> <http://sourceforge.net/p/linux-ima/wiki/Home/#imaevm-keyrings-loading-the-public-keys> to load the public keys, but instead of x509 certificate, I just use the RSA key pairs. 
> 
> Why don't you follow the directions first, before making changes, and
> see if that works.   You'll need the ima-evm-utils package.

I already use the latest ima-evm-utils package compiled from source code, and use the script in the example directory to create the RSA key pairs. But it does not work following the instructions in the wiki page. 

Here are the commands I used just in case there are some steps which are wrong:

	git clone git://git.code.sf.net/p/linux-ima/ima-evm-utils <git://git.code.sf.net/p/linux-ima/ima-evm-utils>
	cd ima-evm-utils
	build the source code with the steps on the wiki page

	cd examples
	./ima-genkey-self.sh 
	cp privkey_evm.pem /etc/keys/
	cp pubkey_evm.pem /etc/keys/

	ima_id=`keyctl newring _ima @u`
	evmctl import --rsa /etc/keys/pubkey_evm.pem $ima_id
	evmctl ima_sign —rsa file -v 
	evmctl ima_verify —rsa file -v 

Until this step, I can see the verification is OK. Then I change the owner of this file to user ‘temp’, whose file is set to be appraised with ima-policy. But then I try to read the content of the file with cat, the permission is denied with:
	
	[   358.334856] digsig: key not found, id: 821C0DFD4C617DA
	cat: file: Permission denied

Please let me know if there are some commands are not correct or there are some missing steps. 

Thank you very much for your time and best wishes!
Tao

> 
> Mimi
> 

Re: [Linux-ima-user] IMA appraisal with signature issue

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

On Tue, 2016-01-12 at 13:16 +0100, Baal Su wrote:
> > On 11 Jan 2016, at 20:53, Mimi Zohar <zo...@li...> wrote:
> > 
> > On Mon, 2016-01-11 at 16:58 +0100, Baal Su wrote:

> But when I try to read this file, which belongs to another user whose
> files are appraised, it still shows the same error as the following.
> 
> Following Mark’s suggestion, I try to show the keys belonging to the
> keyring of global .ima, there is no key under it. 

If CONFIG_IMA_TRUSTED_KERYING is enabled, the IMA keyring name is .ima,
otherwise it is _ima.

> >> 
> >> 	But when I want to read from a file under appraisal with enforce mode, it still shows:
> >> 
> >> 		[   358.334856] digsig: key not found, id: 821C0DFD4C617DA
> >> 		cat: file: Permission denied
> > 
> > Only asymmetric keys should be on the IMA keyring, not user.
> 
> I follow the instructions in the wiki page
> <http://sourceforge.net/p/linux-ima/wiki/Home/#imaevm-keyrings-loading-the-public-keys> to load the public keys, but instead of x509 certificate, I just use the RSA key pairs. 

Why don't you follow the directions first, before making changes, and
see if that works.   You'll need the ima-evm-utils package.

Mimi

Re: [Linux-ima-user] IMA appraisal with signature issue

[Baal Su <baa...@gm...>]

> On 11 Jan 2016, at 20:53, Mimi Zohar <zo...@li...> wrote:
> 
> On Mon, 2016-01-11 at 16:58 +0100, Baal Su wrote:
> 
>> Hi Mimi,
>> 
>> 	Thank you for your reply. 
>> 
>> 	I tried to recompile the kernel to 4.1.15, which is the latest longterm version. But the aforementioned problem still exists. 
>> 
>> 	When I run “keyctl show”, I can see the following output:
>> 		
>> 		Session Keyring
>> 		841881916   —alswrv	0	   0  keyring: _ses
>> 		1060565120 —alswrv	0 65534   \_ keyring: _uid.0
>> 		332490404   —alswrv 	0	   0		\_ keyring: _ima
>> 		452725264   —alswrv	0	   0		\_ user: 821C0DFD4C617DA
> 
> It doesn't looke like there are any keys on the _ima keyring.  Try
> listing the keys on the keyring:   keyctl list `keyctl search @u keyring
> _ima`
> 

Hi Mimi and Mark, 

There is a mistake in the previous output, the correct one is the following:
	
	Session Keyring
	841881916	—alswrv	0	   0  	keyring: _ses
	1060565120 	—alswrv	0 	65534	\_ keyring: _uid.0
	332490404   	—alswrv 	0	   0			\_ keyring: _ima
	452725264   	—alswrv	0	   0				\_ user: 821C0DFD4C617DA

The ‘\_user:821C0DFD4C617DA' is the sub level of the keyring _ima. When I list the keys on the keyring, I can see the following output:
	
	1 key in keyring:
	6747479103	—alswrv 	0	0	user: 821C0DFD4C617DA

But when I try to read this file, which belongs to another user whose files are appraised, it still shows the same error as the following.

Following Mark’s suggestion, I try to show the keys belonging to the keyring of global .ima, there is no key under it. 

> 
>> 
>> 	But when I want to read from a file under appraisal with enforce mode, it still shows:
>> 
>> 		[   358.334856] digsig: key not found, id: 821C0DFD4C617DA
>> 		cat: file: Permission denied
> 
> Only asymmetric keys should be on the IMA keyring, not user.

I follow the instructions in the wiki page <http://sourceforge.net/p/linux-ima/wiki/Home/#imaevm-keyrings-loading-the-public-keys> to load the public keys, but instead of x509 certificate, I just use the RSA key pairs. 

Is there any change in the new version of the code? Because when I tried to load the public key, if I omit the ‘—rsa’ option, it will show 'd2i_x509_fp() failed', but it is not mentioned in the wiki.

Please let me know if you have some idea why this error happens.

Thank you very much for your time and best wishes!
Tao

> 
> Mimi 
> 
>> 	Should I try with more recent kernel?
>> 
>> Thank you for your time and best wishes!
> 

Re: [Linux-ima-user] IMA appraisal with signature issue

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

On Mon, 2016-01-11 at 16:58 +0100, Baal Su wrote:

> Hi Mimi,
> 
> 	Thank you for your reply. 
> 
> 	I tried to recompile the kernel to 4.1.15, which is the latest longterm version. But the aforementioned problem still exists. 
> 
> 	When I run “keyctl show”, I can see the following output:
> 		
> 		Session Keyring
> 		841881916   —alswrv	0	   0  keyring: _ses
> 		1060565120 —alswrv	0 65534   \_ keyring: _uid.0
> 		332490404   —alswrv 	0	   0		\_ keyring: _ima
> 		452725264   —alswrv	0	   0		\_ user: 821C0DFD4C617DA

It doesn't looke like there are any keys on the _ima keyring.  Try
listing the keys on the keyring:   keyctl list `keyctl search @u keyring
_ima`

> 
> 	But when I want to read from a file under appraisal with enforce mode, it still shows:
> 
> 		[   358.334856] digsig: key not found, id: 821C0DFD4C617DA
> 		cat: file: Permission denied

Only asymmetric keys should be on the IMA keyring, not user.

Mimi 

> 	Should I try with more recent kernel?
> 
> Thank you for your time and best wishes!

Re: [Linux-ima-user] IMA appraisal with signature issue

[Mark D. B. <md...@ju...>]

Hi Baal,

...elided...
>	When I run “keyctl show”, I can see the following output:
...elided...

You may wish to consider

    keyctl show %keyring:.ima

to look at the global .ima keyring rather than the _ima local user
keyring.

You could also dump all keyring information at once by doing

    cat /proc/keys

(if you have compiled your kernel with CONFIG_KEYS=y)

	-- Mark

Re: [Linux-ima-user] IMA appraisal with signature issue

[Baal Su <baa...@gm...>]

> On 23 Dec 2015, at 21:35, Mimi Zohar <zo...@li...> wrote:
> 
> On Wed, 2015-12-23 at 20:02 +0100, Tao wrote:
>> Hi Mimi,
>> 
>>     Thank you very much for your reply.
>> 
>>     My answers are in-line.
>> 
>>     Another issue, when I open the file with vi or vim and make some 
>> modifications of the file,
>> the security.ima attribute will disappear. But when I use nano to edit 
>> the file, the value of
>> security.ima will be updated. I am not sure if this is another issue.
> 
> "vi" doesn't edit the existing file, but creates a new file.  Look at
> the inode (stat  <pathname>) associated with the file before and after
> using "vi".
> 
> (Your email is still mangled.)
> 
>>>>                  But after I change the ownership of the file to user
>>>> ‘temp’ whose file is set to be appraised, and try to run the same
>>>> ima_verify again, it gives error with the following message:
>>>> 
>>>> [8621.067731]digsig: key not found, id:DE253B20DFD8E3
>>> Probably "_ima" is not on root's keyring.
>> It should be, because when I execute 'keyctl show', I can see _ima as a 
>> sub keyring of keyring:_uid.0
>> but the system still show that :
>> 
>> digsig: key not found, id:DE253B20DFD8E3
>> 
>> Any other thoughts?
> 
> The keyid lookup was broken and fixed twice.  Perhaps one of these
> commits were backported to RHEL 7 without the corresponding fixes.
> 
> - Commit 46963b7 "KEYS: Overhaul key identification when searching for
> asymmetric  keys" broke the keyid lookup.  Commit   f1b731d "KEYS:
> Restore partial ID matching functionality for asymmetric keys" fixed it.
> 
> - Commit 46963b774d44 "KEYS: Overhaul key identification when searching
> for asymmetric keys" broke the keyid lookup.   Commit f2b3dee "KEYS: fix
> "ca_keys=" partial key matching" fixed it.
> 

Hi Mimi,

	Thank you for your reply. 

	I tried to recompile the kernel to 4.1.15, which is the latest longterm version. But the aforementioned problem still exists. 

	When I run “keyctl show”, I can see the following output:
		
		Session Keyring
		841881916   —alswrv	0	   0  keyring: _ses
		1060565120 —alswrv	0 65534   \_ keyring: _uid.0
		332490404   —alswrv 	0	   0		\_ keyring: _ima
		452725264   —alswrv	0	   0		\_ user: 821C0DFD4C617DA

	But when I want to read from a file under appraisal with enforce mode, it still shows:

		[   358.334856] digsig: key not found, id: 821C0DFD4C617DA
		cat: file: Permission denied

	Should I try with more recent kernel?

Thank you for your time and best wishes!
Tao
> Mimi
> 

Re: [Linux-ima-user] Root can always modify xattrs

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

On Thu, 2015-12-24 at 15:06 -0500, Kevin Sullivan wrote:
> On Tue, Dec 22, 2015 at 2:05 PM, Mimi Zohar <zo...@li...>
> wrote:
> 
> > On Tue, 2015-12-22 at 08:56 -0500, Kevin Sullivan wrote:
> > > Is there a way to prevent the root user from modifying the `security.ima`
> > > extended attribute on files?
> > >
> > > I am attempting to setup an IMA policy that only measures and appraises
> > > executables. I am able to do this by adding the following to my policy:
> > >
> > >     measure func=BPRM_CHECK mask=MAY_EXEC
> > >     measure func=FILE_MMAP       mask=MAY_EXEC
> > >
> > >     appraise func=BPRM_CHECK mask=MAY_EXEC
> > >     appraise func=FILE_MMAP       mask=MAY_EXEC
> > >
> > >     dont_appraise func=FILE_CHECK
> > >
> > > However, I am noticing that the root user can always change the value of
> > > the `security.ima` extended attribute for any file, even when I'm not in
> > > `ima_appraise=fix` mode. For example, I can successfully run:
> > >
> > >     # setfattr -n 'security.ima' -v 'FOO' /path/to/file
> > >
> > > Is there something that I can put in my policy to prevent the changing of
> > > extended attributes? I am not using EVM or SELinux, would these help?
> > >
> > > I am running a 3.10 kernel on RHEL7.
> >
> > Yes, if the xattr contains a file signature, then the file is considered
> > "immutable" and is prevented from being modified.   Commit c68ed80 "ima:
> > limit file hash setting by user to fix and log modes" added this
> > support.  Unfortunately, this commit is relatively recent and appears in
> > more recent kernels.
> >
> > Mimi
> >
> >
> Thank you for the prompt response Mimi! This is exactly what I was looking
> for.
> 
> Just to be clear, by 'file signature', do you mean a hash or digital
> signature?

When security.ima is a file signature, as generated by evmctl, even root
can not modify the xattr.

> Also, it looks like RHEL 7 doesn't have a kernel that has incorporated this
> commit, so I am out of luck for now.
> 
> Thank you!

You're welcome. 

Mimi

Re: [Linux-ima-user] Root can always modify xattrs

[Kevin S. <kev...@gm...>]

On Tue, Dec 22, 2015 at 2:05 PM, Mimi Zohar <zo...@li...>
wrote:

> On Tue, 2015-12-22 at 08:56 -0500, Kevin Sullivan wrote:
> > Is there a way to prevent the root user from modifying the `security.ima`
> > extended attribute on files?
> >
> > I am attempting to setup an IMA policy that only measures and appraises
> > executables. I am able to do this by adding the following to my policy:
> >
> >     measure func=BPRM_CHECK mask=MAY_EXEC
> >     measure func=FILE_MMAP       mask=MAY_EXEC
> >
> >     appraise func=BPRM_CHECK mask=MAY_EXEC
> >     appraise func=FILE_MMAP       mask=MAY_EXEC
> >
> >     dont_appraise func=FILE_CHECK
> >
> > However, I am noticing that the root user can always change the value of
> > the `security.ima` extended attribute for any file, even when I'm not in
> > `ima_appraise=fix` mode. For example, I can successfully run:
> >
> >     # setfattr -n 'security.ima' -v 'FOO' /path/to/file
> >
> > Is there something that I can put in my policy to prevent the changing of
> > extended attributes? I am not using EVM or SELinux, would these help?
> >
> > I am running a 3.10 kernel on RHEL7.
>
> Yes, if the xattr contains a file signature, then the file is considered
> "immutable" and is prevented from being modified.   Commit c68ed80 "ima:
> limit file hash setting by user to fix and log modes" added this
> support.  Unfortunately, this commit is relatively recent and appears in
> more recent kernels.
>
> Mimi
>
>
Thank you for the prompt response Mimi! This is exactly what I was looking
for.

Just to be clear, by 'file signature', do you mean a hash or digital
signature?

Also, it looks like RHEL 7 doesn't have a kernel that has incorporated this
commit, so I am out of luck for now.

Thank you!

Kevin

Re: [Linux-ima-user] IMA appraisal with signature issue

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

On Wed, 2015-12-23 at 20:02 +0100, Tao wrote:
> Hi Mimi,
> 
>      Thank you very much for your reply.
> 
>      My answers are in-line.
> 
>      Another issue, when I open the file with vi or vim and make some 
> modifications of the file,
> the security.ima attribute will disappear. But when I use nano to edit 
> the file, the value of
> security.ima will be updated. I am not sure if this is another issue.

"vi" doesn't edit the existing file, but creates a new file.  Look at
the inode (stat  <pathname>) associated with the file before and after
using "vi".

(Your email is still mangled.)

> >>                   But after I change the ownership of the file to user
> >> ‘temp’ whose file is set to be appraised, and try to run the same
> >> ima_verify again, it gives error with the following message:
> >>
> >> [8621.067731]digsig: key not found, id:DE253B20DFD8E3
> > Probably "_ima" is not on root's keyring.
> It should be, because when I execute 'keyctl show', I can see _ima as a 
> sub keyring of keyring:_uid.0
> but the system still show that :
> 
> digsig: key not found, id:DE253B20DFD8E3
> 
> Any other thoughts?

The keyid lookup was broken and fixed twice.  Perhaps one of these
commits were backported to RHEL 7 without the corresponding fixes.

- Commit 46963b7 "KEYS: Overhaul key identification when searching for
asymmetric  keys" broke the keyid lookup.  Commit   f1b731d "KEYS:
Restore partial ID matching functionality for asymmetric keys" fixed it.

- Commit 46963b774d44 "KEYS: Overhaul key identification when searching
for asymmetric keys" broke the keyid lookup.   Commit f2b3dee "KEYS: fix
"ca_keys=" partial key matching" fixed it.

Mimi

Re: [Linux-ima-user] IMA appraisal with signature issue

[Tao <baa...@gm...>]

Hi Mimi,

     Thank you very much for your reply.

     My answers are in-line.

     Another issue, when I open the file with vi or vim and make some 
modifications of the file,
the security.ima attribute will disappear. But when I use nano to edit 
the file, the value of
security.ima will be updated. I am not sure if this is another issue.

Best wishes!
Tao

On 12/23/2015 6:50 PM, Mimi Zohar wrote:
> On Wed, 2015-12-23 at 17:28 +0100, Tao wrote:
>> Hi,
>>
>> I am trying the IMA appraisal function on a CentOS7 minimal installation
>> machine. By default, thisdistribution ships with compiled kernel
>> supports IMA functions. Kernel version is 3.10.0.
>>
>> I followed the instructions on the following two web pages.
>>
>> http://sourceforge.net/p/linux-ima/wiki/Home/
>>
>> https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture
>>
>> It works fine with the measurement functions and IMA appraisal without
>> digital signatures. I activated i_version flag in the root filesystem in
>> the boot command line and change the mount option in /etc/fstab file.
>>
>> Since right now I am just testing the capability of the IMA, I set a
>> custom policy only to appraise the file belonging to a user named “temp”
>> and add "ima_appraise=enforce" in the boot command line.
>>
>> Then I use ‘evmctl ima_hash file’ and it works fine. I can see
>> security.ima extended attribute with ‘getfattr’ command. And after I
>> change the owner of the file to temp, I can still open it and execute it.
> Does the reverse also work, meaning if a file owned by temp isn't
> signed, can you execute it?
if the file's hash is correct, but it is not signed, it can still be 
executed. As I understand, the
'ima_hash' function only computes the hash value of the file, and store 
it in the security.ima
attribute, so if the security.ima attribute is not signature based, the 
appraise will succeed, and
then it should be able to be executed.
>> The problem is with the ima_sign function provided by evmctl. Following
>> the instructions, I create a new keyring in the system by launching the
>> following commands:
>>
>> openssl  genrsa  -outprivkey_evm.pem  1024
>>
>> openssl  rsa  -pubout  -inprivkey_evm.pem  -outpubkey_evm.pem
>>
>> ima_id=`keyctl  newring  _ima  @u`
> Try logging in as root or "su - ", not using "sudo" to create the "_ima"
> keyring.
I always login as root, since I am just testing in a virtual machine, 
with the root account, it
is more convenient.
>
>> evmctl  import --rsa  /etc/keys/pubkey_evm.pem  $ima_id
>>
>> evmctl  ima_sign  –rsa  file –v
>>
>> Until this point, I can see the hash value, the keyed, sighash and
>> evm/ima signature. And I also can see the security.ima attribute is
>> becoming 274 bytes long.
>>
>> Then I launch:
>>
>>
>> evmctl  ima_verify  –rsa  file –v
>>
>> and I can see the hash is correct and sighash is the same one shown with
>> the above command. And the verification is OK.
>>
>>
>>                   But after I change the ownership of the file to user
>> ‘temp’ whose file is set to be appraised, and try to run the same
>> ima_verify again, it gives error with the following message:
>>
>> [8621.067731]digsig: key not found, id:DE253B20DFD8E3
> Probably "_ima" is not on root's keyring.
It should be, because when I execute 'keyctl show', I can see _ima as a 
sub keyring of keyring:_uid.0
but the system still show that :

digsig: key not found, id:DE253B20DFD8E3

Any other thoughts?

>
> Mimi
>
>> Fail to open: file
>>
>> Errno: Permission denied (13)
>>
>>
>>                   with 'keyctl show' command, I can see the
>> sub-attributes of keyring: _uid.0, named _ima and DE253B20DFD8E3.
>>
>>
>> Can any one enlighten me what is the possible error? I followed exactly
>> the procedure described in the wiki page. Or if there is something changed?
>>
>>
>> Thank you very much for your time and best wishes!
>

Re: [Linux-ima-user] IMA appraisal with signature issue

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

On Wed, 2015-12-23 at 17:28 +0100, Tao wrote:
> Hi,
> 
> I am trying the IMA appraisal function on a CentOS7 minimal installation 
> machine. By default, thisdistribution ships with compiled kernel 
> supports IMA functions. Kernel version is 3.10.0.
> 
> I followed the instructions on the following two web pages.
> 
> http://sourceforge.net/p/linux-ima/wiki/Home/
> 
> https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture
> 
> It works fine with the measurement functions and IMA appraisal without 
> digital signatures. I activated i_version flag in the root filesystem in 
> the boot command line and change the mount option in /etc/fstab file.
> 
> Since right now I am just testing the capability of the IMA, I set a 
> custom policy only to appraise the file belonging to a user named “temp” 
> and add "ima_appraise=enforce" in the boot command line.
> 
> Then I use ‘evmctl ima_hash file’ and it works fine. I can see 
> security.ima extended attribute with ‘getfattr’ command. And after I 
> change the owner of the file to temp, I can still open it and execute it.

Does the reverse also work, meaning if a file owned by temp isn't
signed, can you execute it?

> The problem is with the ima_sign function provided by evmctl. Following 
> the instructions, I create a new keyring in the system by launching the 
> following commands:
> 
> openssl  genrsa  -outprivkey_evm.pem  1024
> 
> openssl  rsa  -pubout  -inprivkey_evm.pem  -outpubkey_evm.pem
> 
> ima_id=`keyctl  newring  _ima  @u`

Try logging in as root or "su - ", not using "sudo" to create the "_ima"
keyring.

> evmctl  import --rsa  /etc/keys/pubkey_evm.pem  $ima_id
> 
> evmctl  ima_sign  –rsa  file –v
> 
> Until this point, I can see the hash value, the keyed, sighash and 
> evm/ima signature. And I also can see the security.ima attribute is 
> becoming 274 bytes long.
> 
> Then I launch:
> 
> 
> evmctl  ima_verify  –rsa  file –v
> 
> and I can see the hash is correct and sighash is the same one shown with 
> the above command. And the verification is OK.
> 
> 
>                  But after I change the ownership of the file to user 
> ‘temp’ whose file is set to be appraised, and try to run the same 
> ima_verify again, it gives error with the following message:
> 
> [8621.067731]digsig: key not found, id:DE253B20DFD8E3

Probably "_ima" is not on root's keyring.

Mimi

> Fail to open: file
> 
> Errno: Permission denied (13)
> 
> 
>                  with 'keyctl show' command, I can see the 
> sub-attributes of keyring: _uid.0, named _ima and DE253B20DFD8E3.
> 
> 
> Can any one enlighten me what is the possible error? I followed exactly 
> the procedure described in the wiki page. Or if there is something changed?
> 
> 
> Thank you very much for your time and best wishes!

[Linux-ima-user] IMA appraisal with signature issue

[Tao <baa...@gm...>]

Hi,

I am trying the IMA appraisal function on a CentOS7 minimal installation 
machine. By default, thisdistribution ships with compiled kernel 
supports IMA functions. Kernel version is 3.10.0.

I followed the instructions on the following two web pages.

http://sourceforge.net/p/linux-ima/wiki/Home/

https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture

It works fine with the measurement functions and IMA appraisal without 
digital signatures. I activated i_version flag in the root filesystem in 
the boot command line and change the mount option in /etc/fstab file.

Since right now I am just testing the capability of the IMA, I set a 
custom policy only to appraise the file belonging to a user named “temp” 
and add "ima_appraise=enforce" in the boot command line.

Then I use ‘evmctl ima_hash file’ and it works fine. I can see 
security.ima extended attribute with ‘getfattr’ command. And after I 
change the owner of the file to temp, I can still open it and execute it.

The problem is with the ima_sign function provided by evmctl. Following 
the instructions, I create a new keyring in the system by launching the 
following commands:

openssl  genrsa  -outprivkey_evm.pem  1024

openssl  rsa  -pubout  -inprivkey_evm.pem  -outpubkey_evm.pem

ima_id=`keyctl  newring  _ima  @u`

evmctl  import --rsa  /etc/keys/pubkey_evm.pem  $ima_id

evmctl  ima_sign  –rsa  file –v

Until this point, I can see the hash value, the keyed, sighash and 
evm/ima signature. And I also can see the security.ima attribute is 
becoming 274 bytes long.

Then I launch:


evmctl  ima_verify  –rsa  file –v

and I can see the hash is correct and sighash is the same one shown with 
the above command. And the verification is OK.


                 But after I change the ownership of the file to user 
‘temp’ whose file is set to be appraised, and try to run the same 
ima_verify again, it gives error with the following message:

[8621.067731]digsig: key not found, id:DE253B20DFD8E3

Fail to open: file

Errno: Permission denied (13)


                 with 'keyctl show' command, I can see the 
sub-attributes of keyring: _uid.0, named _ima and DE253B20DFD8E3.


Can any one enlighten me what is the possible error? I followed exactly 
the procedure described in the wiki page. Or if there is something changed?


Thank you very much for your time and best wishes!
Tao

Re: [Linux-ima-user] Root can always modify xattrs

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

On Tue, 2015-12-22 at 08:56 -0500, Kevin Sullivan wrote:
> Is there a way to prevent the root user from modifying the `security.ima`
> extended attribute on files?
> 
> I am attempting to setup an IMA policy that only measures and appraises
> executables. I am able to do this by adding the following to my policy:
> 
>     measure func=BPRM_CHECK mask=MAY_EXEC
>     measure func=FILE_MMAP       mask=MAY_EXEC
> 
>     appraise func=BPRM_CHECK mask=MAY_EXEC
>     appraise func=FILE_MMAP       mask=MAY_EXEC
> 
>     dont_appraise func=FILE_CHECK
> 
> However, I am noticing that the root user can always change the value of
> the `security.ima` extended attribute for any file, even when I'm not in
> `ima_appraise=fix` mode. For example, I can successfully run:
> 
>     # setfattr -n 'security.ima' -v 'FOO' /path/to/file
> 
> Is there something that I can put in my policy to prevent the changing of
> extended attributes? I am not using EVM or SELinux, would these help?
> 
> I am running a 3.10 kernel on RHEL7.

Yes, if the xattr contains a file signature, then the file is considered
"immutable" and is prevented from being modified.   Commit c68ed80 "ima:
limit file hash setting by user to fix and log modes" added this
support.  Unfortunately, this commit is relatively recent and appears in
more recent kernels.

Mimi

[Linux-ima-user] Root can always modify xattrs

[Kevin S. <kev...@gm...>]

Is there a way to prevent the root user from modifying the `security.ima`
extended attribute on files?

I am attempting to setup an IMA policy that only measures and appraises
executables. I am able to do this by adding the following to my policy:

    measure func=BPRM_CHECK mask=MAY_EXEC
    measure func=FILE_MMAP       mask=MAY_EXEC

    appraise func=BPRM_CHECK mask=MAY_EXEC
    appraise func=FILE_MMAP       mask=MAY_EXEC

    dont_appraise func=FILE_CHECK

However, I am noticing that the root user can always change the value of
the `security.ima` extended attribute for any file, even when I'm not in
`ima_appraise=fix` mode. For example, I can successfully run:

    # setfattr -n 'security.ima' -v 'FOO' /path/to/file

Is there something that I can put in my policy to prevent the changing of
extended attributes? I am not using EVM or SELinux, would these help?

I am running a 3.10 kernel on RHEL7.

Thanks,

Kevin

Re: [Linux-ima-user] [PATCH 2/2] security/integrity: make ima/ima_mok.c explicitly non-modular

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

On Wed, 2015-12-09 at 17:37 -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
> 
> ima/Kconfig:config IMA_MOK_KEYRING
> ima/Kconfig: bool "Create IMA machine owner keys (MOK) and blacklist keyrings"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> Lets remove the couple of traces of modularity so that when reading the
> driver there is no doubt it really is builtin-only.
> 
> Since module_init translates to device_initcall in the non-modular
> case, the init ordering remains unchanged with this commit.
> 
> Cc: Mimi Zohar <zo...@li...>
> Cc: Dmitry Kasatkin <dmi...@gm...>
> Cc: James Morris <jam...@or...>
> Cc: "Serge E. Hallyn" <se...@ha...>
> Cc: lin...@li...
> Cc: lin...@li...
> Cc: lin...@vg...
> Signed-off-by: Paul Gortmaker <pau...@wi...>

Thanks, this patch is queued to be upstreamed with the original ima_mok
keyring patch.

Mimi

> ---
>  security/integrity/ima/ima_mok.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/security/integrity/ima/ima_mok.c b/security/integrity/ima/ima_mok.c
> index 8dad9a2b8e47..676885e4320e 100644
> --- a/security/integrity/ima/ima_mok.c
> +++ b/security/integrity/ima/ima_mok.c
> @@ -16,7 +16,7 @@
>  #include <linux/sched.h>
>  #include <linux/cred.h>
>  #include <linux/err.h>
> -#include <linux/module.h>
> +#include <linux/init.h>
>  #include <keys/asymmetric-type.h>
> 
> 
> @@ -52,5 +52,4 @@ __init int ima_mok_init(void)
>  	set_bit(KEY_FLAG_KEEP, &ima_blacklist_keyring->flags);
>  	return 0;
>  }
> -
> -module_init(ima_mok_init);
> +device_initcall(ima_mok_init);

Re: [Linux-ima-user] [PATCH 0/2] security: clarify that some code is really non-modular

[David H. <dho...@re...>]

Paul Gortmaker <pau...@wi...> wrote:

> Paul Gortmaker (2):
>   security/keys: make big_key.c explicitly non-modular
>   security/integrity: make ima/ima_mok.c explicitly non-modular

Note that I only see patch 1.  Note also that key...@li... should
now be key...@vg....

David

[Linux-ima-user] [PATCH 2/2] security/integrity: make ima/ima_mok.c explicitly non-modular

[Paul G. <pau...@wi...>]

The Kconfig currently controlling compilation of this code is:

ima/Kconfig:config IMA_MOK_KEYRING
ima/Kconfig: bool "Create IMA machine owner keys (MOK) and blacklist keyrings"

...meaning that it currently is not being built as a module by anyone.

Lets remove the couple of traces of modularity so that when reading the
driver there is no doubt it really is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

Cc: Mimi Zohar <zo...@li...>
Cc: Dmitry Kasatkin <dmi...@gm...>
Cc: James Morris <jam...@or...>
Cc: "Serge E. Hallyn" <se...@ha...>
Cc: lin...@li...
Cc: lin...@li...
Cc: lin...@vg...
Signed-off-by: Paul Gortmaker <pau...@wi...>
---
 security/integrity/ima/ima_mok.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/security/integrity/ima/ima_mok.c b/security/integrity/ima/ima_mok.c
index 8dad9a2b8e47..676885e4320e 100644
--- a/security/integrity/ima/ima_mok.c
+++ b/security/integrity/ima/ima_mok.c
@@ -16,7 +16,7 @@
 #include <linux/sched.h>
 #include <linux/cred.h>
 #include <linux/err.h>
-#include <linux/module.h>
+#include <linux/init.h>
 #include <keys/asymmetric-type.h>
 
 
@@ -52,5 +52,4 @@ __init int ima_mok_init(void)
 	set_bit(KEY_FLAG_KEEP, &ima_blacklist_keyring->flags);
 	return 0;
 }
-
-module_init(ima_mok_init);
+device_initcall(ima_mok_init);
-- 
2.6.1

[Linux-ima-user] [PATCH 0/2] security: clarify that some code is really non-modular

[Paul G. <pau...@wi...>]

The goal is to ensure that non-modular code doesn't appear modular
just by accident.  Here we have two more commits to do that and they
are of the trivial nature (i.e. no ".remove" functions deleted and
no need to block any unbind actions).  We just change the
registration functions to be the non modular versions and adjust
the include headers to match.

Paul Gortmaker (2):
  security/keys: make big_key.c explicitly non-modular
  security/integrity: make ima/ima_mok.c explicitly non-modular

 security/integrity/ima/ima_mok.c |  5 ++---
 security/keys/big_key.c          | 15 +--------------
 2 files changed, 3 insertions(+), 17 deletions(-)

---

Cc: David Howells <dho...@re...>
Cc: James Morris <jam...@or...>
Cc: "Serge E. Hallyn" <se...@ha...>
Cc: key...@li...
Cc: lin...@vg...
Cc: Mimi Zohar <zo...@li...>
Cc: Dmitry Kasatkin <dmi...@gm...>
Cc: James Morris <jam...@or...>
Cc: "Serge E. Hallyn" <se...@ha...>
Cc: lin...@li...
Cc: lin...@li...
Cc: lin...@vg...

2.6.1

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

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

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.

FYI, the EVM key is an encrypted key, which encrypts/decrypts either a
trusted or user type key.

Mimi

[Linux-ima-user] [RFC] crypto: caam - add red blobifier

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

Signed-off-by: Steffen Trumtrar <s.t...@pe...>
---
 drivers/crypto/caam/Kconfig    |   9 +
 drivers/crypto/caam/Makefile   |   1 +
 drivers/crypto/caam/blob_gen.c | 528 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 538 insertions(+)
 create mode 100644 drivers/crypto/caam/blob_gen.c

diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig
index e7555ff4cafd..329fab7ba4f7 100644
--- a/drivers/crypto/caam/Kconfig
+++ b/drivers/crypto/caam/Kconfig
@@ -99,6 +99,15 @@ config CRYPTO_DEV_FSL_CAAM_AHASH_API
 	  To compile this as a module, choose M here: the module
 	  will be called caamhash.
 
+config CRYPTO_DEV_FSL_CAAM_BLOB_GEN
+	tristate "CAAM Blob Generator (EXPERIMENTAL)"
+	depends on CRYPTO_DEV_FSL_CAAM
+	default n
+	help
+	  Selecting this will enable the CAAM red blob generator.
+          This module will take a chunk of data via sysfs and returns
+	  an encrypted red blob. The inverse is also possible.
+
 config CRYPTO_DEV_FSL_CAAM_RNG_API
 	tristate "Register caam device for hwrng API"
 	depends on CRYPTO_DEV_FSL_CAAM && CRYPTO_DEV_FSL_CAAM_JR
diff --git a/drivers/crypto/caam/Makefile b/drivers/crypto/caam/Makefile
index 550758a333e7..359ef3b97fdf 100644
--- a/drivers/crypto/caam/Makefile
+++ b/drivers/crypto/caam/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_JR) += caam_jr.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API) += caamalg.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API) += caamhash.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API) += caamrng.o
+obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_BLOB_GEN) += blob_gen.o
 
 caam-objs := ctrl.o
 caam_jr-objs := jr.o key_gen.o error.o
diff --git a/drivers/crypto/caam/blob_gen.c b/drivers/crypto/caam/blob_gen.c
new file mode 100644
index 000000000000..9c2a02c2882a
--- /dev/null
+++ b/drivers/crypto/caam/blob_gen.c
@@ -0,0 +1,528 @@
+/*
+ * Copyright (C) 2015 Pengutronix, Steffen Trumtrar <ke...@pe...>
+ *
+ * This program is free software; you can redistribute it and/or modify it under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/evm.h>
+#include "compat.h"
+#include "intern.h"
+#include "desc.h"
+#include "desc_constr.h"
+#include "error.h"
+#include "jr.h"
+
+enum access_rights {
+	KERNEL,
+	KERNEL_EVM,
+	USERSPACE,
+};
+
+struct blob_priv {
+	struct device *jrdev;
+	struct device dev;
+	u32 *desc;
+	u8 __iomem *red_blob;
+	u8 __iomem *modifier;
+	u8 __iomem *output;
+	bool busy;
+	enum access_rights access;
+	unsigned int payload_size;
+	struct bin_attribute *blob;
+	struct bin_attribute *payload;
+	struct caam_drv_private *ctrlpriv;
+};
+
+struct blob_job_result {
+	int err;
+	struct completion completion;
+};
+
+static struct platform_device *pdev;
+
+static void blob_job_done(struct device *dev, u32 *desc, u32 err, void *context)
+{
+	struct blob_job_result *res = context;
+
+#ifdef DEBUG
+	dev_err(dev, "%s %d: err 0x%x\n", __func__, __LINE__, err);
+#endif
+
+	if (err)
+		caam_jr_strstatus(dev, err);
+
+	res->err = err;
+
+	complete(&res->completion);
+}
+
+/*
+ * Upon completion, desc points to a buffer containing a CAAM job
+ * descriptor which encapsulates data into an externally-storable
+ * blob.
+ */
+#define INITIAL_DESCSZ		16
+#define BLOB_OVERHEAD		(32 + 16)
+#define KEYMOD_LENGTH		16
+#define RED_BLOB_LENGTH		64
+#define MAX_BLOB_LEN		4096
+
+/*
+ * Generate a blob with the following format:
+ * Format: Normal format (Test format only for testing)
+ * Contents: General data (aka red blob)
+ * Security State: Secure State (Non-Secure for testing)
+ * Memory Types: General memory
+ */
+static int blob_encap_blob(struct blob_priv *priv, u8 *keymod, u8 *input,
+				u8 *output, u16 length)
+{
+	u32 *desc;
+	struct device *jrdev = priv->jrdev;
+	dma_addr_t dma_keymod;
+	dma_addr_t dma_in;
+	dma_addr_t dma_out;
+	struct blob_job_result testres;
+	int ret;
+
+	desc = kmalloc(CAAM_CMD_SZ * 5 + CAAM_PTR_SZ * 5, GFP_KERNEL | GFP_DMA);
+	if (!desc) {
+		dev_err(jrdev, "unable to allocate desc\n");
+		return -ENOMEM;
+	}
+
+	dma_keymod = dma_map_single(jrdev, keymod, KEYMOD_LENGTH, DMA_TO_DEVICE);
+	if (dma_mapping_error(jrdev, dma_keymod)) {
+		dev_err(jrdev, "unable to map keymod buffer\n");
+		ret = -ENOMEM;
+		goto out_free;
+	}
+
+	dma_in = dma_map_single(jrdev, input, length - BLOB_OVERHEAD,
+					DMA_TO_DEVICE);
+	if (dma_mapping_error(jrdev, dma_in)) {
+		dev_err(jrdev, "unable to map keymod buffer\n");
+		ret = -ENOMEM;
+		goto out_unmap_key;
+	}
+
+	dma_out = dma_map_single(jrdev, output, length,	DMA_FROM_DEVICE);
+	if (dma_mapping_error(jrdev, dma_out)) {
+		dev_err(jrdev, "unable to map output DMA buffer\n");
+		ret = -ENOMEM;
+		goto out_unmap_in;
+	}
+
+	/*
+	 * A data blob is encrypted using a blob key (BK); a random number.
+	 * The BK is used as an AES-CCM key. The initial block (B0) and the
+	 * initial counter (Ctr0) are generated automatically and stored in
+	 * Class 1 Context DWords 0+1+2+3. The random BK is stored in the	
+	 * Class 1 Key Register. Operation Mode is set to AES-CCM.
+	 */
+
+	init_job_desc(desc, 0);
+	/*
+	 * The key modifier can be used to differentiate specific data.
+	 * Or to prevent replay attacks.
+	 */
+	append_key(desc, dma_keymod, KEYMOD_LENGTH, CLASS_2 | KEY_DEST_CLASS_REG);
+	append_seq_in_ptr(desc, dma_in, length - BLOB_OVERHEAD, 0);
+	append_seq_out_ptr(desc, dma_out, length, 0);
+	append_operation(desc, OP_TYPE_ENCAP_PROTOCOL | OP_PCLID_BLOB);
+
+#ifdef DEBUG
+	printk("%s: keymod %s\n", __func__, keymod);
+	print_hex_dump(KERN_ERR, "data@"__stringify(__LINE__)": ",
+			DUMP_PREFIX_ADDRESS, 16, 1, input,
+			length - BLOB_OVERHEAD, false);
+	print_hex_dump(KERN_ERR, "jobdesc@"__stringify(__LINE__)": ",
+			DUMP_PREFIX_ADDRESS, 16, 1, desc,
+			desc_bytes(desc), false);
+#endif
+
+	testres.err = 0;
+	init_completion(&testres.completion);
+
+	ret = caam_jr_enqueue(jrdev, desc, blob_job_done, &testres);
+	if (!ret) {
+		wait_for_completion_interruptible(&testres.completion);
+		ret = testres.err;
+#ifdef DEBUG
+		print_hex_dump(KERN_ERR, "output@"__stringify(__LINE__)": ",
+			       DUMP_PREFIX_ADDRESS, 16, 1, output,
+			       length, false);
+#endif
+	}
+
+	dma_unmap_single(jrdev, dma_out, length,
+					DMA_FROM_DEVICE);
+out_unmap_in:
+	dma_unmap_single(jrdev, dma_keymod, KEYMOD_LENGTH, DMA_TO_DEVICE);
+out_unmap_key:
+	dma_unmap_single(jrdev, dma_in, length - BLOB_OVERHEAD, DMA_TO_DEVICE);
+out_free:
+	kfree(desc);
+
+	return ret;
+}
+
+static int blob_decap_blob(struct blob_priv *priv, u8 *keymod, u8 *input,
+				u8 *output, u16 length)
+{
+	u32 *desc;
+	struct device *jrdev = priv->jrdev;
+	dma_addr_t dma_keymod;
+	dma_addr_t dma_in;
+	dma_addr_t dma_out;
+	struct blob_job_result testres;
+	int ret;
+
+	desc = kzalloc(CAAM_CMD_SZ * 5 + CAAM_PTR_SZ * 5, GFP_KERNEL | GFP_DMA);
+	if (!desc) {
+		dev_err(jrdev, "unable to allocate desc\n");
+		return -ENOMEM;
+	}
+
+	dma_keymod = dma_map_single(jrdev, keymod, KEYMOD_LENGTH, DMA_TO_DEVICE);
+	if (dma_mapping_error(jrdev, dma_keymod)) {
+		dev_err(jrdev, "unable to map keymod buffer\n");
+		ret = -ENOMEM;
+		goto out_free;
+	}
+
+	dma_in = dma_map_single(jrdev, input, length, DMA_TO_DEVICE);
+	if (dma_mapping_error(jrdev, dma_in)) {
+		dev_err(jrdev, "unable to map keymod buffer\n");
+		ret = -ENOMEM;
+		goto out_unmap_key;
+	}
+
+	dma_out = dma_map_single(jrdev, output, length - BLOB_OVERHEAD, DMA_FROM_DEVICE);
+	if (dma_mapping_error(jrdev, dma_out)) {
+		dev_err(jrdev, "unable to map output DMA buffer\n");
+		ret = -ENOMEM;
+		goto out_unmap_in;
+	}
+
+	/*
+	 * A data blob is encrypted using a blob key (BK); a random number.
+	 * The BK is used as an AES-CCM key. The initial block (B0) and the
+	 * initial counter (Ctr0) are generated automatically and stored in
+	 * Class 1 Context DWords 0+1+2+3. The random BK is stored in the	
+	 * Class 1 Key Register. Operation Mode is set to AES-CCM.
+	 */
+
+	init_job_desc(desc, 0);
+	/*
+	 * The key modifier can be used to differentiate specific data.
+	 * Or to prevent replay attacks.
+	 */
+	append_key(desc, dma_keymod, KEYMOD_LENGTH, CLASS_2 | KEY_DEST_CLASS_REG);
+	append_seq_in_ptr(desc, dma_in, length, 0);
+	append_seq_out_ptr(desc, dma_out, length - BLOB_OVERHEAD, 0);
+	append_operation(desc, OP_TYPE_DECAP_PROTOCOL | OP_PCLID_BLOB);
+
+#ifdef DEBUG
+	print_hex_dump(KERN_ERR, "data@"__stringify(__LINE__)": ",
+			DUMP_PREFIX_ADDRESS, 16, 1, input,
+			length, false);
+	print_hex_dump(KERN_ERR, "jobdesc@"__stringify(__LINE__)": ",
+			DUMP_PREFIX_ADDRESS, 16, 1, desc,
+			desc_bytes(desc), false);
+#endif
+
+	testres.err = 0;
+	init_completion(&testres.completion);
+
+	ret = caam_jr_enqueue(jrdev, desc, blob_job_done, &testres);
+	if (!ret) {
+		wait_for_completion_interruptible(&testres.completion);
+		ret = testres.err;
+#ifdef DEBUG
+		print_hex_dump(KERN_ERR, "output@"__stringify(__LINE__)": ",
+			       DUMP_PREFIX_ADDRESS, 16, 1, output,
+			       length - BLOB_OVERHEAD, false);
+#endif
+	}
+
+	dma_unmap_single(jrdev, dma_out, length - BLOB_OVERHEAD, DMA_FROM_DEVICE);
+out_unmap_in:
+	dma_unmap_single(jrdev, dma_keymod, KEYMOD_LENGTH, DMA_TO_DEVICE);
+out_unmap_key:
+	dma_unmap_single(jrdev, dma_in, length, DMA_TO_DEVICE);
+out_free:
+	kfree(desc);
+
+	return ret;
+}
+
+static void blob_gen_init_evm(struct blob_priv *priv)
+{
+	evm_init((const char *)priv->output, priv->payload_size);
+}
+
+static ssize_t
+blob_gen_blob_read(struct file *filp, struct kobject *kobj, struct bin_attribute *attr,
+		char *buf, loff_t off, size_t size)
+{
+	struct device *dev = kobj_to_dev(kobj);
+	struct blob_priv *priv = dev_get_drvdata(dev);
+	int length = min((int)size, (int) (priv->payload_size + BLOB_OVERHEAD - off));
+	int ret;
+
+	if (length > 0) {
+		priv->busy = true;
+
+		ret = blob_encap_blob(priv, priv->modifier, priv->output, priv->red_blob, length);
+		if (ret) {
+			priv->busy = false;
+			return -EINVAL;
+		}
+
+		memcpy(buf, priv->red_blob, length);
+
+		priv->busy = false;
+	}
+
+	return length;
+}
+
+static ssize_t
+blob_gen_blob_write(struct file *filp, struct kobject *kobj,
+		struct bin_attribute *attr, char *buf, loff_t off, size_t size)
+{
+	struct device *dev = kobj_to_dev(kobj);
+	struct blob_priv *priv = dev_get_drvdata(dev);
+	int ret;
+
+	if (size > 0) {
+		priv->busy = true;
+
+		memcpy(priv->red_blob, buf, size);
+
+		memset(priv->output, 0, MAX_BLOB_LEN - BLOB_OVERHEAD);
+
+		ret = blob_decap_blob(priv, priv->modifier, priv->red_blob,
+					priv->output, size);
+		if (ret) {
+			priv->busy = false;
+			return -EINVAL;
+		}
+
+		priv->payload_size = size - BLOB_OVERHEAD;
+
+		if (priv->access == KERNEL_EVM)
+			blob_gen_init_evm(priv);
+
+		priv->busy = false;
+	}
+
+	return size;
+}
+
+static ssize_t
+blob_gen_payload_read(struct file *filp, struct kobject *kobj,
+			struct bin_attribute *attr, char *buf, loff_t off,
+			size_t size)
+{
+	struct device *dev = kobj_to_dev(kobj);
+	struct blob_priv *priv = dev_get_drvdata(dev);
+	int length = min((int) size, (int) (priv->payload_size - off));
+
+	if (priv->payload_size == 0)
+		return -EINVAL;
+
+	if (priv->access != USERSPACE)
+		return -EPERM;
+
+	memcpy(buf, priv->output + off, length);
+
+	return length;
+}
+
+static ssize_t
+blob_gen_payload_write(struct file *filp, struct kobject *kobj,
+			struct bin_attribute *attr, char *buf, loff_t off,
+			size_t size)
+{
+	struct device *dev = kobj_to_dev(kobj);
+	struct blob_priv *priv = dev_get_drvdata(dev);
+
+	if (priv->busy)
+		return -EPERM;
+
+	memcpy(priv->output, buf, size);
+
+	priv->payload_size = size;
+
+	return size;
+}
+
+static ssize_t
+blob_gen_show_modifier(struct device *dev, struct device_attribute *attr,
+			char *buf)
+{
+	struct blob_priv *priv = dev_get_drvdata(dev);
+
+	memcpy(buf, priv->modifier, KEYMOD_LENGTH);
+
+	return KEYMOD_LENGTH;
+}
+
+static ssize_t
+blob_gen_set_modifier(struct device *dev, struct device_attribute *attr,
+			const char *buf, size_t n)
+{
+	struct blob_priv *priv = dev_get_drvdata(dev);
+	char *buf_ptr;
+
+	if (n > KEYMOD_LENGTH)
+		return -EINVAL;
+
+	if (priv->busy)
+		return -EPERM;
+
+	buf_ptr = (char *)buf;
+	if (!strncmp(buf_ptr, "kernel:evm", 10))
+		priv->access = KERNEL_EVM;
+	else if (!strncmp(buf_ptr, "kernel:", 7))
+		priv->access = KERNEL;
+	else if (!strncmp(buf_ptr, "user:", 5))
+		priv->access = USERSPACE;
+
+	memset(priv->output, 0, MAX_BLOB_LEN - BLOB_OVERHEAD);
+	memset(priv->red_blob, 0, MAX_BLOB_LEN);
+
+	memcpy(priv->modifier, buf, n);
+
+	return n;
+}
+static DEVICE_ATTR(modifier, S_IRUSR | S_IWUSR,
+		blob_gen_show_modifier, blob_gen_set_modifier);
+
+static struct attribute *blob_attrs[] = {
+	&dev_attr_modifier.attr,
+	NULL,
+};
+ATTRIBUTE_GROUPS(blob);
+
+static int __init blob_gen_init(void)
+{
+	struct device_node *dev_node;
+	struct device *ctrldev;
+	struct caam_drv_private *ctrlpriv;
+	struct blob_priv *priv;
+	int ret;
+
+	dev_node = of_find_compatible_node(NULL, NULL, "fsl,sec-v4.0");
+	if (!dev_node) {
+		dev_node = of_find_compatible_node(NULL, NULL, "fsl,sec4.0");
+		if (!dev_node)
+			return -ENODEV;
+	}
+
+	pdev = of_find_device_by_node(dev_node);
+	if (!pdev) {
+		of_node_put(dev_node);
+		return -ENODEV;
+	}
+
+	ctrldev = &pdev->dev;
+	ctrlpriv = dev_get_drvdata(ctrldev);
+
+	pdev = platform_device_alloc("blob_gen", -1);
+	if (!pdev)
+		return -ENOMEM;
+	pdev->dev.parent = ctrldev;
+	pdev->dev.groups = blob_groups;
+
+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+	priv->blob = devm_kzalloc(&pdev->dev, sizeof(struct bin_attribute),
+					GFP_KERNEL);
+	priv->payload = devm_kzalloc(&pdev->dev, sizeof(struct bin_attribute),
+					GFP_KERNEL);
+
+	ret = platform_device_add(pdev);
+	if (ret)
+		goto pdev_add_failed;
+
+	priv->modifier = devm_kzalloc(&pdev->dev, sizeof(*priv->modifier)*KEYMOD_LENGTH,
+			GFP_KERNEL | GFP_DMA);
+
+	priv->red_blob = devm_kzalloc(&pdev->dev, sizeof(*priv->red_blob)*
+					MAX_BLOB_LEN, GFP_KERNEL | GFP_DMA);
+
+	priv->output = devm_kzalloc(&pdev->dev, sizeof(*priv->output)*
+					MAX_BLOB_LEN - BLOB_OVERHEAD, GFP_KERNEL | GFP_DMA);
+
+	priv->desc = devm_kzalloc(&pdev->dev, sizeof(*priv->desc), GFP_KERNEL | GFP_DMA);
+	if (priv->desc == NULL)
+		return -ENOMEM;
+
+	dev_set_drvdata(&pdev->dev, priv);
+
+	priv->busy = false;
+
+	priv->jrdev = &ctrlpriv->jrpdev[0]->dev;
+
+	priv->blob->attr.name = "blob";
+	priv->blob->attr.mode = S_IRUSR | S_IWUSR;
+
+	sysfs_bin_attr_init(priv->blob);
+	priv->blob->read = blob_gen_blob_read;
+	priv->blob->write = blob_gen_blob_write;
+
+	ret = sysfs_create_bin_file(&pdev->dev.kobj, priv->blob);
+	if (ret)
+		dev_err(&pdev->dev, "unable to create sysfs file %s\n",
+			priv->blob->attr.name);
+	else
+		dev_info(&pdev->dev, "added sysfs binary attribute\n");
+
+	priv->payload->attr.name = "payload";
+	priv->payload->attr.mode = S_IRUSR | S_IWUSR;
+
+	sysfs_bin_attr_init(priv->payload);
+	priv->payload->read = blob_gen_payload_read;
+	priv->payload->write = blob_gen_payload_write;
+
+	ret = sysfs_create_bin_file(&pdev->dev.kobj, priv->payload);
+	if (ret)
+		dev_err(&pdev->dev, "unable to create sysfs file %s\n",
+			priv->payload->attr.name);
+	else
+		dev_info(&pdev->dev, "added sysfs binary attribute\n");
+
+	return 0;
+
+pdev_add_failed:
+	platform_device_put(pdev);
+
+	return ret;
+}
+
+static void __exit blob_gen_exit(void)
+{
+	struct blob_priv *priv;
+
+	priv = dev_get_drvdata(&pdev->dev);
+	if (!priv)
+		return;
+
+	sysfs_remove_bin_file(&pdev->dev.kobj, priv->payload);
+	sysfs_remove_bin_file(&pdev->dev.kobj, priv->blob);
+
+	platform_device_unregister(pdev);
+}
+
+module_init(blob_gen_init);
+module_exit(blob_gen_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Blob Generator Example");
+MODULE_AUTHOR("Steffen Trumtrar <s.t...@pe...>");
-- 
2.6.1