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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1358449049.2689.87.camel@falcor1>
Date:	Thu, 17 Jan 2013 13:57:29 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	David Howells <dhowells@...hat.com>
Cc:	dmitry.kasatkin@...el.com, linux-kernel@...r.kernel.org,
	keyrings@...ux-nfs.org, linux-security-module@...r.kernel.org,
	linux-crypto@...r.kernel.org
Subject: Re: [PATCH 2/3] KEYS: Separate the kernel signature checking
 keyring from module signing

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@...hat.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/