1. 11 Apr, 2016 6 commits
    • David Howells's avatar
      IMA: Use the the system trusted keyrings instead of .ima_mok · 56104cf2
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      56104cf2
    • David Howells's avatar
      certs: Add a secondary system keyring that can be added to dynamically · d3bfe841
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      d3bfe841
    • David Howells's avatar
      KEYS: Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED · 77f68bac
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      77f68bac
    • David Howells's avatar
      KEYS: Move the point of trust determination to __key_link() · a511e1af
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      a511e1af
    • David Howells's avatar
      KEYS: Generalise x509_request_asymmetric_key() · 9eb02989
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      9eb02989
    • David Howells's avatar
      KEYS: Move x509_request_asymmetric_key() to asymmetric_type.c · 983023f2
      David Howells authored
      Move x509_request_asymmetric_key() to asymmetric_type.c so that it can be
      generalised.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      983023f2
  2. 06 Apr, 2016 2 commits
  3. 09 Feb, 2016 1 commit
  4. 20 Dec, 2015 2 commits
  5. 15 Dec, 2015 1 commit
    • Petko Manolov's avatar
      IMA: create machine owner and blacklist keyrings · 41c89b64
      Petko Manolov authored
      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: default avatarPetko Manolov <petkan@mip-labs.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      41c89b64
  6. 21 Oct, 2015 1 commit
    • David Howells's avatar
      KEYS: Merge the type-specific data with the payload data · 146aa8b1
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      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
      146aa8b1
  7. 18 Oct, 2015 2 commits
  8. 12 Aug, 2015 1 commit
    • David Howells's avatar
      PKCS#7: Appropriately restrict authenticated attributes and content type · 99db4435
      David Howells authored
      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_SIGNATURE
      
      	 These 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 </tmp/stuff.pkcs7
      
           will attempt to check the signature on stuff.pkcs7 as if it contains a
           firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).
      Suggested-by: default avatarAndy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Reviewed-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      99db4435
  9. 07 Aug, 2015 1 commit
    • David Howells's avatar
      MODSIGN: Extract the blob PKCS#7 signature verifier from module signing · 091f6e26
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Seth Forshee <seth.forshee@canonical.com>
      Cc: Kyle McMartin <kyle@kernel.org>
      091f6e26
  10. 06 Oct, 2014 1 commit
  11. 16 Sep, 2014 3 commits
    • David Howells's avatar
      KEYS: Implement binary asymmetric key ID handling · 7901c1a8
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarVivek Goyal <vgoyal@redhat.com>
      7901c1a8
    • David Howells's avatar
      KEYS: Remove key_type::match in favour of overriding default by match_preparse · c06cfb08
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarVivek Goyal <vgoyal@redhat.com>
      c06cfb08
    • David Howells's avatar
      KEYS: Preparse match data · 46291959
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarVivek Goyal <vgoyal@redhat.com>
      46291959
  12. 22 Jul, 2014 2 commits
  13. 17 Jul, 2014 1 commit
  14. 25 Sep, 2013 1 commit
  15. 24 Sep, 2013 2 commits
    • David Howells's avatar
      KEYS: Implement a big key type that can save to tmpfs · ab3c3587
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarSimo Sorce <simo@redhat.com>
      ab3c3587
    • David Howells's avatar
      KEYS: Expand the capacity of a keyring · b2a4df20
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      b2a4df20
  16. 07 Oct, 2012 3 commits
    • David Howells's avatar
      KEYS: Asymmetric key pluggable data parsers · 46c6f177
      David Howells authored
      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 <dhowells.pem
      
      or a PGP key:
      
      	keyctl padd asymmetric bar @s <dhowells.pub
      
      or a pointer into the contents of the TPM:
      
      	keyctl add asymmetric zebra "TPM:04982390582905f8" @s
      
      Inside the kernel, pluggable parsers register themselves and then get to
      examine the payload data to see if they can handle it.  If they can, they get
      to:
      
        (1) Propose a name for the key, to be used it the name is "" or NULL.
      
        (2) Specify the key subtype.
      
        (3) Provide the data for the subtype.
      
      The key type asks the parser to do its stuff before a key is allocated and thus
      before the name is set.  If successful, the parser stores the suggested data
      into the key_preparsed_payload struct, which will be either used (if the key is
      successfully created and instantiated or updated) or discarded.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      46c6f177
    • David Howells's avatar
      KEYS: Implement asymmetric key type · 964f3b3b
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      964f3b3b
    • David Howells's avatar
      KEYS: Add payload preparsing opportunity prior to key instantiate or update · cf7f601c
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      cf7f601c
  17. 13 Sep, 2012 1 commit
    • David Howells's avatar
      KEYS: Add payload preparsing opportunity prior to key instantiate or update · d4f65b5d
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      d4f65b5d
  18. 11 May, 2012 1 commit
    • David Howells's avatar
      KEYS: Permit in-place link replacement in keyring list · 233e4735
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      233e4735
  19. 17 Jan, 2012 1 commit
    • Jeff Layton's avatar
      keys: add a "logon" key type · 9f6ed2ca
      Jeff Layton authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      9f6ed2ca
  20. 27 Jun, 2011 1 commit
  21. 29 Mar, 2011 1 commit
  22. 02 Mar, 2011 1 commit
    • Anton Blanchard's avatar
      RxRPC: Fix v1 keys · f009918a
      Anton Blanchard authored
      commit 33941284 (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: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f009918a
  23. 28 Nov, 2010 2 commits
    • Mimi Zohar's avatar
      keys: add new key-type encrypted · 7e70cb49
      Mimi Zohar authored
      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: default avatarMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: default avatarDavid Safford <safford@watson.ibm.com>
      Reviewed-by: default avatarRoberto Sassu <roberto.sassu@polito.it>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      7e70cb49
    • Mimi Zohar's avatar
      keys: add new trusted key-type · d00a1c72
      Mimi Zohar authored
      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: default avatarDavid Safford <safford@watson.ibm.com>
      Signed-off-by: default avatarMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      d00a1c72
  24. 05 Aug, 2010 1 commit
    • Wang Lei's avatar
      DNS: Separate out CIFS DNS Resolver code · 1a4240f4
      Wang Lei authored
      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 "[<type>:]<domain_name>".  The optional <type>
      indicates the particular DNS lookup and packaging that's required.  The
      <domain_name> is the query to be made.
      
      If <type> 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: default avatarWang Lei <wang840925@gmail.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      1a4240f4
  25. 16 Sep, 2009 1 commit