Skip to content

L
linux
Switch branch/tag
  1. 21 Oct, 2015 16 commits
    • David Howells's avatar
      KEYS: Move the point of trust determination to __key_link() · d1664ecc
      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.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      d1664ecc
    • David Howells's avatar
      X.509: Move the trust validation code out to its own file · bced9d87
      David Howells authored 
      Move the X.509 trust validation code out to its own file so that it can be
generalised.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      bced9d87
    • David Howells's avatar
      PKCS#7: Make the signature a pointer rather than embedding it · 4e4420dd
      David Howells authored 
      Point to the public_key_signature struct from the pkcs7_signed_info struct
rather than embedding it.  This makes it easier to have it take an
arbitrary number of MPIs in future.

We also save a copy of the digest in the signature without sharing the
memory with the crypto layer metadata.  This means we can use
public_key_free() to get rid of the signature record.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      4e4420dd
    • David Howells's avatar
      X.509: Extract signature digest and make self-signed cert checks earlier · 47410d3a
      David Howells authored 
      Extract the signature digest for an X.509 certificate earlier, at the end
of x509_cert_parse() rather than leaving it to the callers thereof.

Further, immediately after that, check the signature on self-signed
certificates, also rather in the callers of x509_cert_parse().

This we need to determine whether or not the X.509 cert requires crypto
that we don't support before we do the above two steps.

We note in the x509_certificate struct the following bits of information:

 (1) Whether the signature is self-signed (even if we can't check the
     signature due to missing crypto).

 (2) Whether the key held in the certificate needs unsupported crypto to be
     used.  We may get a PKCS#7 message with X.509 certs that we can't make
     use of - we just ignore them and give ENOPKG at the end it we couldn't
     verify anything if at least one of these unusable certs are in the
     chain of trust.

 (3) Whether the signature held in the certificate needs unsupported crypto
     to be checked.  We can still use the key held in this certificate,
     even if we can't check the signature on it - if it is held in the
     system trusted keyring, for instance.  We just can't add it to a ring
     of trusted keys or follow it further up the chain of trust.

Making these checks earlier allows x509_check_signature() to be removed and
replaced with direct calls to public_key_verify_signature().
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      47410d3a
    • David Howells's avatar
      X.509: Retain the key verification data · dfd0cabf
      David Howells authored 
      Retain the key verification data (ie. the struct public_key_signature)
including the digest and the key identifiers.

Note that this means that we need to take a separate copy of the digest in
x509_get_sig_params() rather than lumping it in with the crypto layer data.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      dfd0cabf
    • David Howells's avatar
      KEYS: Add identifier pointers to public_key_signature struct · d14424ec
      David Howells authored 
      Add key identifier pointers to public_key_signature struct so that they can
be used to retain the identifier of the key to be used to verify the
signature in both PKCS#7 and X.509.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      d14424ec
    • David Howells's avatar
      KEYS: Allow authentication data to be stored in an asymmetric key · 385dedf4
      David Howells authored 
      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: default avatarDavid Howells <dhowells@redhat.com>
      385dedf4
    • David Howells's avatar
      KEYS: Add facility to check key trustworthiness upon link creation · b3e2fd85
      David Howells authored 
      Add a facility whereby if KEY_FLAG_TRUSTED_ONLY is set on the destination
keyring, the creation of a link to a candidate key will cause the
trustworthiness of that key to be evaluated against the already present
contents of that keyring.  This affects operations like add_key(),
KEYCTL_LINK and KEYCTL_INSTANTIATE.

To this end:

 (1) A new key type method is provided:

	int (*verify_trust)(const union key_payload *payload,
			    struct key *keyring);

     This is implemented by key types for which verification of one key by
     another is appropriate.  It is primarily intended for use with the
     asymmetric key type.

     When called, it is given the payload or prospective payload[*] of the
     candidate key to verify and a pointer to the destination keyring.  The
     method is expected to search the keying for an appropriate key with
     which to verify the candidate.

     [*] If called during add_key(), preparse is called before this method,
     	 but a key isn't actually allocated unless the verification is
     	 successful.

 (2) KEY_FLAG_TRUSTED is removed.  A key is now trusted by virtue of being
     contained in the trusted-only keyring being searched.

 (3) KEY_ALLOC_TRUSTED now acts as an override.  If this is passed to
     key_create_or_update() then the ->verify_trust() method will be
     ignored and the key will be added anyway.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      b3e2fd85
    • David Howells's avatar
      PKCS#7: Make trust determination dependent on contents of trust keyring · be4dc974
      David Howells authored 
      Make the determination of the trustworthiness of a key dependent on whether
a key that can verify it is present in the ring of trusted keys rather than
whether or not the verifying key has KEY_FLAG_TRUSTED set.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      be4dc974
    • David Howells's avatar
      KEYS: Generalise system_verify_data() to provide access to internal content · 661cb9c4
      David Howells authored 
      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: default avatarDavid Howells <dhowells@redhat.com>
      661cb9c4
    • 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
    • David Howells's avatar
      KEYS: Provide a script to extract a module signature · 4adc605e
      David Howells authored 
      The supplied script takes a signed module file and extracts the tailmost
signature (there could theoretically be more than one) and dumps all or
part of it or the unsigned file to stdout.

Call as:

	scripts/extract-module-sig.pl -[0adnks] module-file >out

where the initial flag indicates which bit of the signed file you want dumping
to stdout:

 (*) "-0".  Dumps the unsigned data with the signature stripped.

 (*) "-a".  Dumps all of the signature data, including the magic number.

 (*) "-d".  Dumps the signature information block as a sequence of decimal
     	    numbers in text form with spaces between (crypto algorithm type,
     	    hash type, identifier type, signer's name length, key identifier
     	    length and signature length).

 (*) "-n".  Dumps the signer's name contents.

 (*) "-k".  Dumps the key identifier contents.

 (*) "-s".  Dumps the cryptographic signature contents.

In the case that the signature is a PKCS#7 (or CMS) message, -n and -k will
print a warning to stderr and dump nothing to stdout, but will otherwise
complete okay; the entire PKCS#7/CMS message will be dumped by "-s"; and "-d"
will show "0 0 2 0 0 <pkcs#7-msg-len>".
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      4adc605e
    • David Howells's avatar
      KEYS: Provide a script to extract the sys cert list from a vmlinux file · 2221a6ee
      David Howells authored 
      The supplied script takes a vmlinux file - and if necessary a System.map
file - locates the system certificates list and extracts it to the named
file.

Call as:

    ./scripts/extract-sys-certs vmlinux certs

if vmlinux contains symbols and:

    ./scripts/extract-sys-certs -s System.map vmlinux certs

if it does not.

It prints something like the following to stdout:

	Have 27 sections
	No symbols in vmlinux, trying System.map
	Have 80088 symbols
	Have 1346 bytes of certs at VMA 0xffffffff8201c540
	Certificate list in section .init.data
	Certificate list at file offset 0x141c540

If vmlinux contains symbols then that is used rather than System.map - even
if one is given.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      2221a6ee
    • Insu Yun's avatar
      keys: Be more consistent in selection of union members used · 27720e75
      Insu Yun authored 
      key->description and key->index_key.description are same because
they are unioned. But, for readability, using same name for
duplication and validation seems better.
Signed-off-by: default avatarInsu Yun <wuninsu@gmail.com>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      27720e75
    • Paul Gortmaker's avatar
      certs: add .gitignore to stop git nagging about x509_certificate_list · 48dbc164
      Paul Gortmaker authored 
      Currently we see this in "git status" if we build in the source dir:

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        certs/x509_certificate_list

It looks like it used to live in kernel/ so we squash that .gitignore
entry at the same time.  I didn't bother to dig through git history to
see when it moved, since it is just a minor annoyance at most.

Cc: David Woodhouse <dwmw2@infradead.org>
Cc: keyrings@linux-nfs.org
Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      48dbc164
    • Geliang Tang's avatar
      KEYS: use kvfree() in add_key · d0e0eba0
      Geliang Tang authored 
      There is no need to make a flag to tell that this memory is allocated by
kmalloc or vmalloc. Just use kvfree to free the memory.
Signed-off-by: default avatarGeliang Tang <geliangtang@163.com>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      d0e0eba0
  3. 20 Oct, 2015 2 commits
  5. 19 Oct, 2015 1 commit
    • Zbigniew Jasinski's avatar
      Smack: limited capability for changing process label · 38416e53
      Zbigniew Jasinski authored 
      This feature introduces new kernel interface:

- <smack_fs>/relabel-self - for setting transition labels list

This list is used to control smack label transition mechanism.
List is set by, and per process. Process can transit to new label only if
label is on the list. Only process with CAP_MAC_ADMIN capability can add
labels to this list. With this list, process can change it's label without
CAP_MAC_ADMIN but only once. After label changing, list is unset.

Changes in v2:
* use list_for_each_entry instead of _rcu during label write
* added missing description in security/Smack.txt

Changes in v3:
* squashed into one commit

Changes in v4:
* switch from global list to per-task list
* since the per-task list is accessed only by the task itself
  there is no need to use synchronization mechanisms on it

Changes in v5:
* change smackfs interface of relabel-self to the one used for onlycap
  multiple labels are accepted, separated by space, which
  replace the previous list upon write
Signed-off-by: default avatarZbigniew Jasinski <z.jasinski@samsung.com>
Signed-off-by: default avatarRafal Krypa <r.krypa@samsung.com>
Acked-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      38416e53
  7. 18 Oct, 2015 18 commits
  9. 09 Oct, 2015 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7