Re: [PATCH v2 2/2] integrity: convert digsig to akcipher api

On 12/14/2015 05:24 AM, Mimi Zohar wrote: > On Sat, 2015-12-12 at 18:26 -0800, Tadeusz Struk wrote: >> Convert asymmetric_verify to akcipher api. >> >> Signed-off-by: Tadeusz Struk >> --- >> security/integrity/Kconfig |1 + >>

Re: [PATCH v2 3/3] keys, trusted: seal with a TPM2 authorization policy

On Sun, 2015-12-13 at 17:42 +0200, Jarkko Sakkinen wrote: > TPM2 supports authorization policies, which are essentially > combinational logic statements repsenting the conditions where the data > can be unsealed based on the TPM state. This patch enables to use > authorization policies to seal

Re: [PATCH v2 1/3] keys, trusted: fix: *do not* allow duplicate key options

On Mon, Dec 14, 2015 at 08:46:33AM -0500, Mimi Zohar wrote: > On Sun, 2015-12-13 at 17:42 +0200, Jarkko Sakkinen wrote: > > The trusted keys option parsing allows specifying the same option > > multiple times. The last option value specified is used. > > > > This can be seen as a regression

Re: [PATCH v2 1/3] keys, trusted: fix: *do not* allow duplicate key options

On Sun, 2015-12-13 at 17:42 +0200, Jarkko Sakkinen wrote: > The trusted keys option parsing allows specifying the same option > multiple times. The last option value specified is used. > > This can be seen as a regression because: > > * No gain. > * Could be problematic if there is be options

Re: [PATCH v2 3/3] keys, trusted: seal with a TPM2 authorization policy

On Mon, Dec 14, 2015 at 08:49:00AM -0500, Mimi Zohar wrote: > On Sun, 2015-12-13 at 17:42 +0200, Jarkko Sakkinen wrote: > > TPM2 supports authorization policies, which are essentially > > combinational logic statements repsenting the conditions where the data > > can be unsealed based on the TPM

Re: [PATCH v2 2/2] integrity: convert digsig to akcipher api

On Sat, 2015-12-12 at 18:26 -0800, Tadeusz Struk wrote: > Convert asymmetric_verify to akcipher api. > > Signed-off-by: Tadeusz Struk > --- > security/integrity/Kconfig |1 + > security/integrity/digsig_asymmetric.c | 10 +++--- > 2 files changed,

Re: Exposing secid to secctx mapping to user-space

On 12/14/2015 12:03 PM, Mike Palmiotto wrote: On Sun, Dec 13, 2015 at 5:06 PM, Paul Moore wrote: On Friday, December 11, 2015 05:14:38 PM Stephen Smalley wrote: Perhaps we could provide a new fixed-size tokenized version of the security context string for export to

Re: Exposing secid to secctx mapping to user-space

On Sun, Dec 13, 2015 at 5:06 PM, Paul Moore wrote: > On Friday, December 11, 2015 05:14:38 PM Stephen Smalley wrote: >> Perhaps we could provide a new fixed-size tokenized version of the >> security context string for export to userspace that could be embedded >> in the

Re: Exposing secid to secctx mapping to user-space

On 12/14/2015 9:03 AM, Mike Palmiotto wrote: > On Sun, Dec 13, 2015 at 5:06 PM, Paul Moore wrote: >> On Friday, December 11, 2015 05:14:38 PM Stephen Smalley wrote: >>> Perhaps we could provide a new fixed-size tokenized version of the >>> security context string for export

RE: Exposing secid to secctx mapping to user-space

> Subject: Re: Exposing secid to secctx mapping to user-space > > On 12/13/2015 2:06 PM, Paul Moore wrote: > > On Friday, December 11, 2015 05:14:38 PM Stephen Smalley wrote: > >> Perhaps we could provide a new fixed-size tokenized version of the > >> security context string for export to

RE: Exposing secid to secctx mapping to user-space

> > > > If I understand correctly, the goal here is to avoid the lookup from > > pid to context. If we somehow Had the context or a token to a context > > during the ipc transaction to userspace, we could just use that In > > computing the access decision. If that is correct, then since we have >