Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 07 3月, 2017 2 次提交
  3. 02 3月, 2017 1 次提交
  5. 28 1月, 2017 2 次提交
  7. 21 12月, 2016 8 次提交
  9. 03 12月, 2016 1 次提交
  11. 14 11月, 2016 4 次提交
  13. 08 10月, 2016 1 次提交
  15. 16 9月, 2016 1 次提交
  17. 06 7月, 2016 1 次提交
  19. 30 6月, 2016 8 次提交
  21. 21 5月, 2016 1 次提交
  23. 04 5月, 2016 1 次提交
  25. 01 5月, 2016 2 次提交
    • M
      ima: add support for creating files using the mknodat syscall · 05d1a717
      由 Mimi Zohar 提交于 
      Commit 3034a146 "ima: pass 'opened' flag to identify newly created files"
stopped identifying empty files as new files.  However new empty files
can be created using the mknodat syscall.  On systems with IMA-appraisal
enabled, these empty files are not labeled with security.ima extended
attributes properly, preventing them from subsequently being opened in
order to write the file data contents.  This patch defines a new hook
named ima_post_path_mknod() to mark these empty files, created using
mknodat, as new in order to allow the file data contents to be written.

In addition, files with security.ima xattrs containing a file signature
are considered "immutable" and can not be modified.  The file contents
need to be written, before signing the file.  This patch relaxes this
requirement for new files, allowing the file signature to be written
before the file contents.

Changelog:
- defer identifying files with signatures stored as security.ima
  (based on Dmitry Rozhkov's comments)
- removing tests (eg. dentry, dentry->d_inode, inode->i_size == 0)
  (based on Al's review)
Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Al Viro <<viro@zeniv.linux.org.uk>
Tested-by: NDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
      05d1a717
    • M
      ima: fix ima_inode_post_setattr · 42a4c603
      由 Mimi Zohar 提交于 
      Changing file metadata (eg. uid, guid) could result in having to
re-appraise a file's integrity, but does not change the "new file"
status nor the security.ima xattr.  The IMA_PERMIT_DIRECTIO and
IMA_DIGSIG_REQUIRED flags are policy rule specific.  This patch
only resets these flags, not the IMA_NEW_FILE or IMA_DIGSIG flags.

With this patch, changing the file timestamp will not remove the
file signature on new files.
Reported-by: NDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
Tested-by: NDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
      42a4c603
  27. 13 4月, 2016 1 次提交
  29. 12 4月, 2016 4 次提交
    • D
      IMA: Use the the system trusted keyrings instead of .ima_mok · 56104cf2
      由 David Howells 提交于 
      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: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      56104cf2
    • D
      KEYS: Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED · 77f68bac
      由 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: NDavid Howells <dhowells@redhat.com>
      77f68bac
    • D
      KEYS: Move the point of trust determination to __key_link() · a511e1af
      由 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: NDavid Howells <dhowells@redhat.com>
      a511e1af
    • D
      KEYS: Add a facility to restrict new links into a keyring · 5ac7eace
      由 David Howells 提交于 
      Add a facility whereby proposed new links to be added to a keyring can be
vetted, permitting them to be rejected if necessary.  This can be used to
block public keys from which the signature cannot be verified or for which
the signature verification fails.  It could also be used to provide
blacklisting.

This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.

To this end:

 (1) A function pointer is added to the key struct that, if set, points to
     the vetting function.  This is called as:

	int (*restrict_link)(struct key *keyring,
			     const struct key_type *key_type,
			     unsigned long key_flags,
			     const union key_payload *key_payload),

     where 'keyring' will be the keyring being added to, key_type and
     key_payload will describe the key being added and key_flags[*] can be
     AND'ed with KEY_FLAG_TRUSTED.

     [*] This parameter will be removed in a later patch when
     	 KEY_FLAG_TRUSTED is removed.

     The function should return 0 to allow the link to take place or an
     error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
     link.

     The pointer should not be set directly, but rather should be set
     through keyring_alloc().

     Note that if called during add_key(), preparse is called before this
     method, but a key isn't actually allocated until after this function
     is called.

 (2) KEY_ALLOC_BYPASS_RESTRICTION is added.  This can be passed to
     key_create_or_update() or key_instantiate_and_link() to bypass the
     restriction check.

 (3) KEY_FLAG_TRUSTED_ONLY is removed.  The entire contents of a keyring
     with this restriction emplaced can be considered 'trustworthy' by
     virtue of being in the keyring when that keyring is consulted.

 (4) key_alloc() and keyring_alloc() take an extra argument that will be
     used to set restrict_link in the new key.  This ensures that the
     pointer is set before the key is published, thus preventing a window
     of unrestrictedness.  Normally this argument will be NULL.

 (5) As a temporary affair, keyring_restrict_trusted_only() is added.  It
     should be passed to keyring_alloc() as the extra argument instead of
     setting KEY_FLAG_TRUSTED_ONLY on a keyring.  This will be replaced in
     a later patch with functions that look in the appropriate places for
     authoritative keys.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Reviewed-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      5ac7eace
  31. 11 4月, 2016 2 次提交