All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: linux-security-module@vger.kernel.org,
	linux-ima-devel@lists.sourceforge.net, keyrings@vger.kernel.org,
	linux-crypto@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	James Morris <james.l.morris@oracle.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	David Howells <dhowells@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Jessica Yu <jeyu@redhat.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	"AKASHI, Takahiro" <takahiro.akashi@linaro.org>
Subject: Re: [PATCH v2 6/6] ima: Support module-style appended signatures for appraisal
Date: Wed, 05 Jul 2017 08:13:01 -0400	[thread overview]
Message-ID: <1499256781.3059.41.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <87fuebei68.fsf@linux.vnet.ibm.com>

On Tue, 2017-07-04 at 23:22 -0300, Thiago Jung Bauermann wrote:
> Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> 
> > On Wed, 2017-06-21 at 14:45 -0300, Thiago Jung Bauermann wrote:
> >> Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> >> > On Wed, 2017-06-07 at 22:49 -0300, Thiago Jung Bauermann wrote:
> >> >> @@ -267,11 +276,18 @@ int ima_appraise_measurement(enum ima_hooks func,
> >> >>  		status = INTEGRITY_PASS;
> >> >>  		break;
> >> >>  	case EVM_IMA_XATTR_DIGSIG:
> >> >> +	case IMA_MODSIG:
> >> >>  		iint->flags |= IMA_DIGSIG;
> >> >> -		rc = integrity_digsig_verify(INTEGRITY_KEYRING_IMA,
> >> >> -					     (const char *)xattr_value, rc,
> >> >> -					     iint->ima_hash->digest,
> >> >> -					     iint->ima_hash->length);
> >> >> +
> >> >> +		if (xattr_value->type == EVM_IMA_XATTR_DIGSIG)
> >> >> +			rc = integrity_digsig_verify(INTEGRITY_KEYRING_IMA,
> >> >> +						     (const char *)xattr_value,
> >> >> +						     rc, iint->ima_hash->digest,
> >> >> +						     iint->ima_hash->length);
> >> >> +		else
> >> >> +			rc = ima_modsig_verify(INTEGRITY_KEYRING_IMA,
> >> >> +					       xattr_value);
> >> >> +
> >> >
> >> > Perhaps allowing IMA_MODSIG to flow into EVM_IMA_XATTR_DIGSIG on
> >> > failure, would help restore process_measurements() to the way it was.
> >> > Further explanation below.
> >> 
> >> It's not possible to simply flow into EVM_IMA_XATTR_DIGSIG on failure
> >> because after calling ima_read_xattr we need to run again all the logic
> >> before the switch statement. Instead, I'm currently testing the
> >> following change for v3, what do you think?
> >
> > I don't think we can assume that the same algorithm will be used for
> > signing the kernel image. Different entities would be signing the
> > kernel image with different requirements.
> >
> > Suppose for example a stock distro image comes signed using one
> > algorithm (appended signature), but the same kernel image is locally
> > signed using a different algorithm (xattr). Signature verification is
> > dependent on either the distro or local public key being loaded onto
> > the IMA keyring.
> 
> This example is good, but it raises one question: should the xattr
> signature cover the entire contents of the stock distro image (i.e.,
> also cover the appended signature), or should it ignore the appended
> signature and thus cover the same contents that the appended signature
> covers?
> 
> If the former, then we can't reuse the iint->ima_hash that was collected
> when trying to verify the appended signature because it doesn't cover
> the appended signature itself and won't match the hash expected by the
> xattr signature.
> 
> If the latter, then evmctl ima_sign needs to be modified to check
> whether there's an appended signature in the given file and ignore it
> when calculating the xattr signature.
> 
> Which is better?

I realize that having the same file hash for both the appended
signature and extended attribute would make things a lot easier, but
security.ima is a signature of the file as written to disk, meaning it
would include any appended signature

> 
> >> >> @@ -226,30 +282,23 @@ static int process_measurement(struct file *file, char *buf, loff_t size,
> >> >>  		goto out_digsig;
> >> >>  	}
> >> >> 
> >> >> -	template_desc = ima_template_desc_current();
> >> >> -	if ((action & IMA_APPRAISE_SUBMASK) ||
> >> >> -		    strcmp(template_desc->name, IMA_TEMPLATE_IMA_NAME) != 0)
> >> >> -		/* read 'security.ima' */
> >> >> -		xattr_len = ima_read_xattr(file_dentry(file), &xattr_value);
> >> >> -
> >> >> -	hash_algo = ima_get_hash_algo(xattr_value, xattr_len);
> >> >> -
> >> >> -	rc = ima_collect_measurement(iint, file, buf, size, hash_algo);
> >> >> -	if (rc != 0) {
> >> >> -		if (file->f_flags & O_DIRECT)
> >> >> -			rc = (iint->flags & IMA_PERMIT_DIRECTIO) ? 0 : -EACCES;
> >> >> -		goto out_digsig;
> >> >> -	}
> >> >> -
> >> >
> >> > There are four stages: collect measurement, store measurement,
> >> > appraise measurement and audit measurement. "Collect" needs to be
> >> > done if any one of the other stages is needed.
> >> >
> >> >>  	if (!pathbuf)	/* ima_rdwr_violation possibly pre-fetched */
> >> >>  		pathname = ima_d_path(&file->f_path, &pathbuf, filename);
> >> >> 
> >> >> +	if (iint->flags & IMA_MODSIG_ALLOWED)
> >> >> +		rc = measure_and_appraise(file, buf, size, func, opened, action,
> >> >> +					  iint, &xattr_value, &xattr_len,
> >> >> +					  pathname, true);
> >> >> +	if (!xattr_len)
> >> >> +		rc = measure_and_appraise(file, buf, size, func, opened, action,
> >> >> +					  iint, &xattr_value, &xattr_len,
> >> >> +					  pathname, false);
> >> >
> >> > I would rather see "collect" extended to support an appended signature
> >> > rather than trying to combine "collect" and "appraise" together.
> >> 
> >> I'm not sure I understand what you mean by "extend collect to support an
> >> appended signature", but the fundamental problem is that we don't know
> >> whether we need to fallback to the xattr sig until the appraise step
> >> because that's when we verify the signature, and by then the collect and
> >> store steps were already completed and would need to be done again if
> >> the hash algorithm in the xattr sig is different.
> >
> > The "appraise" stage could be moved before the "store" stage, like you
> > have. (This should be a separate patch explaining the need for moving
> > it.) Based on an argument to ima_collect_measurement() have it
> > "collect" either the appended signature or the xattr. Maybe something
> > like this:
> >
> > loop [ appended signature, xattr ] { <== list based on policy flags
> >   collect_measurement()
> >   if failure
> >     continue
> >   appraise_measurement()
> >   if success
> >     break
> > }
> >
> > store_measurement()
> 
> Ok, the above is what v2 already does, so the only change I made was to
> rename the function from measure_and_appraise to collect_and_appraise to
> match the IMA jargon.

I would prefer if you did not combine the "collect" and "appraise"
functions, but left them independent of each other. 

Mimi

WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Cc: linux-security-module@vger.kernel.org,
	linux-ima-devel@lists.sourceforge.net, keyrings@vger.kernel.org,
	linux-crypto@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	James Morris <james.l.morris@oracle.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	David Howells <dhowells@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Jessica Yu <jeyu@redhat.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	"AKASHI, Takahiro" <takahiro.akashi@linaro.org>
Subject: Re: [PATCH v2 6/6] ima: Support module-style appended signatures for appraisal
Date: Wed, 05 Jul 2017 12:13:01 +0000	[thread overview]
Message-ID: <1499256781.3059.41.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <87fuebei68.fsf@linux.vnet.ibm.com>

On Tue, 2017-07-04 at 23:22 -0300, Thiago Jung Bauermann wrote:
> Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> 
> > On Wed, 2017-06-21 at 14:45 -0300, Thiago Jung Bauermann wrote:
> >> Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> >> > On Wed, 2017-06-07 at 22:49 -0300, Thiago Jung Bauermann wrote:
> >> >> @@ -267,11 +276,18 @@ int ima_appraise_measurement(enum ima_hooks func,
> >> >>  		status = INTEGRITY_PASS;
> >> >>  		break;
> >> >>  	case EVM_IMA_XATTR_DIGSIG:
> >> >> +	case IMA_MODSIG:
> >> >>  		iint->flags |= IMA_DIGSIG;
> >> >> -		rc = integrity_digsig_verify(INTEGRITY_KEYRING_IMA,
> >> >> -					     (const char *)xattr_value, rc,
> >> >> -					     iint->ima_hash->digest,
> >> >> -					     iint->ima_hash->length);
> >> >> +
> >> >> +		if (xattr_value->type = EVM_IMA_XATTR_DIGSIG)
> >> >> +			rc = integrity_digsig_verify(INTEGRITY_KEYRING_IMA,
> >> >> +						     (const char *)xattr_value,
> >> >> +						     rc, iint->ima_hash->digest,
> >> >> +						     iint->ima_hash->length);
> >> >> +		else
> >> >> +			rc = ima_modsig_verify(INTEGRITY_KEYRING_IMA,
> >> >> +					       xattr_value);
> >> >> +
> >> >
> >> > Perhaps allowing IMA_MODSIG to flow into EVM_IMA_XATTR_DIGSIG on
> >> > failure, would help restore process_measurements() to the way it was.
> >> > Further explanation below.
> >> 
> >> It's not possible to simply flow into EVM_IMA_XATTR_DIGSIG on failure
> >> because after calling ima_read_xattr we need to run again all the logic
> >> before the switch statement. Instead, I'm currently testing the
> >> following change for v3, what do you think?
> >
> > I don't think we can assume that the same algorithm will be used for
> > signing the kernel image. Different entities would be signing the
> > kernel image with different requirements.
> >
> > Suppose for example a stock distro image comes signed using one
> > algorithm (appended signature), but the same kernel image is locally
> > signed using a different algorithm (xattr). Signature verification is
> > dependent on either the distro or local public key being loaded onto
> > the IMA keyring.
> 
> This example is good, but it raises one question: should the xattr
> signature cover the entire contents of the stock distro image (i.e.,
> also cover the appended signature), or should it ignore the appended
> signature and thus cover the same contents that the appended signature
> covers?
> 
> If the former, then we can't reuse the iint->ima_hash that was collected
> when trying to verify the appended signature because it doesn't cover
> the appended signature itself and won't match the hash expected by the
> xattr signature.
> 
> If the latter, then evmctl ima_sign needs to be modified to check
> whether there's an appended signature in the given file and ignore it
> when calculating the xattr signature.
> 
> Which is better?

I realize that having the same file hash for both the appended
signature and extended attribute would make things a lot easier, but
security.ima is a signature of the file as written to disk, meaning it
would include any appended signature

> 
> >> >> @@ -226,30 +282,23 @@ static int process_measurement(struct file *file, char *buf, loff_t size,
> >> >>  		goto out_digsig;
> >> >>  	}
> >> >> 
> >> >> -	template_desc = ima_template_desc_current();
> >> >> -	if ((action & IMA_APPRAISE_SUBMASK) ||
> >> >> -		    strcmp(template_desc->name, IMA_TEMPLATE_IMA_NAME) != 0)
> >> >> -		/* read 'security.ima' */
> >> >> -		xattr_len = ima_read_xattr(file_dentry(file), &xattr_value);
> >> >> -
> >> >> -	hash_algo = ima_get_hash_algo(xattr_value, xattr_len);
> >> >> -
> >> >> -	rc = ima_collect_measurement(iint, file, buf, size, hash_algo);
> >> >> -	if (rc != 0) {
> >> >> -		if (file->f_flags & O_DIRECT)
> >> >> -			rc = (iint->flags & IMA_PERMIT_DIRECTIO) ? 0 : -EACCES;
> >> >> -		goto out_digsig;
> >> >> -	}
> >> >> -
> >> >
> >> > There are four stages: collect measurement, store measurement,
> >> > appraise measurement and audit measurement. "Collect" needs to be
> >> > done if any one of the other stages is needed.
> >> >
> >> >>  	if (!pathbuf)	/* ima_rdwr_violation possibly pre-fetched */
> >> >>  		pathname = ima_d_path(&file->f_path, &pathbuf, filename);
> >> >> 
> >> >> +	if (iint->flags & IMA_MODSIG_ALLOWED)
> >> >> +		rc = measure_and_appraise(file, buf, size, func, opened, action,
> >> >> +					  iint, &xattr_value, &xattr_len,
> >> >> +					  pathname, true);
> >> >> +	if (!xattr_len)
> >> >> +		rc = measure_and_appraise(file, buf, size, func, opened, action,
> >> >> +					  iint, &xattr_value, &xattr_len,
> >> >> +					  pathname, false);
> >> >
> >> > I would rather see "collect" extended to support an appended signature
> >> > rather than trying to combine "collect" and "appraise" together.
> >> 
> >> I'm not sure I understand what you mean by "extend collect to support an
> >> appended signature", but the fundamental problem is that we don't know
> >> whether we need to fallback to the xattr sig until the appraise step
> >> because that's when we verify the signature, and by then the collect and
> >> store steps were already completed and would need to be done again if
> >> the hash algorithm in the xattr sig is different.
> >
> > The "appraise" stage could be moved before the "store" stage, like you
> > have. (This should be a separate patch explaining the need for moving
> > it.) Based on an argument to ima_collect_measurement() have it
> > "collect" either the appended signature or the xattr. Maybe something
> > like this:
> >
> > loop [ appended signature, xattr ] { <= list based on policy flags
> >   collect_measurement()
> >   if failure
> >     continue
> >   appraise_measurement()
> >   if success
> >     break
> > }
> >
> > store_measurement()
> 
> Ok, the above is what v2 already does, so the only change I made was to
> rename the function from measure_and_appraise to collect_and_appraise to
> match the IMA jargon.

I would prefer if you did not combine the "collect" and "appraise"
functions, but left them independent of each other. 

Mimi


WARNING: multiple messages have this Message-ID (diff)
From: zohar@linux.vnet.ibm.com (Mimi Zohar)
To: linux-security-module@vger.kernel.org
Subject: [PATCH v2 6/6] ima: Support module-style appended signatures for appraisal
Date: Wed, 05 Jul 2017 08:13:01 -0400	[thread overview]
Message-ID: <1499256781.3059.41.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <87fuebei68.fsf@linux.vnet.ibm.com>

On Tue, 2017-07-04 at 23:22 -0300, Thiago Jung Bauermann wrote:
> Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> 
> > On Wed, 2017-06-21 at 14:45 -0300, Thiago Jung Bauermann wrote:
> >> Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> >> > On Wed, 2017-06-07 at 22:49 -0300, Thiago Jung Bauermann wrote:
> >> >> @@ -267,11 +276,18 @@ int ima_appraise_measurement(enum ima_hooks func,
> >> >>  		status = INTEGRITY_PASS;
> >> >>  		break;
> >> >>  	case EVM_IMA_XATTR_DIGSIG:
> >> >> +	case IMA_MODSIG:
> >> >>  		iint->flags |= IMA_DIGSIG;
> >> >> -		rc = integrity_digsig_verify(INTEGRITY_KEYRING_IMA,
> >> >> -					     (const char *)xattr_value, rc,
> >> >> -					     iint->ima_hash->digest,
> >> >> -					     iint->ima_hash->length);
> >> >> +
> >> >> +		if (xattr_value->type == EVM_IMA_XATTR_DIGSIG)
> >> >> +			rc = integrity_digsig_verify(INTEGRITY_KEYRING_IMA,
> >> >> +						     (const char *)xattr_value,
> >> >> +						     rc, iint->ima_hash->digest,
> >> >> +						     iint->ima_hash->length);
> >> >> +		else
> >> >> +			rc = ima_modsig_verify(INTEGRITY_KEYRING_IMA,
> >> >> +					       xattr_value);
> >> >> +
> >> >
> >> > Perhaps allowing IMA_MODSIG to flow into EVM_IMA_XATTR_DIGSIG on
> >> > failure, would help restore process_measurements() to the way it was.
> >> > Further explanation below.
> >> 
> >> It's not possible to simply flow into EVM_IMA_XATTR_DIGSIG on failure
> >> because after calling ima_read_xattr we need to run again all the logic
> >> before the switch statement. Instead, I'm currently testing the
> >> following change for v3, what do you think?
> >
> > I don't think we can assume that the same algorithm will be used for
> > signing the kernel image. Different entities would be signing the
> > kernel image with different requirements.
> >
> > Suppose for example a stock distro image comes signed using one
> > algorithm (appended signature), but the same kernel image is locally
> > signed using a different algorithm (xattr). Signature verification is
> > dependent on either the distro or local public key being loaded onto
> > the IMA keyring.
> 
> This example is good, but it raises one question: should the xattr
> signature cover the entire contents of the stock distro image (i.e.,
> also cover the appended signature), or should it ignore the appended
> signature and thus cover the same contents that the appended signature
> covers?
> 
> If the former, then we can't reuse the iint->ima_hash that was collected
> when trying to verify the appended signature because it doesn't cover
> the appended signature itself and won't match the hash expected by the
> xattr signature.
> 
> If the latter, then evmctl ima_sign needs to be modified to check
> whether there's an appended signature in the given file and ignore it
> when calculating the xattr signature.
> 
> Which is better?

I realize that having the same file hash for both the appended
signature and extended attribute would make things a lot easier, but
security.ima is a signature of the file as written to disk, meaning it
would include any appended signature

> 
> >> >> @@ -226,30 +282,23 @@ static int process_measurement(struct file *file, char *buf, loff_t size,
> >> >>  		goto out_digsig;
> >> >>  	}
> >> >> 
> >> >> -	template_desc = ima_template_desc_current();
> >> >> -	if ((action & IMA_APPRAISE_SUBMASK) ||
> >> >> -		    strcmp(template_desc->name, IMA_TEMPLATE_IMA_NAME) != 0)
> >> >> -		/* read 'security.ima' */
> >> >> -		xattr_len = ima_read_xattr(file_dentry(file), &xattr_value);
> >> >> -
> >> >> -	hash_algo = ima_get_hash_algo(xattr_value, xattr_len);
> >> >> -
> >> >> -	rc = ima_collect_measurement(iint, file, buf, size, hash_algo);
> >> >> -	if (rc != 0) {
> >> >> -		if (file->f_flags & O_DIRECT)
> >> >> -			rc = (iint->flags & IMA_PERMIT_DIRECTIO) ? 0 : -EACCES;
> >> >> -		goto out_digsig;
> >> >> -	}
> >> >> -
> >> >
> >> > There are four stages: collect measurement, store measurement,
> >> > appraise measurement and audit measurement. "Collect" needs to be
> >> > done if any one of the other stages is needed.
> >> >
> >> >>  	if (!pathbuf)	/* ima_rdwr_violation possibly pre-fetched */
> >> >>  		pathname = ima_d_path(&file->f_path, &pathbuf, filename);
> >> >> 
> >> >> +	if (iint->flags & IMA_MODSIG_ALLOWED)
> >> >> +		rc = measure_and_appraise(file, buf, size, func, opened, action,
> >> >> +					  iint, &xattr_value, &xattr_len,
> >> >> +					  pathname, true);
> >> >> +	if (!xattr_len)
> >> >> +		rc = measure_and_appraise(file, buf, size, func, opened, action,
> >> >> +					  iint, &xattr_value, &xattr_len,
> >> >> +					  pathname, false);
> >> >
> >> > I would rather see "collect" extended to support an appended signature
> >> > rather than trying to combine "collect" and "appraise" together.
> >> 
> >> I'm not sure I understand what you mean by "extend collect to support an
> >> appended signature", but the fundamental problem is that we don't know
> >> whether we need to fallback to the xattr sig until the appraise step
> >> because that's when we verify the signature, and by then the collect and
> >> store steps were already completed and would need to be done again if
> >> the hash algorithm in the xattr sig is different.
> >
> > The "appraise" stage could be moved before the "store" stage, like you
> > have. (This should be a separate patch explaining the need for moving
> > it.) Based on an argument to ima_collect_measurement() have it
> > "collect" either the appended signature or the xattr. Maybe something
> > like this:
> >
> > loop [ appended signature, xattr ] { <== list based on policy flags
> >   collect_measurement()
> >   if failure
> >     continue
> >   appraise_measurement()
> >   if success
> >     break
> > }
> >
> > store_measurement()
> 
> Ok, the above is what v2 already does, so the only change I made was to
> rename the function from measure_and_appraise to collect_and_appraise to
> match the IMA jargon.

I would prefer if you did not combine the "collect" and "appraise"
functions, but left them independent of each other.?

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-07-05 12:13 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-08  1:49 [PATCH v2 0/6] Appended signatures support for IMA appraisal Thiago Jung Bauermann
2017-06-08  1:49 ` Thiago Jung Bauermann
2017-06-08  1:49 ` Thiago Jung Bauermann
2017-06-08  1:49 ` [PATCH v2 1/6] integrity: Small code improvements Thiago Jung Bauermann
2017-06-08  1:49   ` Thiago Jung Bauermann
2017-06-08  1:49   ` Thiago Jung Bauermann
2017-06-15 16:00   ` Mimi Zohar
2017-06-15 16:00     ` Mimi Zohar
2017-06-15 16:00     ` Mimi Zohar
2017-06-08  1:49 ` [PATCH v2 2/6] ima: Simplify policy_func_show Thiago Jung Bauermann
2017-06-08  1:49   ` Thiago Jung Bauermann
2017-06-08  1:49   ` Thiago Jung Bauermann
2017-06-15 16:00   ` Mimi Zohar
2017-06-15 16:00     ` Mimi Zohar
2017-06-15 16:00     ` Mimi Zohar
2017-06-08  1:49 ` [PATCH v2 3/6] ima: Log the same audit cause whenever a file has no signature Thiago Jung Bauermann
2017-06-08  1:49   ` Thiago Jung Bauermann
2017-06-08  1:49   ` Thiago Jung Bauermann
2017-06-15 16:00   ` Mimi Zohar
2017-06-15 16:00     ` Mimi Zohar
2017-06-15 16:00     ` Mimi Zohar
2017-06-08  1:49 ` [PATCH v2 4/6] integrity: Introduce struct evm_hmac_xattr Thiago Jung Bauermann
2017-06-08  1:49   ` Thiago Jung Bauermann
2017-06-08  1:49   ` Thiago Jung Bauermann
2017-06-08  1:49 ` [PATCH v2 5/6] MODSIGN: Export module signature definitions Thiago Jung Bauermann
2017-06-08  1:49   ` Thiago Jung Bauermann
2017-06-08  1:49   ` Thiago Jung Bauermann
2017-06-08  1:49 ` [PATCH v2 6/6] ima: Support module-style appended signatures for appraisal Thiago Jung Bauermann
2017-06-08  1:49   ` Thiago Jung Bauermann
2017-06-08  1:49   ` Thiago Jung Bauermann
2017-06-14 12:39   ` Mimi Zohar
2017-06-14 12:39     ` Mimi Zohar
2017-06-14 12:39     ` Mimi Zohar
2017-06-21 17:45     ` Thiago Jung Bauermann
2017-06-21 17:45       ` Thiago Jung Bauermann
2017-06-21 17:45       ` Thiago Jung Bauermann
2017-06-22  1:33       ` Mimi Zohar
2017-06-22  1:33         ` Mimi Zohar
2017-06-22  1:33         ` Mimi Zohar
2017-07-05  2:22         ` Thiago Jung Bauermann
2017-07-05  2:22           ` Thiago Jung Bauermann
2017-07-05  2:22           ` Thiago Jung Bauermann
2017-07-05 12:13           ` Mimi Zohar [this message]
2017-07-05 12:13             ` Mimi Zohar
2017-07-05 12:13             ` Mimi Zohar
2017-06-09 10:27 ` [PATCH v2 0/6] Appended signatures support for IMA appraisal Michael Ellerman
2017-06-09 10:27   ` Michael Ellerman
2017-06-09 10:27   ` Michael Ellerman
2017-06-09 21:19   ` Thiago Jung Bauermann
2017-06-09 21:19     ` Thiago Jung Bauermann
2017-06-09 21:19     ` Thiago Jung Bauermann
2017-06-13 10:18     ` Michael Ellerman
2017-06-13 10:18       ` Michael Ellerman
2017-06-13 10:18       ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1499256781.3059.41.camel@linux.vnet.ibm.com \
    --to=zohar@linux.vnet.ibm.com \
    --cc=bauerman@linux.vnet.ibm.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=james.l.morris@oracle.com \
    --cc=jeyu@redhat.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-ima-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=rusty@rustcorp.com.au \
    --cc=serge@hallyn.com \
    --cc=takahiro.akashi@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.