14 Jun, 2016
1 commit
-
Strip some trailing spaces.
Signed-off-by: David Howells
12 Apr, 2016
6 commits
-
Add a config option (IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY)
that, when enabled, allows keys to be added to the IMA keyrings by
userspace - with the restriction that each must be signed by a key in the
system trusted keyrings.EPERM will be returned if this option is disabled, ENOKEY will be returned if
no authoritative key can be found and EKEYREJECTED will be returned if the
signature doesn't match. Other errors such as ENOPKG may also be returned.If this new option is enabled, the builtin system keyring is searched, as is
the secondary system keyring if that is also enabled. Intermediate keys
between the builtin system keyring and the key being added can be added to
the secondary keyring (which replaces .ima_mok) to form a trust chain -
provided they are also validly signed by a key in one of the trusted keyrings.The .ima_mok keyring is then removed and the IMA blacklist keyring gets its
own config option (IMA_BLACKLIST_KEYRING).Signed-off-by: David Howells
Signed-off-by: Mimi Zohar -
Add a secondary system keyring that can be added to by root whilst the
system is running - provided the key being added is vouched for by a key
built into the kernel or already added to the secondary keyring.Rename .system_keyring to .builtin_trusted_keys to distinguish it more
obviously from the new keyring (called .secondary_trusted_keys).The new keyring needs to be enabled with CONFIG_SECONDARY_TRUSTED_KEYRING.
If the secondary keyring is enabled, a link is created from that to
.builtin_trusted_keys so that the the latter will automatically be searched
too if the secondary keyring is searched.Signed-off-by: David Howells
-
Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED as they're no longer
meaningful. Also we can drop the trusted flag from the preparse structure.Given this, we no longer need to pass the key flags through to
restrict_link().Further, we can now get rid of keyring_restrict_trusted_only() also.
Signed-off-by: David Howells
-
Move the point at which a key is determined to be trustworthy to
__key_link() so that we use the contents of the keyring being linked in to
to determine whether the key being linked in is trusted or not.What is 'trusted' then becomes a matter of what's in the keyring.
Currently, the test is done when the key is parsed, but given that at that
point we can only sensibly refer to the contents of the system trusted
keyring, we can only use that as the basis for working out the
trustworthiness of a new key.With this change, a trusted keyring is a set of keys that once the
trusted-only flag is set cannot be added to except by verification through
one of the contained keys.Further, adding a key into a trusted keyring, whilst it might grant
trustworthiness in the context of that keyring, does not automatically
grant trustworthiness in the context of a second keyring to which it could
be secondarily linked.To accomplish this, the authentication data associated with the key source
must now be retained. For an X.509 cert, this means the contents of the
AuthorityKeyIdentifier and the signature data.If system keyrings are disabled then restrict_link_by_builtin_trusted()
resolves to restrict_link_reject(). The integrity digital signature code
still works correctly with this as it was previously using
KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there
is no system keyring against which trust can be determined.Signed-off-by: David Howells
-
Generalise x509_request_asymmetric_key(). It doesn't really have any
dependencies on X.509 features as it uses generalised IDs and the
public_key structs that contain data extracted from X.509.Signed-off-by: David Howells
-
Move x509_request_asymmetric_key() to asymmetric_type.c so that it can be
generalised.Signed-off-by: David Howells
06 Apr, 2016
2 commits
-
Generalise system_verify_data() to provide access to internal content
through a callback. This allows all the PKCS#7 stuff to be hidden inside
this function and removed from the PE file parser and the PKCS#7 test key.If external content is not required, NULL should be passed as data to the
function. If the callback is not required, that can be set to NULL.The function is now called verify_pkcs7_signature() to contrast with
verify_pefile_signature() and the definitions of both have been moved into
linux/verification.h along with the key_being_used_for enum.Signed-off-by: David Howells
-
Allow authentication data to be stored in an asymmetric key in the 4th
element of the key payload and provide a way for it to be destroyed.For the public key subtype, this will be a public_key_signature struct.
Signed-off-by: David Howells
10 Feb, 2016
1 commit
-
In my original patch sealing with policy was done with dynamically
allocated buffer that I changed later into an array so the checks in
tpm2-cmd.c became invalid. This patch fixes the issue.Fixes: 5beb0c435bdd ("keys, trusted: seal with a TPM2 authorization policy")
Reported-by: Dan Carpenter
Signed-off-by: Jarkko Sakkinen
Acked-by: Peter Huewe
26 Dec, 2015
1 commit
20 Dec, 2015
2 commits
-
TPM2 supports authorization policies, which are essentially
combinational logic statements repsenting the conditions where the data
can be unsealed based on the TPM state. This patch enables to use
authorization policies to seal trusted keys.Two following new options have been added for trusted keys:
* 'policydigest=': provide an auth policy digest for sealing.
* 'policyhandle=': provide a policy session handle for unsealing.If 'hash=' option is supplied after 'policydigest=' option, this
will result an error because the state of the option would become
mixed.Signed-off-by: Jarkko Sakkinen
Tested-by: Colin Ian King
Reviewed-by: Mimi Zohar
Acked-by: Peter Huewe -
Added 'hash=' option for selecting the hash algorithm for add_key()
syscall and documentation for it.Added entry for sm3-256 to the following tables in order to support
TPM_ALG_SM3_256:* hash_algo_name
* hash_digest_sizeIncludes support for the following hash algorithms:
* sha1
* sha256
* sha384
* sha512
* sm3-256Signed-off-by: Jarkko Sakkinen
Tested-by: Colin Ian King
Reviewed-by: James Morris
Reviewed-by: Mimi Zohar
Acked-by: Peter Huewe
15 Dec, 2015
1 commit
-
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
Signed-off-by: Mimi Zohar
21 Oct, 2015
1 commit
-
Merge the type-specific data with the payload data into one four-word chunk
as it seems pointless to keep them separate.Use user_key_payload() for accessing the payloads of overloaded
user-defined keys.Signed-off-by: David Howells
cc: linux-cifs@vger.kernel.org
cc: ecryptfs@vger.kernel.org
cc: linux-ext4@vger.kernel.org
cc: linux-f2fs-devel@lists.sourceforge.net
cc: linux-nfs@vger.kernel.org
cc: ceph-devel@vger.kernel.org
cc: linux-ima-devel@lists.sourceforge.net
19 Oct, 2015
2 commits
-
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
Signed-off-by: Peter Huewe -
Moved struct trusted_key_options to trustes-type.h so that the fields
can be accessed from drivers/char/tpm.Signed-off-by: Jarkko Sakkinen
Signed-off-by: Peter Huewe
13 Aug, 2015
1 commit
-
A PKCS#7 or CMS message can have per-signature authenticated attributes
that are digested as a lump and signed by the authorising key for that
signature. If such attributes exist, the content digest isn't itself
signed, but rather it is included in a special authattr which then
contributes to the signature.Further, we already require the master message content type to be
pkcs7_signedData - but there's also a separate content type for the data
itself within the SignedData object and this must be repeated inside the
authattrs for each signer [RFC2315 9.2, RFC5652 11.1].We should really validate the authattrs if they exist or forbid them
entirely as appropriate. To this end:(1) Alter the PKCS#7 parser to reject any message that has more than one
signature where at least one signature has authattrs and at least one
that does not.(2) Validate authattrs if they are present and strongly restrict them.
Only the following authattrs are permitted and all others are
rejected:(a) contentType. This is checked to be an OID that matches the
content type in the SignedData object.(b) messageDigest. This must match the crypto digest of the data.
(c) signingTime. If present, we check that this is a valid, parseable
UTCTime or GeneralTime and that the date it encodes fits within
the validity window of the matching X.509 cert.(d) S/MIME capabilities. We don't check the contents.
(e) Authenticode SP Opus Info. We don't check the contents.
(f) Authenticode Statement Type. We don't check the contents.
The message is rejected if (a) or (b) are missing. If the message is
an Authenticode type, the message is rejected if (e) is missing; if
not Authenticode, the message is rejected if (d) - (f) are present.The S/MIME capabilities authattr (d) unfortunately has to be allowed
to support kernels already signed by the pesign program. This only
affects kexec. sign-file suppresses them (CMS_NOSMIMECAP).The message is also rejected if an authattr is given more than once or
if it contains more than one element in its set of values.(3) Add a parameter to pkcs7_verify() to select one of the following
restrictions and pass in the appropriate option from the callers:(*) VERIFYING_MODULE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
forbids authattrs. sign-file sets CMS_NOATTR. We could be more
flexible and permit authattrs optionally, but only permit minimal
content.(*) VERIFYING_FIRMWARE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
requires authattrs. In future, this will require an attribute
holding the target firmware name in addition to the minimal set.(*) VERIFYING_UNSPECIFIED_SIGNATURE
This requires that the SignedData content type be pkcs7-data but
allows either no authattrs or only permits the minimal set.(*) VERIFYING_KEXEC_PE_SIGNATURE
This only supports the Authenticode SPC_INDIRECT_DATA content type
and requires at least an SpcSpOpusInfo authattr in addition to the
minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and
an S/MIME capabilities authattr because the pesign program doesn't
remove these).(*) VERIFYING_KEY_SIGNATURE
(*) VERIFYING_KEY_SELF_SIGNATUREThese are invalid in this context but are included for later use
when limiting the use of X.509 certs.(4) The pkcs7_test key type is given a module parameter to select between
the above options for testing purposes. For example:echo 1 >/sys/module/pkcs7_test_key/parameters/usage
keyctl padd pkcs7_test foo @s
Signed-off-by: David Howells
Reviewed-by: Marcel Holtmann
Reviewed-by: David Woodhouse
07 Aug, 2015
1 commit
-
Extract the function that drives the PKCS#7 signature verification given a
data blob and a PKCS#7 blob out from the module signing code and lump it with
the system keyring code as it's generic. This makes it independent of module
config options and opens it to use by the firmware loader.Signed-off-by: David Howells
Cc: Luis R. Rodriguez
Cc: Rusty Russell
Cc: Ming Lei
Cc: Seth Forshee
Cc: Kyle McMartin
06 Oct, 2014
1 commit
-
Bring back the functionality whereby an asymmetric key can be matched with a
partial match on one of its IDs.Whilst we're at it, allow for the possibility of having an increased number of
IDs.Reported-by: Dmitry Kasatkin
Signed-off-by: Dmitry Kasatkin
Signed-off-by: David Howells
17 Sep, 2014
3 commits
-
Implement the first step in using binary key IDs for asymmetric keys rather
than hex string keys.The previously added match data preparsing will be able to convert hex
criterion strings into binary which can then be compared more rapidly.Further, we actually want more then one ID string per public key. The problem
is that X.509 certs refer to other X.509 certs by matching Issuer + AuthKeyId
to Subject + SubjKeyId, but PKCS#7 messages match against X.509 Issuer +
SerialNumber.This patch just provides facilities for a later patch to make use of.
Signed-off-by: David Howells
Acked-by: Vivek Goyal -
A previous patch added a ->match_preparse() method to the key type. This is
allowed to override the function called by the iteration algorithm.
Therefore, we can just set a default that simply checks for an exact match of
the key description with the original criterion data and allow match_preparse
to override it as needed.The key_type::match op is then redundant and can be removed, as can the
user_match() function.Signed-off-by: David Howells
Acked-by: Vivek Goyal -
Preparse the match data. This provides several advantages:
(1) The preparser can reject invalid criteria up front.
(2) The preparser can convert the criteria to binary data if necessary (the
asymmetric key type really wants to do binary comparison of the key IDs).(3) The preparser can set the type of search to be performed. This means
that it's not then a one-off setting in the key type.(4) The preparser can set an appropriate comparator function.
Signed-off-by: David Howells
Acked-by: Vivek Goyal
23 Jul, 2014
3 commits
-
Signed-off-by: David Howells
-
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
Acked-by: Steve Dickson -
Make use of key preparsing in user-defined and logon keys so that quota size
determination can take place prior to keyring locking when a key is being
added.Also the idmapper key types need to change to match as they use the
user-defined key type routines.Signed-off-by: David Howells
Acked-by: Steve Dickson
Acked-by: Jeff Layton
17 Jul, 2014
1 commit
-
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 cleanupChangelog:
- define get_system_trusted_keyring() to fix kbuild issuesSigned-off-by: Mimi Zohar
Signed-off-by: David Howells
Acked-by: Dmitry Kasatkin
26 Sep, 2013
1 commit
-
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
24 Sep, 2013
2 commits
-
Implement a big key type that can save its contents to tmpfs and thus
swapspace when memory is tight. This is useful for Kerberos ticket caches.Signed-off-by: David Howells
Tested-by: Simo Sorce -
Expand the capacity of a keyring to be able to hold a lot more keys by using
the previously added associative array implementation. Currently the maximum
capacity is:(PAGE_SIZE - sizeof(header)) / sizeof(struct key *)
which, on a 64-bit system, is a little more 500. However, since this is being
used for the NFS uid mapper, we need more than that. The new implementation
gives us effectively unlimited capacity.With some alterations, the keyutils testsuite runs successfully to completion
after this patch is applied. The alterations are because (a) keyrings that
are simply added to no longer appear ordered and (b) some of the errors have
changed a bit.Signed-off-by: David Howells
08 Oct, 2012
3 commits
-
The instantiation data passed to the asymmetric key type are expected to be
formatted in some way, and there are several possible standard ways to format
the data.The two obvious standards are OpenPGP keys and X.509 certificates. The latter
is especially useful when dealing with UEFI, and the former might be useful
when dealing with, say, eCryptfs.Further, it might be desirable to provide formatted blobs that indicate
hardware is to be accessed to retrieve the keys or that the keys live
unretrievably in a hardware store, but that the keys can be used by means of
the hardware.From userspace, the keys can be loaded using the keyctl command, for example,
an X.509 binary certificate:keyctl padd asymmetric foo @s
Signed-off-by: Rusty Russell -
Create a key type that can be used to represent an asymmetric key type for use
in appropriate cryptographic operations, such as encryption, decryption,
signature generation and signature verification.The key type is "asymmetric" and can provide access to a variety of
cryptographic algorithms.Possibly, this would be better as "public_key" - but that has the disadvantage
that "public key" is an overloaded term.Signed-off-by: David Howells
Signed-off-by: Rusty Russell -
Give the key type the opportunity to preparse the payload prior to the
instantiation and update routines being called. This is done with the
provision of two new key type operations:int (*preparse)(struct key_preparsed_payload *prep);
void (*free_preparse)(struct key_preparsed_payload *prep);If the first operation is present, then it is called before key creation (in
the add/update case) or before the key semaphore is taken (in the update and
instantiate cases). The second operation is called to clean up if the first
was called.preparse() is given the opportunity to fill in the following structure:
struct key_preparsed_payload {
char *description;
void *type_data[2];
void *payload;
const void *data;
size_t datalen;
size_t quotalen;
};Before the preparser is called, the first three fields will have been cleared,
the payload pointer and size will be stored in data and datalen and the default
quota size from the key_type struct will be stored into quotalen.The preparser may parse the payload in any way it likes and may store data in
the type_data[] and payload fields for use by the instantiate() and update()
ops.The preparser may also propose a description for the key by attaching it as a
string to the description field. This can be used by passing a NULL or ""
description to the add_key() system call or the key_create_or_update()
function. This cannot work with request_key() as that required the description
to tell the upcall about the key to be created.This, for example permits keys that store PGP public keys to generate their own
name from the user ID and public key fingerprint in the key.The instantiate() and update() operations are then modified to look like this:
int (*instantiate)(struct key *key, struct key_preparsed_payload *prep);
int (*update)(struct key *key, struct key_preparsed_payload *prep);and the new payload data is passed in *prep, whether or not it was preparsed.
Signed-off-by: David Howells
Signed-off-by: Rusty Russell
11 May, 2012
1 commit
-
Make use of the previous patch that makes the garbage collector perform RCU
synchronisation before destroying defunct keys. Key pointers can now be
replaced in-place without creating a new keyring payload and replacing the
whole thing as the discarded keys will not be destroyed until all currently
held RCU read locks are released.If the keyring payload space needs to be expanded or contracted, then a
replacement will still need allocating, and the original will still have to be
freed by RCU.Signed-off-by: David Howells
18 Jan, 2012
1 commit
-
For CIFS, we want to be able to store NTLM credentials (aka username
and password) in the keyring. We do not, however want to allow users
to fetch those keys back out of the keyring since that would be a
security risk.Unfortunately, due to the nuances of key permission bits, it's not
possible to do this. We need to grant search permissions so the kernel
can find these keys, but that also implies permissions to read the
payload.Resolve this by adding a new key_type. This key type is essentially
the same as key_type_user, but does not define a .read op. This
prevents the payload from ever being visible from userspace. This
key type also vets the description to ensure that it's "qualified"
by checking to ensure that it has a ':' in it that is preceded by
other characters.Acked-by: David Howells
Signed-off-by: Jeff Layton
Signed-off-by: Steve French
27 Jun, 2011
1 commit
-
This patch introduces a new parameter, called 'format', that defines the
format of data stored by encrypted keys. The 'default' format identifies
encrypted keys containing only the symmetric key, while other formats can
be defined to support additional information. The 'format' parameter is
written in the datablob produced by commands 'keyctl print' or
'keyctl pipe' and is integrity protected by the HMAC.Signed-off-by: Roberto Sassu
Acked-by: Gianluca Ramunno
Acked-by: David Howells
Signed-off-by: Mimi Zohar
30 Mar, 2011
1 commit
-
This allows us to use existence of the key type as a feature test,
from userspace.Signed-off-by: Tommi Virtanen
Signed-off-by: Sage Weil
03 Mar, 2011
1 commit
-
commit 339412841d7 (RxRPC: Allow key payloads to be passed in XDR form)
broke klog for me. I notice the v1 key struct had a kif_version field
added:-struct rxkad_key {
- u16 security_index; /* RxRPC header security index */
- u16 ticket_len; /* length of ticket[] */
- u32 expiry; /* time at which expires */
- u32 kvno; /* key version number */
- u8 session_key[8]; /* DES session key */
- u8 ticket[0]; /* the encrypted ticket */
-};+struct rxrpc_key_data_v1 {
+ u32 kif_version; /* 1 */
+ u16 security_index;
+ u16 ticket_length;
+ u32 expiry; /* time_t */
+ u32 kvno;
+ u8 session_key[8];
+ u8 ticket[0];
+};However the code in rxrpc_instantiate strips it away:
data += sizeof(kver);
datalen -= sizeof(kver);Removing kif_version fixes my problem.
Signed-off-by: Anton Blanchard
Signed-off-by: David Howells
Signed-off-by: David S. Miller
29 Nov, 2010
2 commits
-
Define a new kernel key-type called 'encrypted'. Encrypted keys are kernel
generated random numbers, which are encrypted/decrypted with a 'trusted'
symmetric key. Encrypted keys are created/encrypted/decrypted in the kernel.
Userspace only ever sees/stores encrypted blobs.Changelog:
- bug fix: replaced master-key rcu based locking with semaphore
(reported by David Howells)
- Removed memset of crypto_shash_digest() digest output
- Replaced verification of 'key-type:key-desc' using strcspn(), with
one based on string constants.
- Moved documentation to Documentation/keys-trusted-encrypted.txt
- Replace hash with shash (based on comments by David Howells)
- Make lengths/counts size_t where possible (based on comments by David Howells)
Could not convert most lengths, as crypto expects 'unsigned int'
(size_t: on 32 bit is defined as unsigned int, but on 64 bit is unsigned long)
- Add 'const' where possible (based on comments by David Howells)
- allocate derived_buf dynamically to support arbitrary length master key
(fixed by Roberto Sassu)
- wait until late_initcall for crypto libraries to be registered
- cleanup security/Kconfig
- Add missing 'update' keyword (reported/fixed by Roberto Sassu)
- Free epayload on failure to create key (reported/fixed by Roberto Sassu)
- Increase the data size limit (requested by Roberto Sassu)
- Crypto return codes are always 0 on success and negative on failure,
remove unnecessary tests.
- Replaced kzalloc() with kmalloc()Signed-off-by: Mimi Zohar
Signed-off-by: David Safford
Reviewed-by: Roberto Sassu
Signed-off-by: James Morris -
Define a new kernel key-type called 'trusted'. Trusted keys are random
number symmetric keys, generated and RSA-sealed by the TPM. The TPM
only unseals the keys, if the boot PCRs and other criteria match.
Userspace can only ever see encrypted blobs.Based on suggestions by Jason Gunthorpe, several new options have been
added to support additional usages.The new options are:
migratable= designates that the key may/may not ever be updated
(resealed under a new key, new pcrinfo or new auth.)pcrlock=n extends the designated PCR 'n' with a random value,
so that a key sealed to that PCR may not be unsealed
again until after a reboot.keyhandle= specifies the sealing/unsealing key handle.
keyauth= specifies the sealing/unsealing key auth.
blobauth= specifies the sealed data auth.
Implementation of a kernel reserved locality for trusted keys will be
investigated for a possible future extension.Changelog:
- Updated and added examples to Documentation/keys-trusted-encrypted.txt
- Moved generic TPM constants to include/linux/tpm_command.h
(David Howell's suggestion.)
- trusted_defined.c: replaced kzalloc with kmalloc, added pcrlock failure
error handling, added const qualifiers where appropriate.
- moved to late_initcall
- updated from hash to shash (suggestion by David Howells)
- reduced worst stack usage (tpm_seal) from 530 to 312 bytes
- moved documentation to Documentation directory (suggestion by David Howells)
- all the other code cleanups suggested by David Howells
- Add pcrlock CAP_SYS_ADMIN dependency (based on comment by Jason Gunthorpe)
- New options: migratable, pcrlock, keyhandle, keyauth, blobauth (based on
discussions with Jason Gunthorpe)
- Free payload on failure to create key(reported/fixed by Roberto Sassu)
- Updated Kconfig and other descriptions (based on Serge Hallyn's suggestion)
- Replaced kzalloc() with kmalloc() (reported by Serge Hallyn)Signed-off-by: David Safford
Signed-off-by: Mimi Zohar
Signed-off-by: James Morris