summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* PKCS#7: Use x509_request_asymmetric_key()David Howells2014-07-293-72/+29
| | | | | | | | | | | | | pkcs7_request_asymmetric_key() and x509_request_asymmetric_key() do the same thing, the latter being a copy of the former created by the IMA folks, so drop the PKCS#7 version as the X.509 location is more general. Whilst we're at it, rename the arguments of x509_request_asymmetric_key() to better reflect what the values being passed in are intended to match on an X.509 cert. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
* X.509: x509_request_asymmetric_keys() doesn't need string length argumentsDavid Howells2014-07-281-6/+3
| | | | | | | | x509_request_asymmetric_keys() doesn't need the lengths of the NUL-terminated strings passing in as it can work that out for itself. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
* PKCS#7: fix sparse non static symbol warningWei Yongjun2014-07-281-1/+1
| | | | | | | | | | Fixes the following sparse warnings: crypto/asymmetric_keys/pkcs7_key_type.c:73:17: warning: symbol 'key_type_pkcs7' was not declared. Should it be static? Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: David Howells <dhowells@redhat.com>
* KEYS: revert encrypted key changeMimi Zohar2014-07-281-1/+1
| | | | | | | | | Commit fc7c70e "KEYS: struct key_preparsed_payload should have two payload pointers" erroneously modified encrypted-keys. This patch reverts the change to that file. Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: David Howells <dhowells@redhat.com>
* Merge tag 'fw-restrict-3.17' of ↵James Morris2014-07-2611-8/+104
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux into next
| * ima: add support for measuring and appraising firmwareMimi Zohar2014-07-258-5/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | The "security: introduce kernel_fw_from_file hook" patch defined a new security hook to evaluate any loaded firmware that wasn't built into the kernel. This patch defines ima_fw_from_file(), which is called from the new security hook, to measure and/or appraise the loaded firmware's integrity. Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Kees Cook <keescook@chromium.org>
| * firmware_class: perform new LSM checksKees Cook2014-07-251-4/+26
| | | | | | | | | | | | | | | | | | | | This attaches LSM hooks to the existing firmware loading interfaces: filesystem-found firmware and demand-loaded blobs. On errors, loads are aborted and the failure code is returned to userspace. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Takashi Iwai <tiwai@suse.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * security: introduce kernel_fw_from_file hookKees Cook2014-07-253-0/+29
| | | | | | | | | | | | | | | | | | | | In order to validate the contents of firmware being loaded, there must be a hook to evaluate any loaded firmware that wasn't built into the kernel itself. Without this, there is a risk that a root user could load malicious firmware designed to mount an attack against kernel memory (e.g. via DMA). Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Takashi Iwai <tiwai@suse.de>
* | Merge tag 'keys-next-20140725' of ↵James Morris2014-07-261-0/+1
|\ \ | |/ |/| | | git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into next
| * PKCS#7: Missing inclusion of linux/err.hDavid Howells2014-07-251-0/+1
| | | | | | | | | | | | | | | | | | | | crypto/asymmetric_keys/pkcs7_key_type.c needs to #include linux/err.h rather than relying on getting it through other headers. Without this, the powerpc allyesconfig build fails. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David Howells <dhowells@redhat.com>
* | CAPABILITIES: remove undefined caps from all processesEric Paris2014-07-245-12/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is effectively a revert of 7b9a7ec565505699f503b4fcf61500dceb36e744 plus fixing it a different way... We found, when trying to run an application from an application which had dropped privs that the kernel does security checks on undefined capability bits. This was ESPECIALLY difficult to debug as those undefined bits are hidden from /proc/$PID/status. Consider a root application which drops all capabilities from ALL 4 capability sets. We assume, since the application is going to set eff/perm/inh from an array that it will clear not only the defined caps less than CAP_LAST_CAP, but also the higher 28ish bits which are undefined future capabilities. The BSET gets cleared differently. Instead it is cleared one bit at a time. The problem here is that in security/commoncap.c::cap_task_prctl() we actually check the validity of a capability being read. So any task which attempts to 'read all things set in bset' followed by 'unset all things set in bset' will not even attempt to unset the undefined bits higher than CAP_LAST_CAP. So the 'parent' will look something like: CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: ffffffc000000000 All of this 'should' be fine. Given that these are undefined bits that aren't supposed to have anything to do with permissions. But they do... So lets now consider a task which cleared the eff/perm/inh completely and cleared all of the valid caps in the bset (but not the invalid caps it couldn't read out of the kernel). We know that this is exactly what the libcap-ng library does and what the go capabilities library does. They both leave you in that above situation if you try to clear all of you capapabilities from all 4 sets. If that root task calls execve() the child task will pick up all caps not blocked by the bset. The bset however does not block bits higher than CAP_LAST_CAP. So now the child task has bits in eff which are not in the parent. These are 'meaningless' undefined bits, but still bits which the parent doesn't have. The problem is now in cred_cap_issubset() (or any operation which does a subset test) as the child, while a subset for valid cap bits, is not a subset for invalid cap bits! So now we set durring commit creds that the child is not dumpable. Given it is 'more priv' than its parent. It also means the parent cannot ptrace the child and other stupidity. The solution here: 1) stop hiding capability bits in status This makes debugging easier! 2) stop giving any task undefined capability bits. it's simple, it you don't put those invalid bits in CAP_FULL_SET you won't get them in init and you won't get them in any other task either. This fixes the cap_issubset() tests and resulting fallout (which made the init task in a docker container untraceable among other things) 3) mask out undefined bits when sys_capset() is called as it might use ~0, ~0 to denote 'all capabilities' for backward/forward compatibility. This lets 'capsh --caps="all=eip" -- -c /bin/bash' run. 4) mask out undefined bit when we read a file capability off of disk as again likely all bits are set in the xattr for forward/backward compatibility. This lets 'setcap all+pe /bin/bash; /bin/bash' run Signed-off-by: Eric Paris <eparis@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Andrew Vagin <avagin@openvz.org> Cc: Andrew G. Morgan <morgan@kernel.org> Cc: Serge E. Hallyn <serge.hallyn@canonical.com> Cc: Kees Cook <keescook@chromium.org> Cc: Steve Grubb <sgrubb@redhat.com> Cc: Dan Walsh <dwalsh@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: James Morris <james.l.morris@oracle.com>
* | Merge tag 'keys-next-20140722' of ↵James Morris2014-07-2448-217/+3025
|\ \ | |/ | | | | git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into next
| * Merge branch 'keys-fixes' into keys-nextDavid Howells2014-07-226-3/+20
| |\ | | | | | | | | | Signed-off-by: David Howells <dhowells@redhat.com>
| | * digsig: make crypto builtin if digsig selected as builtinDmitry Kasatkin2014-07-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | When SIGNATURE=y but depends on CRYPTO=m, it selects MPILIB as module producing build break. This patch makes digsig to select crypto for correcting dependency. Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: David Howells <dhowells@redhat.com>
| | * RSA: Don't select non-existent symbolJean Delvare2014-07-171-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | You can select MPILIB_EXTRA all you want, it doesn't exist ;-) Surprised kconfig doesn't complain about that... Signed-off-by: Jean Delvare <jdelvare@suse.de> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: David Howells <dhowells@redhat.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net>
| | * KEYS: Allow special keys (eg. DNS results) to be invalidated by CAP_SYS_ADMINDavid Howells2014-07-174-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Special kernel keys, such as those used to hold DNS results for AFS, CIFS and NFS and those used to hold idmapper results for NFS, used to be 'invalidateable' with key_revoke(). However, since the default permissions for keys were reduced: Commit: 96b5c8fea6c0861621051290d705ec2e971963f1 KEYS: Reduce initial permissions on keys it has become impossible to do this. Add a key flag (KEY_FLAG_ROOT_CAN_INVAL) that will permit a key to be invalidated by root. This should not be used for system keyrings as the garbage collector will try and remove any invalidate key. For system keyrings, KEY_FLAG_ROOT_CAN_CLEAR can be used instead. After this, from userspace, keyctl_invalidate() and "keyctl invalidate" can be used by any possessor of CAP_SYS_ADMIN (typically root) to invalidate DNS and idmapper keys. Invalidated keys are immediately garbage collected and will be immediately rerequested if needed again. Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Steve Dickson <steved@redhat.com>
| * | Merge remote-tracking branch 'integrity/next-with-keys' into keys-nextDavid Howells2014-07-2213-25/+225
| |\ \ | | | | | | | | | | | | Signed-off-by: David Howells <dhowells@redhat.com>
| | * | ima: define '.ima' as a builtin 'trusted' keyringMimi Zohar2014-07-175-2/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Require all keys added to the IMA keyring be signed by an existing trusted key on the system trusted keyring. Changelog v6: - remove ifdef CONFIG_IMA_TRUSTED_KEYRING in C code - Dmitry - update Kconfig dependency and help - select KEYS_DEBUG_PROC_KEYS - Dmitry Changelog v5: - Move integrity_init_keyring() to init_ima() - Dmitry - reset keyring[id] on failure - Dmitry Changelog v1: - don't link IMA trusted keyring to user keyring Changelog: - define stub integrity_init_keyring() function (reported-by Fengguang Wu) - differentiate between regular and trusted keyring names. - replace printk with pr_info (D. Kasatkin) - only make the IMA keyring a trusted keyring (reported-by D. Kastatkin) - define stub integrity_init_keyring() definition based on CONFIG_INTEGRITY_SIGNATURE, not CONFIG_INTEGRITY_ASYMMETRIC_KEYS. (reported-by Jim Davis) Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Acked-by: David Howells <dhowells@redhat.com>
| | * | KEYS: validate certificate trust only with builtin keysDmitry Kasatkin2014-07-174-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed only by builtin keys on the system keyring. This patch defines a new option 'builtin' for the kernel parameter 'keys_ownerid' to allow trust validation using builtin keys. Simplified Mimi's "KEYS: define an owner trusted keyring" patch Changelog v7: - rename builtin_keys to use_builtin_keys Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
| | * | KEYS: validate certificate trust only with selected keyDmitry Kasatkin2014-07-173-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring. This patch defines a new kernel parameter 'ca_keys' to identify the specific key which must be used for trust validation of certificates. Simplified Mimi's "KEYS: define an owner trusted keyring" patch. Changelog: - support for builtin x509 public keys only - export "asymmetric_keyid_match" - remove ifndefs MODULE - rename kernel boot parameter from keys_ownerid to ca_keys Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
| | * | KEYS: make partial key id matching as a dedicated functionDmitry Kasatkin2014-07-172-19/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To avoid code duplication this patch refactors asymmetric_key_match(), making partial ID string match a separate function. This patch also implicitly fixes a bug in the code. asymmetric_key_match() allows to match the key by its subtype. But subtype matching could be undone if asymmetric_key_id(key) would return NULL. This patch first checks for matching spec and then for its value. Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
| | * | KEYS: verify a certificate is signed by a 'trusted' keyMimi Zohar2014-07-172-2/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only public keys, with certificates signed by an existing 'trusted' key on the system trusted keyring, should be added to a trusted keyring. This patch adds support for verifying a certificate's signature. This is derived from David Howells pkcs7_request_asymmetric_key() patch. Changelog v6: - on error free key - Dmitry - validate trust only for not already trusted keys - Dmitry - formatting cleanup Changelog: - define get_system_trusted_keyring() to fix kbuild issues Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
| | * | KEYS: special dot prefixed keyring name bug fixMimi Zohar2014-07-171-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dot prefixed keyring names are supposed to be reserved for the kernel, but add_key() calls key_get_type_from_user(), which incorrectly verifies the 'type' field, not the 'description' field. This patch verifies the 'description' field isn't dot prefixed, when creating a new keyring, and removes the dot prefix test in key_get_type_from_user(). Changelog v6: - whitespace and other cleanup Changelog v5: - Only prevent userspace from creating a dot prefixed keyring, not regular keys - Dmitry Reported-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Acked-by: David Howells <dhowells@redhat.com>
| * | | Merge tag 'keys-pefile-20140709' into keys-nextDavid Howells2014-07-229-2/+1150
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here's a set of changes that implement a PE file signature checker. This provides the following facility: (1) Extract the signature from the PE file. This is a PKCS#7 message containing, as its data, a hash of the signed parts of the file. (2) Digest the signed parts of the file. (3) Compare the digest with the one from the PKCS#7 message. (4) Validate the signatures on the PKCS#7 message and indicate whether it was matched by a trusted key. Signed-off-by: David Howells <dhowells@redhat.com>
| | * | | pefile: Validate PKCS#7 trust chainDavid Howells2014-07-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Validate the PKCS#7 trust chain against the contents of the system keyring. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
| | * | | pefile: Digest the PE binary and compare to the PKCS#7 dataDavid Howells2014-07-091-0/+197
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Digest the signed parts of the PE binary, canonicalising the section table before we need it, and then compare the the resulting digest to the one in the PKCS#7 signed content. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org>
| | * | | pefile: Handle pesign using the wrong OIDVivek Goyal2014-07-091-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pesign utility had a bug where it was using OID_msIndividualSPKeyPurpose instead of OID_msPeImageDataObjId - so allow both OIDs. Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
| | * | | pefile: Parse the "Microsoft individual code signing" data blobDavid Howells2014-07-096-2/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PKCS#7 certificate should contain a "Microsoft individual code signing" data blob as its signed content. This blob contains a digest of the signed content of the PE binary and the OID of the digest algorithm used (typically SHA256). Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org>
| | * | | pefile: Parse the presumed PKCS#7 content of the certificate blobDavid Howells2014-07-091-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Parse the content of the certificate blob, presuming it to be PKCS#7 format. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org>
| | * | | pefile: Strip the wrapper off of the cert data blockDavid Howells2014-07-091-0/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The certificate data block in a PE binary has a wrapper around the PKCS#7 signature we actually want to get at. Strip this off and check that we've got something that appears to be a PKCS#7 signature. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org>
| | * | | pefile: Parse a PE binary to find a key and a signature contained thereinDavid Howells2014-07-095-0/+235
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Parse a PE binary to find a key and a signature contained therein. Later patches will check the signature and add the key if the signature checks out. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org>
| | * | | Provide PE binary definitionsDavid Howells2014-07-091-0/+448
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide some PE binary structural and constant definitions as taken from the pesign package sources. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org>
| | * | | KEYS: X.509: Fix a spelling mistakeDavid Howells2014-07-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
| * | | | Merge tag 'keys-pkcs7-20140708' into keys-nextDavid Howells2014-07-2213-2/+1339
| |\ \ \ \ | | |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here's a set of changes that implement a PKCS#7 message parser in the kernel. The PKCS#7 message parsing will then be used to limit kexec to authenticated kernels only if so configured. The changes provide the following facilities: (1) Parse an ASN.1 PKCS#7 message and pick out useful bits such as the data content and the X.509 certificates used to sign it and all the data signatures. (2) Verify all the data signatures against the set of X.509 certificates available in the message. (3) Follow the certificate chains and verify that: (a) for every self-signed X.509 certificate, check that it validly signed itself, and: (b) for every non-self-signed certificate, if we have a 'parent' certificate, the former is validly signed by the latter. (4) Look for intersections between the certificate chains and the trusted keyring, if any intersections are found, verify that the trusted certificates signed the intersection point in the chain. (5) For testing purposes, a key type can be made available that will take a PKCS#7 message, check that the message is trustworthy, and if so, add its data content into the key. Note that (5) has to be altered to take account of the preparsing patches already committed to this branch. Signed-off-by: David Howells <dhowells@redhat.com>
| | * | | PKCS#7: Provide a key type for testing PKCS#7David Howells2014-07-083-0/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide a key type for testing the PKCS#7 parser. It is given a non-detached PKCS#7 message as payload: keyctl padd pkcs7_test a @s <stuff.pkcs7 The PKCS#7 wrapper is validated against the trusted certificates available and then stripped off. If successful, the key can be read, which will give the data content of the PKCS#7 message. A suitable message can be created by running make on the attached Makefile. This will produce a file called stuff.pkcs7 for test loading. The key3.x509 file should be put into the kernel source tree before it is built and converted to DER form: openssl x509 -in .../pkcs7/key3.x509 -outform DER -out key3.x509 ############################################################################### # # Create a pkcs7 message and sign it twice # # openssl x509 -text -inform PEM -noout -in key2.x509 # ############################################################################### stuff.pkcs7: stuff.txt key2.priv key2.x509 key4.priv key4.x509 certs $(RM) $@ openssl smime -sign \ -signer key2.x509 \ -inkey key2.priv \ -signer key4.x509 \ -inkey key4.priv \ -in stuff.txt \ -certfile certs \ -out $@ -binary -outform DER -nodetach openssl pkcs7 -inform DER -in stuff.pkcs7 -print_certs -noout openssl asn1parse -inform DER -in stuff.pkcs7 -i >out stuff.txt: echo "The quick red fox jumped over the lazy brown dog" >stuff.txt certs: key1.x509 key2.x509 key3.x509 key4.x509 cat key{1,3}.x509 >$@ ############################################################################### # # Generate a signed key # # openssl x509 -text -inform PEM -noout -in key2.x509 # ############################################################################### key2.x509: key2.x509_unsigned key1.priv key1.x509 openssl x509 \ -req -in key2.x509_unsigned \ -out key2.x509 \ -extfile key2.genkey -extensions myexts \ -CA key1.x509 \ -CAkey key1.priv \ -CAcreateserial key2.priv key2.x509_unsigned: key2.genkey openssl req -new -nodes -utf8 -sha1 -days 36500 \ -batch -outform PEM \ -config key2.genkey \ -keyout key2.priv \ -out key2.x509_unsigned key2.genkey: @echo Generating X.509 key generation config @echo >$@ "[ req ]" @echo >>$@ "default_bits = 4096" @echo >>$@ "distinguished_name = req_distinguished_name" @echo >>$@ "prompt = no" @echo >>$@ "string_mask = utf8only" @echo >>$@ "x509_extensions = myexts" @echo >>$@ @echo >>$@ "[ req_distinguished_name ]" @echo >>$@ "O = Magrathea" @echo >>$@ "CN = PKCS7 key 2" @echo >>$@ "emailAddress = slartibartfast@magrathea.h2g2" @echo >>$@ @echo >>$@ "[ myexts ]" @echo >>$@ "basicConstraints=critical,CA:FALSE" @echo >>$@ "keyUsage=digitalSignature" @echo >>$@ "subjectKeyIdentifier=hash" @echo >>$@ "authorityKeyIdentifier=keyid" ############################################################################### # # Generate a couple of signing keys # # openssl x509 -text -inform PEM -noout -in key1.x509 # ############################################################################### key1.x509: key1.x509_unsigned key4.priv key4.x509 openssl x509 \ -req -in key1.x509_unsigned \ -out key1.x509 \ -extfile key1.genkey -extensions myexts \ -CA key4.x509 \ -CAkey key4.priv \ -CAcreateserial key1.priv key1.x509_unsigned: key1.genkey openssl req -new -nodes -utf8 -sha1 -days 36500 \ -batch -outform PEM \ -config key1.genkey \ -keyout key1.priv \ -out key1.x509_unsigned key1.genkey: @echo Generating X.509 key generation config @echo >$@ "[ req ]" @echo >>$@ "default_bits = 4096" @echo >>$@ "distinguished_name = req_distinguished_name" @echo >>$@ "prompt = no" @echo >>$@ "string_mask = utf8only" @echo >>$@ "x509_extensions = myexts" @echo >>$@ @echo >>$@ "[ req_distinguished_name ]" @echo >>$@ "O = Magrathea" @echo >>$@ "CN = PKCS7 key 1" @echo >>$@ "emailAddress = slartibartfast@magrathea.h2g2" @echo >>$@ @echo >>$@ "[ myexts ]" @echo >>$@ "basicConstraints=critical,CA:TRUE" @echo >>$@ "keyUsage=digitalSignature,keyCertSign" @echo >>$@ "subjectKeyIdentifier=hash" @echo >>$@ "authorityKeyIdentifier=keyid" ############################################################################### # # Generate a signed key # # openssl x509 -text -inform PEM -noout -in key4.x509 # ############################################################################### key4.x509: key4.x509_unsigned key3.priv key3.x509 openssl x509 \ -req -in key4.x509_unsigned \ -out key4.x509 \ -extfile key4.genkey -extensions myexts \ -CA key3.x509 \ -CAkey key3.priv \ -CAcreateserial key4.priv key4.x509_unsigned: key4.genkey openssl req -new -nodes -utf8 -sha1 -days 36500 \ -batch -outform PEM \ -config key4.genkey \ -keyout key4.priv \ -out key4.x509_unsigned key4.genkey: @echo Generating X.509 key generation config @echo >$@ "[ req ]" @echo >>$@ "default_bits = 4096" @echo >>$@ "distinguished_name = req_distinguished_name" @echo >>$@ "prompt = no" @echo >>$@ "string_mask = utf8only" @echo >>$@ "x509_extensions = myexts" @echo >>$@ @echo >>$@ "[ req_distinguished_name ]" @echo >>$@ "O = Magrathea" @echo >>$@ "CN = PKCS7 key 4" @echo >>$@ "emailAddress = slartibartfast@magrathea.h2g2" @echo >>$@ @echo >>$@ "[ myexts ]" @echo >>$@ "basicConstraints=critical,CA:TRUE" @echo >>$@ "keyUsage=digitalSignature,keyCertSign" @echo >>$@ "subjectKeyIdentifier=hash" @echo >>$@ "authorityKeyIdentifier=keyid" ############################################################################### # # Generate a couple of signing keys # # openssl x509 -text -inform PEM -noout -in key3.x509 # ############################################################################### key3.priv key3.x509: key3.genkey openssl req -new -nodes -utf8 -sha1 -days 36500 \ -batch -x509 -outform PEM \ -config key3.genkey \ -keyout key3.priv \ -out key3.x509 key3.genkey: @echo Generating X.509 key generation config @echo >$@ "[ req ]" @echo >>$@ "default_bits = 4096" @echo >>$@ "distinguished_name = req_distinguished_name" @echo >>$@ "prompt = no" @echo >>$@ "string_mask = utf8only" @echo >>$@ "x509_extensions = myexts" @echo >>$@ @echo >>$@ "[ req_distinguished_name ]" @echo >>$@ "O = Magrathea" @echo >>$@ "CN = PKCS7 key 3" @echo >>$@ "emailAddress = slartibartfast@magrathea.h2g2" @echo >>$@ @echo >>$@ "[ myexts ]" @echo >>$@ "basicConstraints=critical,CA:TRUE" @echo >>$@ "keyUsage=digitalSignature,keyCertSign" @echo >>$@ "subjectKeyIdentifier=hash" @echo >>$@ "authorityKeyIdentifier=keyid" clean: $(RM) *~ $(RM) key1.* key2.* key3.* key4.* stuff.* out certs Signed-off-by: David Howells <dhowells@redhat.com>
| | * | | PKCS#7: Find intersection between PKCS#7 message and known, trusted keysDavid Howells2014-07-083-0/+228
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Find the intersection between the X.509 certificate chain contained in a PKCS#7 message and a set of keys that we already know and trust. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org>
| | * | | PKCS#7: Verify internal certificate chainDavid Howells2014-07-081-1/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Verify certificate chain in the X.509 certificates contained within the PKCS#7 message as far as possible. If any signature that we should be able to verify fails, we reject the whole lot. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org>
| | * | | PKCS#7: Find the right key in the PKCS#7 key list and verify the signatureDavid Howells2014-07-082-0/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Find the appropriate key in the PKCS#7 key list and verify the signature with it. There may be several keys in there forming a chain. Any link in that chain or the root of that chain may be in our keyrings. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org>
| | * | | PKCS#7: Digest the data in a signed-data messageDavid Howells2014-07-082-1/+175
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Digest the data in a PKCS#7 signed-data message and attach to the public_key_signature struct contained in the pkcs7_message struct. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org>
| | * | | PKCS#7: Implement a parser [RFC 2315]David Howells2014-07-087-0/+630
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement a parser for a PKCS#7 signed-data message as described in part of RFC 2315. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org>
| | * | | X.509: Export certificate parse and free functionsDavid Howells2014-07-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Export certificate parse and free functions for use by modules. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Josh Boyer <jwboyer@redhat.com>
| | * | | X.509: Add bits needed for PKCS#7David Howells2014-07-013-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PKCS#7 validation requires access to the serial number and the raw names in an X.509 certificate. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Josh Boyer <jwboyer@redhat.com>
| * | | | Merge tag 'keys-preparse-1-20140722' into keys-nextDavid Howells2014-07-2216-185/+291
| |\ \ \ \ | | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here are a set of changes that make all but encrypted and trusted keys use preparsing. Unfortunately, encrypted and trusted keys incorrectly use the update op to alter a key, so other changes will need to be made for them. These changes permit payload parsing when instantiating or updating a key to be done before locks are taken and to determine the amount of quota that will be required in advance. The latter will make it possible to do LRU discard before any locks are taken. Signed-off-by: David Howells <dhowells@redhat.com>
| | * | | KEYS: request_key_auth: Provide key preparsingDavid Howells2014-07-221-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide key preparsing for the request_key_auth key type so that we can make preparsing mandatory. This does nothing as this type can only be set up internally to the kernel. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Steve Dickson <steved@redhat.com> Acked-by: Jeff Layton <jlayton@primarydata.com>
| | * | | KEYS: keyring: Provide key preparsingDavid Howells2014-07-221-11/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide key preparsing in the keyring so that we can make preparsing mandatory. For keyrings, however, only an empty payload is permitted. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Steve Dickson <steved@redhat.com> Acked-by: Jeff Layton <jlayton@primarydata.com>
| | * | | KEYS: big_key: Use key preparsingDavid Howells2014-07-222-17/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make use of key preparsing in the big key type so that quota size determination can take place prior to keyring locking when a key is being added. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Steve Dickson <steved@redhat.com>
| | * | | KEYS: RxRPC: Use key preparsingDavid Howells2014-07-221-68/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make use of key preparsing in the RxRPC protocol so that quota size determination can take place prior to keyring locking when a key is being added. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Steve Dickson <steved@redhat.com>
| | * | | KEYS: DNS: Use key preparsingDavid Howells2014-07-221-18/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make use of key preparsing in the DNS resolver so that quota size determination can take place prior to keyring locking when a key is being added. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Steve Dickson <steved@redhat.com> Acked-by: Jeff Layton <jlayton@primarydata.com>
| | * | | KEYS: Ceph: Use user_match()David Howells2014-07-221-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ceph can use user_match() instead of defining its own identical function. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Steve Dickson <steved@redhat.com> Reviewed-by: Sage Weil <sage@redhat.com> cc: Tommi Virtanen <tommi.virtanen@dreamhost.com>
| | * | | KEYS: Ceph: Use key preparsingDavid Howells2014-07-221-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make use of key preparsing in Ceph so that quota size determination can take place prior to keyring locking when a key is being added. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Steve Dickson <steved@redhat.com> Reviewed-by: Sage Weil <sage@redhat.com> cc: Tommi Virtanen <tommi.virtanen@dreamhost.com>
OpenPOWER on IntegriCloud