linux-kernel - Re: linux-next: manual merge of the integrity tree with the jc-docs tree

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] [day] [month] [year] [list]

Message-ID: <20171113163524.797e17d4@canb.auug.org.au>
Date:   Mon, 13 Nov 2017 16:35:24 +1100
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Jonathan Corbet <corbet@....net>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        James Morris <jmorris@...ei.org>
Cc:     Mark Brown <broonie@...nel.org>,
        Matthew Garrett <mjg59@...gle.com>,
        Tom Saeger <tom.saeger@...cle.com>,
        Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: manual merge of the integrity tree with the jc-docs
 tree

Hi all,

On Wed, 18 Oct 2017 11:50:25 +0100 Mark Brown <broonie@...nel.org> wrote:
>
> Today's linux-next merge of the integrity tree got a conflict in:
> 
>   Documentation/ABI/testing/evm
> 
> between commit:
> 
>   c7f66400f504fd5 ("Documentation: fix security related doc refs")
> 
> from the jc-docs tree and commit:
> 
>   cbad39d632b7c18 ("EVM: Allow userspace to signal an RSA key has been loaded")
> 
> from the integrity tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --cc Documentation/ABI/testing/evm
> index ca622c9aa24c,a0bbccb00736..000000000000
> --- a/Documentation/ABI/testing/evm
> +++ b/Documentation/ABI/testing/evm
> @@@ -7,17 -7,36 +7,36 @@@ Description
>   		HMAC-sha1 value across the extended attributes, storing the
>   		value as the extended attribute 'security.evm'.
>   
> - 		EVM depends on the Kernel Key Retention System to provide it
> - 		with a trusted/encrypted key for the HMAC-sha1 operation.
> - 		The key is loaded onto the root's keyring using keyctl.  Until
> - 		EVM receives notification that the key has been successfully
> - 		loaded onto the keyring (echo 1 > <securityfs>/evm), EVM
> - 		can not create or validate the 'security.evm' xattr, but
> - 		returns INTEGRITY_UNKNOWN.  Loading the key and signaling EVM
> - 		should be done as early as possible.  Normally this is done
> - 		in the initramfs, which has already been measured as part
> - 		of the trusted boot.  For more information on creating and
> - 		loading existing trusted/encrypted keys, refer to:
> - 		Documentation/security/keys/trusted-encrypted.rst.  (A sample
> - 		dracut patch, which loads the trusted/encrypted key and enables
> - 		EVM, is available from http://linux-ima.sourceforge.net/#EVM.)
> + 		EVM supports two classes of security.evm. The first is
> + 		an HMAC-sha1 generated locally with a
> + 		trusted/encrypted key stored in the Kernel Key
> + 		Retention System. The second is a digital signature
> + 		generated either locally or remotely using an
> + 		asymmetric key. These keys are loaded onto root's
> + 		keyring using keyctl, and EVM is then enabled by
> + 		echoing a value to <securityfs>/evm:
> + 
> + 		1: enable HMAC validation and creation
> + 		2: enable digital signature validation
> + 		3: enable HMAC and digital signature validation and HMAC
> + 		   creation
> + 
> + 		Further writes will be blocked if HMAC support is enabled or
> + 		if bit 32 is set:
> + 
> + 		echo 0x80000002 ><securityfs>/evm
> + 
> + 		will enable digital signature validation and block
> + 		further writes to <securityfs>/evm.
> + 
> + 		Until this is done, EVM can not create or validate the
> + 		'security.evm' xattr, but returns INTEGRITY_UNKNOWN.
> + 		Loading keys and signaling EVM should be done as early
> + 		as possible.  Normally this is done in the initramfs,
> + 		which has already been measured as part of the trusted
> + 		boot.  For more information on creating and loading
> + 		existing trusted/encrypted keys, refer to:
>  -		Documentation/keys-trusted-encrypted.txt. Both dracut
> ++		Documentation/security/keys/trusted-encrypted.rst. Both dracut
> + 		(via 97masterkey and 98integrity) and systemd (via
> + 		core/ima-setup) have support for loading keys at boot
> + 		time.

Just a reminder that this conflict still exists (and is now relevant to
the security tree).

-- 
Cheers,
Stephen Rothwell