Re: [tpmdd-devel] [PATCH 00/10] TPM2 updates for 4.4

[Kevin Strasser]

On Fri, Oct 16, 2015 at 09:40:19PM +0300, Jarkko Sakkinen wrote:
> This patch set enables distributions to start production of for TPM 2.0:
> 
> * Two critical bug fixes
> * PPI support
> * Basic trusted keys with authentication value and SHA256 for keyed hash
> 
> Next steps after this is to add policy based sealing for trusted keys and
> algorithmic agility.

Applied the series and ran some basic trusted keys tests.

For the series:
Tested-by: Kevin Strasser 

> 
> Jarkko Sakkinen (10):
>   tpm, tpm_crb: fix unaligned read of the command buffer address
>   tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM 2.0
>   sysfs: added __compat_only_sysfs_link_entry_to_kobj()
>   tpm: move the PPI attributes to character device directory.
>   tpm: update PPI documentation to address the location change.
>   tpm: introduce tpm_buf
>   keys, trusted: move struct trusted_key_options to trusted-type.h
>   tpm: seal/unseal for TPM 2.0
>   keys, trusted: seal/unseal with TPM 2.0 chips
>   MAINTAINERS: add new maintainer for TPM DEVICE DRIVER
> 
>  Documentation/ABI/testing/sysfs-driver-ppi |  19 ++-
>  MAINTAINERS|   1 +
>  drivers/char/tpm/tpm-chip.c|  24 ++-
>  drivers/char/tpm/tpm-interface.c   |  76 +
>  drivers/char/tpm/tpm.h | 134 ++--
>  drivers/char/tpm/tpm2-cmd.c| 250 
> -
>  drivers/char/tpm/tpm_crb.c |  39 ++---
>  drivers/char/tpm/tpm_ppi.c |  34 ++--
>  drivers/char/tpm/tpm_tis.c | 192 ++
>  fs/sysfs/group.c   |  44 +
>  include/keys/trusted-type.h|  14 +-
>  include/linux/sysfs.h  |  11 ++
>  include/linux/tpm.h|  26 +++
>  security/keys/trusted.c|  36 -
>  security/keys/trusted.h|  11 --
>  15 files changed, 793 insertions(+), 118 deletions(-)
> 
> -- 
> 2.5.0
> 
> 
> --
> ___
> tpmdd-devel mailing list
> tpmdd-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/4] Basic trusted keys support for TPM 2.0

[Jarkko Sakkinen]

Hi

On Fri, Oct 16, 2015 at 05:21:02PM +0100, David Howells wrote:
> Hi Jarkko,
> 
> For some reason I don't see patch 1.

Weird. Well, maybe the best way to proceed is that I'll send the
contents of for-peter-v44 branch for review. It's 9 patches in total,
PPI, trusted keys and couple of bug fixes.

> David

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

[PATCH 00/10] TPM2 updates for 4.4

[Jarkko Sakkinen]

This patch set enables distributions to start production of for TPM 2.0:

* Two critical bug fixes
* PPI support
* Basic trusted keys with authentication value and SHA256 for keyed hash

Next steps after this is to add policy based sealing for trusted keys and
algorithmic agility.

Jarkko Sakkinen (10):
  tpm, tpm_crb: fix unaligned read of the command buffer address
  tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM 2.0
  sysfs: added __compat_only_sysfs_link_entry_to_kobj()
  tpm: move the PPI attributes to character device directory.
  tpm: update PPI documentation to address the location change.
  tpm: introduce tpm_buf
  keys, trusted: move struct trusted_key_options to trusted-type.h
  tpm: seal/unseal for TPM 2.0
  keys, trusted: seal/unseal with TPM 2.0 chips
  MAINTAINERS: add new maintainer for TPM DEVICE DRIVER

 Documentation/ABI/testing/sysfs-driver-ppi |  19 ++-
 MAINTAINERS|   1 +
 drivers/char/tpm/tpm-chip.c|  24 ++-
 drivers/char/tpm/tpm-interface.c   |  76 +
 drivers/char/tpm/tpm.h | 134 ++--
 drivers/char/tpm/tpm2-cmd.c| 250 -
 drivers/char/tpm/tpm_crb.c |  39 ++---
 drivers/char/tpm/tpm_ppi.c |  34 ++--
 drivers/char/tpm/tpm_tis.c | 192 ++
 fs/sysfs/group.c   |  44 +
 include/keys/trusted-type.h|  14 +-
 include/linux/sysfs.h  |  11 ++
 include/linux/tpm.h|  26 +++
 security/keys/trusted.c|  36 -
 security/keys/trusted.h|  11 --
 15 files changed, 793 insertions(+), 118 deletions(-)

-- 
2.5.0

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

[PATCH 08/10] tpm: seal/unseal for TPM 2.0

[Jarkko Sakkinen]

Added tpm_trusted_seal() and tpm_trusted_unseal() API for sealing
trusted keys.

This patch implements basic sealing and unsealing functionality for
TPM 2.0:

* Seal with a parent key using a 20 byte auth value.
* Unseal with a parent key using a 20 byte auth value.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm-interface.c |  76 
 drivers/char/tpm/tpm.h   |  15 ++-
 drivers/char/tpm/tpm2-cmd.c  | 250 ++-
 include/keys/trusted-type.h  |   2 +-
 include/linux/tpm.h  |  26 
 5 files changed, 366 insertions(+), 3 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index e85d341..c50637d 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -666,6 +666,30 @@ int tpm_pcr_read_dev(struct tpm_chip *chip, int pcr_idx, 
u8 *res_buf)
 }
 
 /**
+ * tpm_is_tpm2 - is the chip a TPM2 chip?
+ * @chip_num:  tpm idx # or ANY
+ *
+ * Returns < 0 on error, and 1 or 0 on success depending whether the chip
+ * is a TPM2 chip.
+ */
+int tpm_is_tpm2(u32 chip_num)
+{
+   struct tpm_chip *chip;
+   int rc;
+
+   chip = tpm_chip_find_get(chip_num);
+   if (chip == NULL)
+   return -ENODEV;
+
+   rc = (chip->flags & TPM_CHIP_FLAG_TPM2) != 0;
+
+   tpm_chip_put(chip);
+
+   return rc;
+}
+EXPORT_SYMBOL_GPL(tpm_is_tpm2);
+
+/**
  * tpm_pcr_read - read a pcr value
  * @chip_num:  tpm idx # or ANY
  * @pcr_idx:   pcr idx to retrieve
@@ -1021,6 +1045,58 @@ int tpm_get_random(u32 chip_num, u8 *out, size_t max)
 }
 EXPORT_SYMBOL_GPL(tpm_get_random);
 
+/**
+ * tpm_seal_trusted() - seal a trusted key
+ * @chip_num: A specific chip number for the request or TPM_ANY_NUM
+ * @options: authentication values and other options
+ * @payload: the key data in clear and encrypted form
+ *
+ * Returns < 0 on error and 0 on success. At the moment, only TPM 2.0 chips
+ * are supported.
+ */
+int tpm_seal_trusted(u32 chip_num, struct trusted_key_payload *payload,
+struct trusted_key_options *options)
+{
+   struct tpm_chip *chip;
+   int rc;
+
+   chip = tpm_chip_find_get(chip_num);
+   if (chip == NULL || !(chip->flags & TPM_CHIP_FLAG_TPM2))
+   return -ENODEV;
+
+   rc = tpm2_seal_trusted(chip, payload, options);
+
+   tpm_chip_put(chip);
+   return rc;
+}
+EXPORT_SYMBOL_GPL(tpm_seal_trusted);
+
+/**
+ * tpm_unseal_trusted() - unseal a trusted key
+ * @chip_num: A specific chip number for the request or TPM_ANY_NUM
+ * @options: authentication values and other options
+ * @payload: the key data in clear and encrypted form
+ *
+ * Returns < 0 on error and 0 on success. At the moment, only TPM 2.0 chips
+ * are supported.
+ */
+int tpm_unseal_trusted(u32 chip_num, struct trusted_key_payload *payload,
+  struct trusted_key_options *options)
+{
+   struct tpm_chip *chip;
+   int rc;
+
+   chip = tpm_chip_find_get(chip_num);
+   if (chip == NULL || !(chip->flags & TPM_CHIP_FLAG_TPM2))
+   return -ENODEV;
+
+   rc = tpm2_unseal_trusted(chip, payload, options);
+
+   tpm_chip_put(chip);
+   return rc;
+}
+EXPORT_SYMBOL_GPL(tpm_unseal_trusted);
+
 static int __init tpm_init(void)
 {
int rc;
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index cb46f62..a4257a3 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -90,6 +90,9 @@ enum tpm2_return_codes {
 
 enum tpm2_algorithms {
TPM2_ALG_SHA1   = 0x0004,
+   TPM2_ALG_KEYEDHASH  = 0x0008,
+   TPM2_ALG_SHA256 = 0x000B,
+   TPM2_ALG_NULL   = 0x0010
 };
 
 enum tpm2_command_codes {
@@ -97,6 +100,10 @@ enum tpm2_command_codes {
TPM2_CC_SELF_TEST   = 0x0143,
TPM2_CC_STARTUP = 0x0144,
TPM2_CC_SHUTDOWN= 0x0145,
+   TPM2_CC_CREATE  = 0x0153,
+   TPM2_CC_LOAD= 0x0157,
+   TPM2_CC_UNSEAL  = 0x015E,
+   TPM2_CC_FLUSH_CONTEXT   = 0x0165,
TPM2_CC_GET_CAPABILITY  = 0x017A,
TPM2_CC_GET_RANDOM  = 0x017B,
TPM2_CC_PCR_READ= 0x017E,
@@ -407,7 +414,7 @@ struct tpm_buf {
u8 *data;
 };
 
-static inline void tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal)
+static inline int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal)
 {
struct tpm_input_header *head;
 
@@ -527,6 +534,12 @@ static inline void tpm_add_ppi(struct tpm_chip *chip)
 int tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf);
 int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash);
 int tpm2_get_random(struct tpm_chip *chip, u8 *out, size_t max);
+int tpm2_seal_trusted(struct tpm_chip *chip,
+ struct trusted_key_payload *payload,
+ struct trusted_key_options *options);
+int tpm2_unseal_trusted(struct tpm_chip *chip,

[PATCH 09/10] keys, trusted: seal/unseal with TPM 2.0 chips

[Jarkko Sakkinen]

Call tpm_seal_trusted() and tpm_unseal_trusted() for TPM 2.0 chips.
We require explicit 'keyhandle=' option because there's no a fixed
storage root key inside TPM2 chips.

Signed-off-by: Jarkko Sakkinen 
Reviewed-by: Andreas Fuchs 
Tested-by: Mimi Zohar  (on TPM 1.2)
Tested-by: Chris J Arges 
Tested-by: Colin Ian King 
---
 security/keys/trusted.c | 36 +---
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index c0594cb..d3633cf 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -862,12 +862,19 @@ static int datablob_parse(char *datablob, struct 
trusted_key_payload *p,
 static struct trusted_key_options *trusted_options_alloc(void)
 {
struct trusted_key_options *options;
+   int tpm2;
+
+   tpm2 = tpm_is_tpm2(TPM_ANY_NUM);
+   if (tpm2 < 0)
+   return NULL;
 
options = kzalloc(sizeof *options, GFP_KERNEL);
if (options) {
/* set any non-zero defaults */
options->keytype = SRK_keytype;
-   options->keyhandle = SRKHANDLE;
+
+   if (!tpm2)
+   options->keyhandle = SRKHANDLE;
}
return options;
 }
@@ -905,6 +912,11 @@ static int trusted_instantiate(struct key *key,
int ret = 0;
int key_cmd;
size_t key_len;
+   int tpm2;
+
+   tpm2 = tpm_is_tpm2(TPM_ANY_NUM);
+   if (tpm2 < 0)
+   return tpm2;
 
if (datalen <= 0 || datalen > 32767 || !prep->data)
return -EINVAL;
@@ -932,12 +944,20 @@ static int trusted_instantiate(struct key *key,
goto out;
}
 
+   if (!options->keyhandle) {
+   ret = -EINVAL;
+   goto out;
+   }
+
dump_payload(payload);
dump_options(options);
 
switch (key_cmd) {
case Opt_load:
-   ret = key_unseal(payload, options);
+   if (tpm2)
+   ret = tpm_unseal_trusted(TPM_ANY_NUM, payload, options);
+   else
+   ret = key_unseal(payload, options);
dump_payload(payload);
dump_options(options);
if (ret < 0)
@@ -950,7 +970,10 @@ static int trusted_instantiate(struct key *key,
pr_info("trusted_key: key_create failed (%d)\n", ret);
goto out;
}
-   ret = key_seal(payload, options);
+   if (tpm2)
+   ret = tpm_seal_trusted(TPM_ANY_NUM, payload, options);
+   else
+   ret = key_seal(payload, options);
if (ret < 0)
pr_info("trusted_key: key_seal failed (%d)\n", ret);
break;
@@ -1018,6 +1041,13 @@ static int trusted_update(struct key *key, struct 
key_preparsed_payload *prep)
kfree(new_p);
goto out;
}
+
+   if (!new_o->keyhandle) {
+   ret = -EINVAL;
+   kfree(new_p);
+   goto out;
+   }
+
/* copy old key values, and reseal with new pcrs */
new_p->migratable = p->migratable;
new_p->key_len = p->key_len;
-- 
2.5.0

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

[PATCH v1 0/1] Smack: adding Smack-Tags subsystem

[José Bollo]

INTRODUCTION

Adding a feature in the kernel is not something free, it must
have some interest. I will try here to explain the reasons
why I am posting here a new bag of code.

I studied the security of Tizen 3 [1] and modestly participated
to it. Tizen 3 uses Smack as its security background. But
managing API level authorisation with Smack is nor simple
nor very efficient. The current implementation uses a component
named "cynara" [2] to record (database) the authorisation (aka
privilege) of applications. Services called can check wether
an instance of an application has or not the authorisation for
given user.

Before cynara came on the scene, I made some studies. One of it
tried to implement a keyring of authorisations using fuse [3].
This was an interesting research but it had big issues.
The biggest being that it can not follows application's lifecycle:
clone, exec, exit...

This issues are merely disappearing when the keyring of
authorisations is managed by a LSM (Linux Security Module).
I submit here this "sub"-module of Smack.

I used not the word of "authorisation" but just the word
of "tag". The reason is that the submodule can be used for
any purpose.

HOW TO ACTIVATE IT?
===
It is a sub-module of Smack and it can be activated/deactivated in
the config using CONFIG_SECURITY_SMACK_TAGS.

WHAT IS IT DOING?
=
Each process or thread receive a list of tags. This list can
be empty. This tags are copied (this is not shared) during 'clone'
and mostly kept during 'exec'.

By default:
 - processes can NOT remove any tags for itself
 - processes can NOT add any tag to itself
 - processes can NOT alter the tags of other processes
 - processes lose their tags during 'execve'
 - processes can read tags of other processes when DAC/MAC allows it

But some rules allow:
 - authorised processes can remove tags
 - authorised processes can add tags
 - authorised processes can alter other processes tags
 - authorised processes can keep their tags during 'exec'

More accurate details are in the commit message.

WHAT IS THE IDEA BEHIND?

An authorised process can add a tag X to itself or other process.
Later, an other process can check wether a process has or not the
tag X to adapt its behaviour.

Mechanisms here given are allowing either a centralized service
for tagging processes or a fork/exec model.

A such module can be easily used as part of a cynara like
authorisation system.

LINKS
=
[1] https://wiki.tizen.org/wiki/Security
[2] https://wiki.tizen.org/wiki/Security/Tizen_3.X_Cynara
[3] https://github.com/jobol/keyzen

José Bollo (1):
  Smack: adding Smack-Tags subsystem

 fs/proc/base.c  |   3 +
 security/smack/Kconfig  |   8 +
 security/smack/Makefile |   1 +
 security/smack/smack.h  |   7 +
 security/smack/smack_lsm.c  |  39 +++
 security/smack/smack_tags.c | 641

 security/smack/smack_tags.h |  40 +++
 7 files changed, 739 insertions(+)
 create mode 100644 security/smack/smack_tags.c
 create mode 100644 security/smack/smack_tags.h

-- 
2.1.4



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

[PATCH v4 1/3] Enable multiple writes to the IMA policy;

[Petko Manolov]

IMA policy can now be updated multiple times.  The new rules get appended
to the original policy.  Have in mind that the rules are scanned in FIFO
order so be careful when you add new ones.

The mutex locks are replaced with RCU, which should lead to faster policy
traversals.  The new rules are first appended to a temporary list, which
on error gets released without disturbing the normal IMA operations.

Signed-off-by: Petko Manolov 
---
 security/integrity/ima/Kconfig  | 14 
 security/integrity/ima/ima_fs.c | 13 +++
 security/integrity/ima/ima_policy.c | 70 +
 3 files changed, 74 insertions(+), 23 deletions(-)

diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index df30334..15264b7 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -107,6 +107,20 @@ config IMA_DEFAULT_HASH
default "sha512" if IMA_DEFAULT_HASH_SHA512
default "wp512" if IMA_DEFAULT_HASH_WP512
 
+config IMA_WRITE_POLICY
+   bool "Enable multiple writes to the IMA policy"
+   depends on IMA
+   default n
+   help
+ IMA policy can now be updated multiple times.  The new rules get
+ appended to the original policy.  Have in mind that the rules are
+ scanned in FIFO order so be careful when you add new ones.
+
+ WARNING: Potential security hole - should be used with care in
+ production-grade kernels!
+
+ If unsure, say N.
+
 config IMA_APPRAISE
bool "Appraise integrity measurements"
depends on IMA
diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
index 816d175..a3cf5c0 100644
--- a/security/integrity/ima/ima_fs.c
+++ b/security/integrity/ima/ima_fs.c
@@ -25,6 +25,8 @@
 
 #include "ima.h"
 
+static DEFINE_MUTEX(ima_write_mutex);
+
 static int valid_policy = 1;
 #define TMPBUFLEN 12
 static ssize_t ima_show_htable_value(char __user *buf, size_t count,
@@ -261,6 +263,11 @@ static ssize_t ima_write_policy(struct file *file, const 
char __user *buf,
 {
char *data = NULL;
ssize_t result;
+   int res;
+
+   res = mutex_lock_interruptible(_write_mutex);
+   if (res)
+   return res;
 
if (datalen >= PAGE_SIZE)
datalen = PAGE_SIZE - 1;
@@ -286,6 +293,8 @@ out:
if (result < 0)
valid_policy = 0;
kfree(data);
+   mutex_unlock(_write_mutex);
+
return result;
 }
 
@@ -337,8 +346,12 @@ static int ima_release_policy(struct inode *inode, struct 
file *file)
return 0;
}
ima_update_policy();
+#ifndefCONFIG_IMA_WRITE_POLICY
securityfs_remove(ima_policy);
ima_policy = NULL;
+#else
+   clear_bit(IMA_FS_BUSY, _fs_flags);
+#endif
return 0;
 }
 
diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index 3997e20..7ace4e4 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "ima.h"
@@ -135,11 +136,11 @@ static struct ima_rule_entry default_appraise_rules[] = {
 
 static LIST_HEAD(ima_default_rules);
 static LIST_HEAD(ima_policy_rules);
+static LIST_HEAD(ima_temp_rules);
 static struct list_head *ima_rules;
 
-static DEFINE_MUTEX(ima_rules_mutex);
-
 static int ima_policy __initdata;
+
 static int __init default_measure_policy_setup(char *str)
 {
if (ima_policy)
@@ -171,9 +172,8 @@ static int __init default_appraise_policy_setup(char *str)
 __setup("ima_appraise_tcb", default_appraise_policy_setup);
 
 /*
- * Although the IMA policy does not change, the LSM policy can be
- * reloaded, leaving the IMA LSM based rules referring to the old,
- * stale LSM policy.
+ * Blocking here is not legal as we hold an RCU lock.  ima_update_policy()
+ * should make it safe to walk the list at any time.
  *
  * Update the IMA LSM based rules to reflect the reloaded LSM policy.
  * We assume the rules still exist; and BUG_ON() if they don't.
@@ -184,7 +184,6 @@ static void ima_lsm_update_rules(void)
int result;
int i;
 
-   mutex_lock(_rules_mutex);
list_for_each_entry_safe(entry, tmp, _policy_rules, list) {
for (i = 0; i < MAX_LSM_RULES; i++) {
if (!entry->lsm[i].rule)
@@ -196,7 +195,6 @@ static void ima_lsm_update_rules(void)
BUG_ON(!entry->lsm[i].rule);
}
}
-   mutex_unlock(_rules_mutex);
 }
 
 /**
@@ -319,9 +317,9 @@ static int get_subaction(struct ima_rule_entry *rule, int 
func)
  * Measure decision based on func/mask/fsmagic and LSM(subj/obj/type)
  * conditions.
  *
- * (There is no need for locking when walking the policy list,
- * as elements in the list are never deleted, nor does the list
- * change.)
+ * Since the IMA policy may be updated multiple times we need to 

[PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Petko Manolov]

This option creates IMA MOK and blacklist keyrings.  IMA MOK is an
intermediate keyring that sits between .system and .ima keyrings,
effectively forming a simple CA hierarchy.  To successfully import a key
into .ima_mok it must be signed by a key which CA is in .system keyring.
On turn any key that needs to go in .ima keyring must be signed by CA in
either .system or .ima_mok keyrings. IMA MOK is empty at kernel boot.

IMA blacklist keyring contains all revoked IMA keys.  It is consulted
before any other keyring.  If the search is successful the requested
operation is rejected and error is returned to the caller.

Signed-off-by: Petko Manolov 
---
 crypto/asymmetric_keys/x509_public_key.c |  2 ++
 include/keys/system_keyring.h| 24 ++
 security/integrity/digsig_asymmetric.c   | 14 +
 security/integrity/ima/Kconfig   | 17 ++
 security/integrity/ima/Makefile  |  1 +
 security/integrity/ima/ima_mok.c | 54 
 6 files changed, 112 insertions(+)
 create mode 100644 security/integrity/ima/ima_mok.c

diff --git a/crypto/asymmetric_keys/x509_public_key.c 
b/crypto/asymmetric_keys/x509_public_key.c
index 1970966..66dcf30 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -319,6 +319,8 @@ static int x509_key_preparse(struct key_preparsed_payload 
*prep)
goto error_free_cert;
} else if (!prep->trusted) {
ret = x509_validate_trust(cert, get_system_trusted_keyring());
+   if (ret)
+   ret = x509_validate_trust(cert, get_ima_mok_keyring());
if (!ret)
prep->trusted = 1;
}
diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index b20cd88..39fd38c 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -35,4 +35,28 @@ extern int system_verify_data(const void *data, unsigned 
long len,
  enum key_being_used_for usage);
 #endif
 
+#ifdef CONFIG_IMA_MOK_KEYRING
+extern struct key *ima_mok_keyring;
+extern struct key *ima_blacklist_keyring;
+
+static inline struct key *get_ima_mok_keyring(void)
+{
+   return ima_mok_keyring;
+}
+static inline struct key *get_ima_blacklist_keyring(void)
+{
+   return ima_blacklist_keyring;
+}
+#else
+static inline struct key *get_ima_mok_keyring(void)
+{
+   return NULL;
+}
+static inline struct key *get_ima_blacklist_keyring(void)
+{
+   return NULL;
+}
+#endif /* CONFIG_IMA_MOK_KEYRING */
+
+
 #endif /* _KEYS_SYSTEM_KEYRING_H */
diff --git a/security/integrity/digsig_asymmetric.c 
b/security/integrity/digsig_asymmetric.c
index 4fec181..5ade2a7 100644
--- a/security/integrity/digsig_asymmetric.c
+++ b/security/integrity/digsig_asymmetric.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "integrity.h"
 
@@ -32,9 +33,22 @@ static struct key *request_asymmetric_key(struct key 
*keyring, uint32_t keyid)
 
pr_debug("key search: \"%s\"\n", name);
 
+   key = get_ima_blacklist_keyring();
+   if (key) {
+   key_ref_t kref;
+
+   kref = keyring_search(make_key_ref(key, 1),
+_type_asymmetric, name);
+   if (!IS_ERR(kref)) {
+   pr_err("Key '%s' is in ima_blacklist_keyring\n", name);
+   return ERR_PTR(-EKEYREJECTED);
+   }
+   }
+
if (keyring) {
/* search in specific keyring */
key_ref_t kref;
+
kref = keyring_search(make_key_ref(keyring, 1),
  _type_asymmetric, name);
if (IS_ERR(kref))
diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index 15264b7..235b3c2 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -145,6 +145,23 @@ config IMA_TRUSTED_KEYRING
   This option requires that all keys added to the .ima
   keyring be signed by a key on the system trusted keyring.
 
+config IMA_MOK_KEYRING
+   bool "Create IMA machine owner keys (MOK) and blacklist keyrings"
+   depends on IMA_TRUSTED_KEYRING
+   default y
+   help
+  This option creates IMA MOK and blacklist keyrings.  IMA MOK is an
+  intermediate keyring that sits between .system and .ima keyrings,
+  effectively forming a simple CA hierarchy.  To successfully import a
+  key into .ima_mok it must be signed by a key which CA is in .system
+  keyring.  On turn any key that needs to go in .ima keyring must be
+  signed by CA in either .system or .ima_mok keyrings. IMA MOK is empty
+  at kernel boot.
+
+  IMA blacklist keyring contains all revoked IMA keys.  It is consulted
+  before any other keyring.  If the search is successful the 

Re: [PATCH v4 09/11] smack: namespace groundwork

[Lukasz Pawelczyk]

On pią, 2015-10-16 at 11:04 +0800, Hillf Danton wrote:
> > +
> >  static inline void smack_userns_free(struct user_namespace *ns)
> >  {
> > struct smack_ns *snsp = ns->security;
> > @@ -4680,12 +4689,11 @@ static inline void smack_userns_free(struct
> > user_namespace *ns)
> > 
> > mutex_lock(>smk_mapped_lock);
> > list_del_rcu(>smk_list_known);
> > -   if (sknp->smk_allocated)
> > -   kfree(sknp->smk_mapped);
> > -   kfree(sknp);
> > mutex_unlock(>smk_mapped_lock);
> > 
> > list_del(>smk_list_ns);
> 
> Is list_del safe, given the operation
> 
> + mutex_lock(>smk_mapped_lock);
> + list_add_rcu(>smk_list_ns, >smk_mapped);
> + mutex_unlock(>smk_mapped_lock);
> 
> in smk_import_mapped() function(copied below)?

Yes, the namespace is destroyed when all its references are gone. This
also includes processes that were in that namespace. Meaning there is
no way to import a new mapping for them anymore at this point.


-- 
Lukasz Pawelczyk
Samsung R Institute Poland
Samsung Electronics




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

Re: [PATCH v4] Smack: limited capability for changing process label

[Rafał Krypa]

On 2015-10-15 10:04, Casey Schaufler wrote:
> On 10/15/2015 12:48 AM, Rafał Krypa wrote:
>> On 2015-10-14 17:54, Rafal Krypa wrote:
>>> From: Zbigniew Jasinski 
>>>
>>> This feature introduces new kernel interface:
>>>
>>> - /relabel-self - for setting transition labels list
>>>
>>> This list is used to control smack label transition mechanism.
>>> List is set by, and per process. Process can transit to new label only if
>>> label is on the list. Only process with CAP_MAC_ADMIN capability can add
>>> labels to this list. With this list, process can change it's label without
>>> CAP_MAC_ADMIN but only once. After label changing, list is unset.
>>>
>>> Changes in v2:
>>> * use list_for_each_entry instead of _rcu during label write
>>> * added missing description in security/Smack.txt
>>>
>>> Changes in v3:
>>> * squashed into one commit
>>>
>>> Changes in v4:
>>> * switch from global list to per-task list
>>> * since the per-task list is accessed only by the task itself
>>>   there is no need to use synchronization mechanisms on it
>>>
>>> Signed-off-by: Zbigniew Jasinski 
>>> Signed-off-by: Rafal Krypa 
>>> ---
>>>  Documentation/security/Smack.txt |  14 
>>>  security/smack/smack.h   |   3 +-
>>>  security/smack/smack_access.c|   6 +-
>>>  security/smack/smack_lsm.c   |  73 -
>>>  security/smack/smackfs.c | 167 
>>> ---
>>>  5 files changed, 246 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/Documentation/security/Smack.txt 
>>> b/Documentation/security/Smack.txt
>>> index 5e6d07f..d9ace08 100644
>>> --- a/Documentation/security/Smack.txt
>>> +++ b/Documentation/security/Smack.txt
>>> @@ -255,6 +255,20 @@ unconfined
>>> the access permitted if it wouldn't be otherwise. Note that this
>>> is dangerous and can ruin the proper labeling of your system.
>>> It should never be used in production.
>>> +relabel-self
>>> +   This interface contains a list of labels to which the process can
>>> +   transition to, by writing to /proc/self/attr/current.
>>> +   Normally a process can change its own label to any legal value, but only
>>> +   if it has CAP_MAC_ADMIN. This interface allows a process without
>>> +   CAP_MAC_ADMIN to relabel itself to one of labels from predefined list.
>>> +   A process without CAP_MAC_ADMIN can change its label only once. When it
>>> +   does, this list will be cleared.
>>> +
>>> +   The format accepted on write is:
>>> +   "%s"
>>> +   for adding label, and:
>>> +   "-%s"
>>> +   for removing label from list.
>> I have one concern here, let me make some self-criticism.
>> The interface described here for relabel-self is convenient and suiting 
>> actual needs of user space parts that are going to use it.
>> But it is inconsistent with other existing interfaces in smackfs. Recently I 
>> submitted a patch (merged into v4.2) that extended onlycap to allow multiple 
>> labels in it.
>> The smackfs interface for onlycap always takes the full list of labels that 
>> replaces the list that was previously set.
>> Now relabel-self is also going to contain a list of labels. But smackfs 
>> interface gets one label at a time and performs add/remove operations.
>>
>> Are you OK. with such inconsistency?
>>
> A foolish consistency is the hobgoblin of little minds.
>
> More directly, I am fine with it. Some of your previous work
> made removing labels from lists practical where it had not been
> before. I would rather have an inconsistent interface set
> than one that is consistently bad.

I am sorry forcausing confusion. I have reassessed the user space requirements 
and it seems that with per-task list, it will be always written in full. The 
ability for adding or removing labels was nice, but only useful when the list 
was global.
So please let me update the patch one more time, with relabel-self having the 
same interface as onlycap.
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/4] Basic trusted keys support for TPM 2.0

[David Howells]

Hi Jarkko,

For some reason I don't see patch 1.

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