02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
29 Aug, 2017
1 commit
-
Since the 'expiry' variable of 'struct key_preparsed_payload' has been
changed to 'time64_t' type, which is year 2038 safe on 32bits system.In net/rxrpc subsystem, we need convert 'u32' type to 'time64_t' type
when copying ticket expires time to 'prep->expiry', then this patch
introduces two helper functions to help convert 'u32' to 'time64_t'
type.This patch also uses ktime_get_real_seconds() to get current time instead
of get_seconds() which is not year 2038 safe on 32bits system.Signed-off-by: Baolin Wang
Signed-off-by: David Howells
04 Apr, 2017
1 commit
-
The first argument to the restrict_link_func_t functions was a keyring
pointer. These functions are called by the key subsystem with this
argument set to the destination keyring, but restrict_link_by_signature
expects a pointer to the relevant trusted keyring.Restrict functions may need something other than a single struct key
pointer to allow or reject key linkage, so the data used to make that
decision (such as the trust keyring) is moved to a new, fourth
argument. The first argument is now always the destination keyring.Signed-off-by: Mat Martineau
03 Apr, 2017
1 commit
-
Add the following:
(1) A new system keyring that is used to store information about
blacklisted certificates and signatures.(2) A new key type (called 'blacklist') that is used to store a
blacklisted hash in its description as a hex string. The key accepts
no payload.(3) The ability to configure a list of blacklisted hashes into the kernel
at build time. This is done by setting
CONFIG_SYSTEM_BLACKLIST_HASH_LIST to the filename of a list of hashes
that are in the form:"", "", ..., ""
where each is a hex string representation of the hash and must
include all necessary leading zeros to pad the hash to the right size.The above are enabled with CONFIG_SYSTEM_BLACKLIST_KEYRING.
Once the kernel is booted, the blacklist keyring can be listed:
root@andromeda ~]# keyctl show %:.blacklist
Keyring
723359729 ---lswrv 0 0 keyring: .blacklist
676257228 ---lswrv 0 0 \_ blacklist: 123412341234c55c1dcc601ab8e172917706aa32fb5eaf826813547fdf02dd46The blacklist cannot currently be modified by userspace, but it will be
possible to load it, for example, from the UEFI blacklist database.A later commit will make it possible to load blacklisted asymmetric keys in
here too.Signed-off-by: David Howells
02 Mar, 2017
1 commit
-
rcu_dereference_key() and user_key_payload() are currently being used in
two different, incompatible ways:(1) As a wrapper to rcu_dereference() - when only the RCU read lock used
to protect the key.(2) As a wrapper to rcu_dereference_protected() - when the key semaphor is
used to protect the key and the may be being modified.Fix this by splitting both of the key wrappers to produce:
(1) RCU accessors for keys when caller has the key semaphore locked:
dereference_key_locked()
user_key_payload_locked()(2) RCU accessors for keys when caller holds the RCU read lock:
dereference_key_rcu()
user_key_payload_rcu()This should fix following warning in the NFS idmapper
===============================
[ INFO: suspicious RCU usage. ]
4.10.0 #1 Tainted: G W
-------------------------------
./include/keys/user-type.h:53 suspicious rcu_dereference_protected() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 0
1 lock held by mount.nfs/5987:
#0: (rcu_read_lock){......}, at: [] nfs_idmap_get_key+0x15c/0x420 [nfsv4]
stack backtrace:
CPU: 1 PID: 5987 Comm: mount.nfs Tainted: G W 4.10.0 #1
Call Trace:
dump_stack+0xe8/0x154 (unreliable)
lockdep_rcu_suspicious+0x140/0x190
nfs_idmap_get_key+0x380/0x420 [nfsv4]
nfs_map_name_to_uid+0x2a0/0x3b0 [nfsv4]
decode_getfattr_attrs+0xfac/0x16b0 [nfsv4]
decode_getfattr_generic.constprop.106+0xbc/0x150 [nfsv4]
nfs4_xdr_dec_lookup_root+0xac/0xb0 [nfsv4]
rpcauth_unwrap_resp+0xe8/0x140 [sunrpc]
call_decode+0x29c/0x910 [sunrpc]
__rpc_execute+0x140/0x8f0 [sunrpc]
rpc_run_task+0x170/0x200 [sunrpc]
nfs4_call_sync_sequence+0x68/0xa0 [nfsv4]
_nfs4_lookup_root.isra.44+0xd0/0xf0 [nfsv4]
nfs4_lookup_root+0xe0/0x350 [nfsv4]
nfs4_lookup_root_sec+0x70/0xa0 [nfsv4]
nfs4_find_root_sec+0xc4/0x100 [nfsv4]
nfs4_proc_get_rootfh+0x5c/0xf0 [nfsv4]
nfs4_get_rootfh+0x6c/0x190 [nfsv4]
nfs4_server_common_setup+0xc4/0x260 [nfsv4]
nfs4_create_server+0x278/0x3c0 [nfsv4]
nfs4_remote_mount+0x50/0xb0 [nfsv4]
mount_fs+0x74/0x210
vfs_kern_mount+0x78/0x220
nfs_do_root_mount+0xb0/0x140 [nfsv4]
nfs4_try_mount+0x60/0x100 [nfsv4]
nfs_fs_mount+0x5ec/0xda0 [nfs]
mount_fs+0x74/0x210
vfs_kern_mount+0x78/0x220
do_mount+0x254/0xf70
SyS_mount+0x94/0x100
system_call+0x38/0xe0Reported-by: Jan Stancek
Signed-off-by: David Howells
Tested-by: Jan Stancek
Signed-off-by: James Morris
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
