Re: [PATCH 2/3] KEYS: Separate the kernel signature checking keyring from module signing

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

On Thu, 2013-01-17 at 18:04 +0000, David Howells wrote:
> Separate the kernel signature checking keyring from module signing so that it
> can be used by code other than the module-signing code.
> 
> Signed-off-by: David Howells <dhowells@redhat.com>

Sounds good, but comment below...

> ---
> 
>  init/Kconfig                 |   13 +++++
>  kernel/Makefile              |   17 ++++---
>  kernel/modsign_certificate.S |   18 -------
>  kernel/modsign_pubkey.c      |  104 ------------------------------------------
>  kernel/module-internal.h     |    2 -
>  kernel/module_signing.c      |    3 +
>  kernel/system_certificates.S |   18 +++++++
>  kernel/system_keyring.c      |  101 +++++++++++++++++++++++++++++++++++++++++
>  8 files changed, 145 insertions(+), 131 deletions(-)
>  delete mode 100644 kernel/modsign_certificate.S
>  delete mode 100644 kernel/modsign_pubkey.c
>  create mode 100644 kernel/system_certificates.S
>  create mode 100644 kernel/system_keyring.c
> 
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 7d30240..a5363d2 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1568,6 +1568,18 @@ config BASE_SMALL
>  	default 0 if BASE_FULL
>  	default 1 if !BASE_FULL
> 
> +config SYSTEM_TRUSTED_KEYRING
> +	bool "Provide system-wide ring of trusted keys"
> +	select KEYS
> +	help
> +	  Provide a system keyring to which trusted keys can be added.  Keys in
> +	  the keyring are considered to be trusted.  Keys may be added at will
> +	  by the kernel from compiled-in data and from hardware key stores, but
> +	  userspace may only add extra keys if those keys can be verified by
> +	  keys already in the keyring.
> +

Lets assume accepting built in keys should is acceptable for all use
cases.  Adding additional keys from userspace is probably not acceptable
for all use cases.  Those keys should be added to specific 'trusted'
keyrings.

EVM and IMA-appraisal have separate keyrings for this reason.  I might
be interested in allowing third party packages to be installed and
executed, but that doesn't imply that a security.evm extended attribute,
signed by a third party application, is acceptable.

thanks,

Mimi