linux-stable.git/security/integrity, branch linux-5.6.y

evm: Fix RCU list related warnings

2020-06-07T11:16:45+00:00

[ Upstream commit 770f60586d2af0590be263f55fd079226313922c ]

This patch fixes the following warning and few other instances of
traversal of evm_config_xattrnames list:

[   32.848432] =============================
[   32.848707] WARNING: suspicious RCU usage
[   32.848966] 5.7.0-rc1-00006-ga8d5875ce5f0b #1 Not tainted
[   32.849308] -----------------------------
[   32.849567] security/integrity/evm/evm_main.c:231 RCU-list traversed in non-reader section!!

Since entries are only added to the list and never deleted, use
list_for_each_entry_lockless() instead of list_for_each_entry_rcu for
traversing the list.  Also, add a relevant comment in evm_secfs.c to
indicate this fact.

Reported-by: kernel test robot 
Suggested-by: Paul E. McKenney 
Signed-off-by: Madhuparna Bhowmik 
Acked-by: Paul E. McKenney  (RCU viewpoint)
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

evm: Fix a small race in init_desc()

2020-05-27T15:48:03+00:00

[ Upstream commit 8433856947217ebb5697a8ff9c4c9cad4639a2cf ]

The IS_ERR_OR_NULL() function has two conditions and if we got really
unlucky we could hit a race where "ptr" started as an error pointer and
then was set to NULL.  Both conditions would be false even though the
pointer at the end was NULL.

This patch fixes the problem by ensuring that "*tfm" can only be NULL
or valid.  I have introduced a "tmp_tfm" variable to make that work.  I
also reversed a condition and pulled the code in one tab.

Reported-by: Roberto Sassu 
Fixes: 53de3b080d5e ("evm: Check also if *tfm is an error pointer in init_desc()")
Signed-off-by: Dan Carpenter 
Acked-by: Roberto Sassu 
Acked-by: Krzysztof Struczynski 
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

ima: Fix return value of ima_write_policy()

2020-05-27T15:47:57+00:00

[ Upstream commit 2e3a34e9f409ebe83d1af7cd2f49fca7af97dfac ]

This patch fixes the return value of ima_write_policy() when a new policy
is directly passed to IMA and the current policy requires appraisal of the
file containing the policy. Currently, if appraisal is not in ENFORCE mode,
ima_write_policy() returns 0 and leads user space applications to an
endless loop. Fix this issue by denying the operation regardless of the
appraisal mode.

Cc: stable@vger.kernel.org # 4.10.x
Fixes: 19f8a84713edc ("ima: measure and appraise the IMA policy itself")
Signed-off-by: Roberto Sassu 
Reviewed-by: Krzysztof Struczynski 
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

evm: Check also if *tfm is an error pointer in init_desc()

2020-05-27T15:47:56+00:00

[ Upstream commit 53de3b080d5eae31d0de219617155dcc34e7d698 ]

This patch avoids a kernel panic due to accessing an error pointer set by
crypto_alloc_shash(). It occurs especially when there are many files that
require an unsupported algorithm, as it would increase the likelihood of
the following race condition:

Task A: *tfm = crypto_alloc_shash() <= error pointer
Task B: if (*tfm == NULL) <= *tfm is not NULL, use it
Task B: rc = crypto_shash_init(desc) <= panic
Task A: *tfm = NULL

This patch uses the IS_ERR_OR_NULL macro to determine whether or not a new
crypto context must be created.

Cc: stable@vger.kernel.org
Fixes: d46eb3699502b ("evm: crypto hash replaced by shash")
Co-developed-by: Krzysztof Struczynski 
Signed-off-by: Krzysztof Struczynski 
Signed-off-by: Roberto Sassu 
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

ima: Set file->f_mode instead of file->f_flags in ima_calc_file_hash()

2020-05-27T15:47:56+00:00

[ Upstream commit 0014cc04e8ec077dc482f00c87dfd949cfe2b98f ]

Commit a408e4a86b36 ("ima: open a new file instance if no read
permissions") tries to create a new file descriptor to calculate a file
digest if the file has not been opened with O_RDONLY flag. However, if a
new file descriptor cannot be obtained, it sets the FMODE_READ flag to
file->f_flags instead of file->f_mode.

This patch fixes this issue by replacing f_flags with f_mode as it was
before that commit.

Cc: stable@vger.kernel.org # 4.20.x
Fixes: a408e4a86b36 ("ima: open a new file instance if no read permissions")
Signed-off-by: Roberto Sassu 
Reviewed-by: Goldwyn Rodrigues 
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

ima: add sm3 algorithm to hash algorithm configuration list

2020-02-18T12:35:49+00:00

sm3 has been supported by the ima hash algorithm, but it is not
yet in the Kconfig configuration list. After adding, both ima and tpm2
can support sm3 well.

Signed-off-by: Tianjia Zhang 
Signed-off-by: Mimi Zohar

efi: Only print errors about failing to get certs if EFI vars are found

2020-02-18T12:35:48+00:00

If CONFIG_LOAD_UEFI_KEYS is enabled, the kernel attempts to load the certs
from the db, dbx and MokListRT EFI variables into the appropriate keyrings.

But it just assumes that the variables will be present and prints an error
if the certs can't be loaded, even when is possible that the variables may
not exist. For example the MokListRT variable will only be present if shim
is used.

So only print an error message about failing to get the certs list from an
EFI variable if this is found. Otherwise these printed errors just pollute
the kernel log ring buffer with confusing messages like the following:

[    5.427251] Couldn't get size: 0x800000000000000e
[    5.427261] MODSIGN: Couldn't get UEFI db list
[    5.428012] Couldn't get size: 0x800000000000000e
[    5.428023] Couldn't get UEFI MokListRT

Reported-by: Hans de Goede 
Signed-off-by: Javier Martinez Canillas 
Tested-by: Hans de Goede 
Acked-by: Ard Biesheuvel 
Signed-off-by: Mimi Zohar

Merge branch 'next-integrity' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity

2020-01-29T02:52:09+00:00

Pull IMA updates from Mimi Zohar:
 "Two new features - measuring certificates and querying IMA for a file
  hash - and three bug fixes:

   - Measuring certificates is like the rest of IMA, based on policy,
     but requires loading a custom policy. Certificates loaded onto a
     keyring, for example during early boot, before a custom policy has
     been loaded, are queued and only processed after loading the custom
     policy.

   - IMA calculates and caches files hashes. Other kernel subsystems,
     and possibly kernel modules, are interested in accessing these
     cached file hashes.

  The bug fixes prevent classifying a file short read (e.g. shutdown) as
  an invalid file signature, add a missing blank when displaying the
  securityfs policy rules containing LSM labels, and, lastly, fix the
  handling of the IMA policy information for unknown LSM labels"

* 'next-integrity' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity:
  IMA: Defined delayed workqueue to free the queued keys
  IMA: Call workqueue functions to measure queued keys
  IMA: Define workqueue for early boot key measurements
  IMA: pre-allocate buffer to hold keyrings string
  ima: ima/lsm policy rule loading logic bug fixes
  ima: add the ability to query the cached hash of a given file
  ima: Add a space after printing LSM rules for readability
  IMA: fix measuring asymmetric keys Kconfig
  IMA: Read keyrings= option from the IMA policy
  IMA: Add support to limit measuring keys
  KEYS: Call the IMA hook to measure keys
  IMA: Define an IMA hook to measure keys
  IMA: Add KEY_CHECK func to measure keys
  IMA: Check IMA policy flag
  ima: avoid appraise error for hash calc interrupt

IMA: Defined delayed workqueue to free the queued keys

2020-01-23T12:37:31+00:00

Keys queued for measurement should be freed if a custom IMA policy
was not loaded.  Otherwise, the keys will remain queued forever
consuming kernel memory.

This patch defines a delayed workqueue to handle the above scenario.
The workqueue handler is setup to execute 5 minutes after IMA
initialization is completed.

If a custom IMA policy is loaded before the workqueue handler is
scheduled to execute, the workqueue task is cancelled and any queued keys
are processed for measurement.  But if a custom policy was not loaded then
the queued keys are just freed when the delayed workqueue handler is run.

Signed-off-by: Lakshmi Ramasubramanian 
Reported-by: kernel test robot  # sleeping
function called from invalid context
Reported-by: kbuild test robot  # redefinition of
ima_init_key_queue() function.
Signed-off-by: Mimi Zohar

IMA: Call workqueue functions to measure queued keys

2020-01-23T12:35:25+00:00

Measuring keys requires a custom IMA policy to be loaded.  Keys should
be queued for measurement if a custom IMA policy is not yet loaded.
Keys queued for measurement, if any, should be processed when a custom
policy is loaded.

This patch updates the IMA hook function ima_post_key_create_or_update()
to queue the key if a custom IMA policy has not yet been loaded.  And,
ima_update_policy() function, which is called when a custom IMA policy
is loaded, is updated to process queued keys.

Signed-off-by: Lakshmi Ramasubramanian 
Signed-off-by: Mimi Zohar