26 Sep, 2013

1 commit


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

    David Howells
     
  • 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

    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

    David Howells
     
  • 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

    David Howells
     
  • 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

    David Howells
     

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

    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

    Jeff Layton
     

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

    Roberto Sassu
     

30 Mar, 2011

1 commit


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

    Anton Blanchard
     

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

    Mimi Zohar
     
  • 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

    Mimi Zohar
     

06 Aug, 2010

1 commit

  • Separate out the DNS resolver key type from the CIFS filesystem into its own
    module so that it can be made available for general use, including the AFS
    filesystem module.

    This facility makes it possible for the kernel to upcall to userspace to have
    it issue DNS requests, package up the replies and present them to the kernel
    in a useful form. The kernel is then able to cache the DNS replies as keys
    can be retained in keyrings.

    Resolver keys are of type "dns_resolver" and have a case-insensitive
    description that is of the form "[:]". The optional
    indicates the particular DNS lookup and packaging that's required. The
    is the query to be made.

    If isn't given, a basic hostname to IP address lookup is made, and the
    result is stored in the key in the form of a printable string consisting of a
    comma-separated list of IPv4 and IPv6 addresses.

    This key type is supported by userspace helpers driven from /sbin/request-key
    and configured through /etc/request-key.conf. The cifs.upcall utility is
    invoked for UNC path server name to IP address resolution.

    The CIFS functionality is encapsulated by the dns_resolve_unc_to_ip() function,
    which is used to resolve a UNC path to an IP address for CIFS filesystem. This
    part remains in the CIFS module for now.

    See the added Documentation/networking/dns_resolver.txt for more information.

    Signed-off-by: Wang Lei
    Signed-off-by: David Howells
    Acked-by: Jeff Layton
    Signed-off-by: Steve French

    Wang Lei
     

16 Sep, 2009

1 commit


15 Sep, 2009

2 commits


14 Nov, 2008

1 commit


22 Apr, 2008

1 commit


17 Oct, 2007

1 commit

  • Make request_key() and co fundamentally asynchronous to make it easier for
    NFS to make use of them. There are now accessor functions that do
    asynchronous constructions, a wait function to wait for construction to
    complete, and a completion function for the key type to indicate completion
    of construction.

    Note that the construction queue is now gone. Instead, keys under
    construction are linked in to the appropriate keyring in advance, and that
    anyone encountering one must wait for it to be complete before they can use
    it. This is done automatically for userspace.

    The following auxiliary changes are also made:

    (1) Key type implementation stuff is split from linux/key.h into
    linux/key-type.h.

    (2) AF_RXRPC provides a way to allocate null rxrpc-type keys so that AFS does
    not need to call key_instantiate_and_link() directly.

    (3) Adjust the debugging macros so that they're -Wformat checked even if
    they are disabled, and make it so they can be enabled simply by defining
    __KDEBUG to be consistent with other code of mine.

    (3) Documentation.

    [alan@lxorguk.ukuu.org.uk: keys: missing word in documentation]
    Signed-off-by: David Howells
    Signed-off-by: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

27 Apr, 2007

1 commit

  • Provide AF_RXRPC sockets that can be used to talk to AFS servers, or serve
    answers to AFS clients. KerberosIV security is fully supported. The patches
    and some example test programs can be found in:

    http://people.redhat.com/~dhowells/rxrpc/

    This will eventually replace the old implementation of kernel-only RxRPC
    currently resident in net/rxrpc/.

    Signed-off-by: David Howells
    Signed-off-by: David S. Miller

    David Howells
     

27 Jun, 2006

1 commit

  • Cause the keys linked to a keyring to be unlinked from it when revoked and it
    causes the data attached to a user-defined key to be discarded when revoked.

    This frees up most of the quota a key occupied at that point, rather than
    waiting for the key to actually be destroyed.

    Signed-off-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

07 Jan, 2006

1 commit


31 Oct, 2005

1 commit

  • Export user-defined key operations so that those who wish to define their
    own key type based on the user-defined key operations may do so (as has
    been requested).

    The header file created has been placed into include/keys/user-type.h, thus
    creating a directory where other key types may also be placed. Any
    objections to doing this?

    Signed-Off-By: David Howells
    Signed-Off-By: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells