DM configures a block device with various target specific attributes
passed to it as a table.  DM loads the table, and calls each target’s
respective constructors with the attributes as input parameters.
Some of these attributes are critical to ensure the device meets
certain security bar.  Thus, IMA should measure these attributes, to
ensure they are not tampered with, during the lifetime of the device.
So that the external services can have high confidence in the
configuration of the block-devices on a given system.

Some devices may have large tables.  And a given device may change its
state (table-load, suspend, resume, rename, remove, table-clear etc.)
many times.  Measuring these attributes each time when the device
changes its state will significantly increase the size of the IMA logs.
Further, once configured, these attributes are not expected to change
unless a new table is loaded, or a device is removed and recreated.
Therefore the clear-text of the attributes should only be measured
during table load, and the hash of the active/inactive table should be
measured for the remaining device state changes.

Export IMA function ima_measure_critical_data() to allow measurement
of DM device parameters, as well as target specific attributes, during
table load.  Compute the hash of the inactive table and store it for
measurements during future state change.  If a load is called multiple
times, update the inactive table hash with the hash of the latest
populated table.  So that the correct inactive table hash is measured
when the device transitions to different states like resume, remove,
rename, etc.
Signed-off-by: NTushar Sugandhi <tusharsu@linux.microsoft.com>
Signed-off-by: Colin Ian King <colin.king@canonical.com> # leak fix
Signed-off-by: NMike Snitzer <snitzer@redhat.com>

This patch fixes the sparse warning:

sparse: warning: Using plain integer as NULL pointer
Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

The original function name was ima_path_check().  The policy parsing
still supports PATH_CHECK.   Commit 9bbb6cad ("ima: rename
ima_path_check to ima_file_check") renamed the function to
ima_file_check(), but missed modifying the function name in the
comment.

Fixes: 9bbb6cad ("ima: rename ima_path_check to ima_file_check").
Signed-off-by: NJiele Zhao <unclexiaole@gmail.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

Of the three LSMs that implement the security_task_getsecid() LSM
hook, all three LSMs provide the task's objective security
credentials.  This turns out to be unfortunate as most of the hook's
callers seem to expect the task's subjective credentials, although
a small handful of callers do correctly expect the objective
credentials.

This patch is the first step towards fixing the problem: it splits
the existing security_task_getsecid() hook into two variants, one
for the subjective creds, one for the objective creds.

  void security_task_getsecid_subj(struct task_struct *p,
				   u32 *secid);
  void security_task_getsecid_obj(struct task_struct *p,
				  u32 *secid);

While this patch does fix all of the callers to use the correct
variant, in order to keep this patch focused on the callers and to
ease review, the LSMs continue to use the same implementation for
both hooks.  The net effect is that this patch should not change
the behavior of the kernel in any way, it will be up to the latter
LSM specific patches in this series to change the hook
implementations and return the correct credentials.

Acked-by: Mimi Zohar <zohar@linux.ibm.com> (IMA)
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NRichard Guy Briggs <rgb@redhat.com>
Signed-off-by: NPaul Moore <paul@paul-moore.com>

Unless an IMA policy is loaded, don't bother checking for an appraise
policy rule.  Return immediately.
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

IMA does sometimes access the inode's i_uid and compares it against the
rules' fowner. Enable IMA to handle idmapped mounts by passing down the
mount's user namespace. We simply make use of the helpers we introduced
before. If the initial user namespace is passed nothing changes so
non-idmapped mounts will see identical behavior as before.

Link: https://lore.kernel.org/r/20210121131959.646623-27-christian.brauner@ubuntu.comSigned-off-by: NChristian Brauner <christian.brauner@ubuntu.com>

The IMA hook ima_measure_critical_data() does not support a way to
specify the source of the critical data provider.  Thus, the data
measurement cannot be constrained based on the data source label
in the IMA policy.

Extend the IMA hook ima_measure_critical_data() to support passing
the data source label as an input parameter, so that the policy rule can
be used to limit the measurements based on the label.
Signed-off-by: NTushar Sugandhi <tusharsu@linux.microsoft.com>
Reviewed-by: NTyler Hicks <tyhicks@linux.microsoft.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

IMA provides capabilities to measure file and buffer data.  However,
various data structures, policies, and states stored in kernel memory
also impact the integrity of the system.  Several kernel subsystems
contain such integrity critical data.  These kernel subsystems help
protect the integrity of the system.  Currently, IMA does not provide a
generic function for measuring kernel integrity critical data.

Define ima_measure_critical_data, a new IMA hook, to measure kernel
integrity critical data.
Signed-off-by: NTushar Sugandhi <tusharsu@linux.microsoft.com>
Reviewed-by: NTyler Hicks <tyhicks@linux.microsoft.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

The original IMA buffer data measurement sizes were small (e.g.  boot
command line), but the new buffer data measurement use cases have data
sizes that are a lot larger.  Just as IMA measures the file data hash,
not the file data, IMA should similarly support the option for measuring
buffer data hash.

Introduce a boolean parameter to support measuring buffer data hash,
which would be much smaller, instead of the buffer itself.
Signed-off-by: NTushar Sugandhi <tusharsu@linux.microsoft.com>
Reviewed-by: NTyler Hicks <tyhicks@linux.microsoft.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

IMA functions such as ima_match_keyring(), process_buffer_measurement(),
ima_match_policy() etc.  handle data specific to keyrings.  Currently,
these constructs are not generic to handle any func specific data.
This makes it harder to extend them without code duplication.

Refactor the keyring specific measurement constructs to be generic and
reusable in other measurement scenarios.
Signed-off-by: NTushar Sugandhi <tusharsu@linux.microsoft.com>
Reviewed-by: NTyler Hicks <tyhicks@linux.microsoft.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

This is in preparation to add a helper for BPF LSM programs to use
IMA hashes when attached to LSM hooks. There are LSM hooks like
inode_unlink which do not have a struct file * argument and cannot
use the existing ima_file_hash API.

An inode based API is, therefore, useful in LSM based detections like an
executable trying to delete itself which rely on the inode_unlink LSM
hook.

Moreover, the ima_file_hash function does nothing with the struct file
pointer apart from calling file_inode on it and converting it to an
inode.
Signed-off-by: NKP Singh <kpsingh@google.com>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Acked-by: NYonghong Song <yhs@fb.com>
Acked-by: NMimi Zohar <zohar@linux.ibm.com>
Link: https://lore.kernel.org/bpf/20201124151210.1081188-2-kpsingh@chromium.org

The default IMA template used for all policy rules is the value set
for CONFIG_IMA_DEFAULT_TEMPLATE if the policy rule does not specify
a template. The default IMA template for buffer measurements should be
'ima-buf' - so that the measured buffer is correctly included in the IMA
measurement log entry.

With the default template format, buffer measurements are added to
the measurement list, but do not include the buffer data, making it
difficult, if not impossible, to validate. Including 'ima-buf'
template records in the measurement list by default, should not impact
existing attestation servers without 'ima-buf' template support.

Initialize a global 'ima-buf' template and select that template,
by default, for buffer measurements.
Signed-off-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

Chester reports that it is necessary to introduce a new way to pass
the EFI secure boot status between the EFI stub and the core kernel
on ARM systems. The usual way of obtaining this information is by
checking the SecureBoot and SetupMode EFI variables, but this can
only be done after the EFI variable workqueue is created, which
occurs in a subsys_initcall(), whereas arch_ima_get_secureboot()
is called much earlier by the IMA framework.

However, the IMA framework itself is started as a late_initcall,
and the only reason the call to arch_ima_get_secureboot() occurs
so early is because it happens in the context of a __setup()
callback that parses the ima_appraise= command line parameter.

So let's refactor this code a little bit, by using a core_param()
callback to capture the command line argument, and deferring any
reasoning based on its contents to the IMA init routine.

Cc: Chester Lin <clin@suse.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Link: https://lore.kernel.org/linux-arm-kernel/20200904072905.25332-2-clin@suse.com/Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Reported-by: kernel test robot <lkp@intel.com> [missing core_param()]
[zohar@linux.ibm.com: included linux/module.h]
Tested-by: NChester Lin <clin@suse.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

When the kernel_read_file LSM hook is called with contents=false, IMA
can appraise the file directly, without requiring a filled buffer. When
such a buffer is available, though, IMA can continue to use it instead
of forcing a double read here.
Signed-off-by: NScott Branden <scott.branden@broadcom.com>
Link: https://lore.kernel.org/lkml/20200706232309.12010-10-scott.branden@broadcom.com/Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
Link: https://lore.kernel.org/r/20201002173828.2099543-13-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

As with the kernel_load_data LSM hook, add a "contents" flag to the
kernel_read_file LSM hook that indicates whether the LSM can expect
a matching call to the kernel_post_read_file LSM hook with the full
contents of the file. With the coming addition of partial file read
support for kernel_read_file*() API, the LSM will no longer be able
to always see the entire contents of a file during the read calls.

For cases where the LSM must read examine the complete file contents,
it will need to do so on its own every time the kernel_read_file
hook is called with contents=false (or reject such cases). Adjust all
existing LSMs to retain existing behavior.
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
Link: https://lore.kernel.org/r/20201002173828.2099543-12-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that security_post_load_data() is wired up, use it instead
of the NULL file argument style of security_post_read_file(),
and update the security_kernel_load_data() call to indicate that a
security_kernel_post_load_data() call is expected.

Wire up the IMA check to match earlier logic. Perhaps a generalized
change to ima_post_load_data() might look something like this:

    return process_buffer_measurement(buf, size,
                                      kernel_load_data_id_str(load_id),
                                      read_idmap[load_id] ?: FILE_CHECK,
                                      0, NULL);
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
Link: https://lore.kernel.org/r/20201002173828.2099543-10-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are a few places in the kernel where LSMs would like to have
visibility into the contents of a kernel buffer that has been loaded or
read. While security_kernel_post_read_file() (which includes the
buffer) exists as a pairing for security_kernel_read_file(), no such
hook exists to pair with security_kernel_load_data().

Earlier proposals for just using security_kernel_post_read_file() with a
NULL file argument were rejected (i.e. "file" should always be valid for
the security_..._file hooks, but it appears at least one case was
left in the kernel during earlier refactoring. (This will be fixed in
a subsequent patch.)

Since not all cases of security_kernel_load_data() can have a single
contiguous buffer made available to the LSM hook (e.g. kexec image
segments are separately loaded), there needs to be a way for the LSM to
reason about its expectations of the hook coverage. In order to handle
this, add a "contents" argument to the "kernel_load_data" hook that
indicates if the newly added "kernel_post_load_data" hook will be called
with the full contents once loaded. That way, LSMs requiring full contents
can choose to unilaterally reject "kernel_load_data" with contents=false
(which is effectively the existing hook coverage), but when contents=true
they can allow it and later evaluate the "kernel_post_load_data" hook
once the buffer is loaded.

With this change, LSMs can gain coverage over non-file-backed data loads
(e.g. init_module(2) and firmware userspace helper), which will happen
in subsequent patches.

Additionally prepare IMA to start processing these cases.
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NKP Singh <kpsingh@google.com>
Link: https://lore.kernel.org/r/20201002173828.2099543-9-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move kernel_read_file* out of linux/fs.h to its own linux/kernel_read_file.h
include file. That header gets pulled in just about everywhere
and doesn't really need functions not related to the general fs interface.
Suggested-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NScott Branden <scott.branden@broadcom.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NJames Morris <jamorris@linux.microsoft.com>
Link: https://lore.kernel.org/r/20200706232309.12010-2-scott.branden@broadcom.com
Link: https://lore.kernel.org/r/20201002173828.2099543-4-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

FIRMWARE_PREALLOC_BUFFER is a "how", not a "what", and confuses the LSMs
that are interested in filtering between types of things. The "how"
should be an internal detail made uninteresting to the LSMs.

Fixes: a098ecd2 ("firmware: support loading into a pre-allocated buffer")
Fixes: fd90bc55 ("ima: based on policy verify firmware signatures (pre-allocated buffer)")
Fixes: 4f0496d8 ("ima: based on policy warn about loading firmware (pre-allocated buffer)")
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org>
Acked-by: NScott Branden <scott.branden@broadcom.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201002173828.2099543-2-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

ima_file_hash can be called when there is no iint->ima_hash available
even though the inode exists in the integrity cache. It is fairly
common for a file to not have a hash. (e.g. an mknodat, prior to the
file being closed).

Another example where this can happen (suggested by Jann Horn):

Process A does:

	while(1) {
		unlink("/tmp/imafoo");
		fd = open("/tmp/imafoo", O_RDWR|O_CREAT|O_TRUNC, 0700);
		if (fd == -1) {
			perror("open");
			continue;
		}
		write(fd, "A", 1);
		close(fd);
	}

and Process B does:

	while (1) {
		int fd = open("/tmp/imafoo", O_RDONLY);
		if (fd == -1)
			continue;
    		char *mapping = mmap(NULL, 0x1000, PROT_READ|PROT_EXEC,
			 	     MAP_PRIVATE, fd, 0);
		if (mapping != MAP_FAILED)
			munmap(mapping, 0x1000);
		close(fd);
  	}

Due to the race to get the iint->mutex between ima_file_hash and
process_measurement iint->ima_hash could still be NULL.

Fixes: 6beea7af ("ima: add the ability to query the cached hash of a given file")
Signed-off-by: NKP Singh <kpsingh@google.com>
Reviewed-by: NFlorent Revest <revest@chromium.org>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

Don't silently ignore unknown or invalid ima_{policy,appraise,hash} and evm
kernel boot command line options.
Signed-off-by: NBruno Meneguele <bmeneg@redhat.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

Take the properties of the kexec kernel's inode and the current task
ownership into consideration when matching a KEXEC_CMDLINE operation to
the rules in the IMA policy. This allows for some uniformity when
writing IMA policy rules for KEXEC_KERNEL_CHECK, KEXEC_INITRAMFS_CHECK,
and KEXEC_CMDLINE operations.

Prior to this patch, it was not possible to write a set of rules like
this:

 dont_measure func=KEXEC_KERNEL_CHECK obj_type=foo_t
 dont_measure func=KEXEC_INITRAMFS_CHECK obj_type=foo_t
 dont_measure func=KEXEC_CMDLINE obj_type=foo_t
 measure func=KEXEC_KERNEL_CHECK
 measure func=KEXEC_INITRAMFS_CHECK
 measure func=KEXEC_CMDLINE

The inode information associated with the kernel being loaded by a
kexec_kernel_load(2) syscall can now be included in the decision to
measure or not

Additonally, the uid, euid, and subj_* conditionals can also now be
used in KEXEC_CMDLINE rules. There was no technical reason as to why
those conditionals weren't being considered previously other than
ima_match_rules() didn't have a valid inode to use so it immediately
bailed out for KEXEC_CMDLINE operations rather than going through the
full list of conditional comparisons.
Signed-off-by: NTyler Hicks <tyhicks@linux.microsoft.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: kexec@lists.infradead.org
Reviewed-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

process_buffer_measurement() and ima_alloc_key_entry() functions need to
log an audit message for auditing integrity measurement failures.

Add audit message in these two functions. Remove "pr_devel" log message
in process_buffer_measurement().

Sample audit messages:

[    6.303048] audit: type=1804 audit(1592506281.627:2): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel op=measuring_key cause=ENOMEM comm="swapper/0" name=".builtin_trusted_keys" res=0 errno=-12

[    8.019432] audit: type=1804 audit(1592506283.344:10): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 op=measuring_kexec_cmdline cause=hashing_error comm="systemd" name="kexec-cmdline" res=0 errno=-22
Signed-off-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com>
Suggested-by: NMimi Zohar <zohar@linux.ibm.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

Make sure IMA is enabled before checking mprotect change.  Addresses
report of a 3.7% regression of boot-time.dhcp.

Fixes: 8eb613c0 ("ima: verify mprotect change is consistent with mmap policy")
Reported-by: Nkernel test robot <rong.a.chen@intel.com>
Reviewed-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com>
Tested-by: NXing Zhengjun <zhengjun.xing@linux.intel.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

Files can be mmap'ed read/write and later changed to execute to circumvent
IMA's mmap appraise policy rules.  Due to locking issues (mmap semaphore
would be taken prior to i_mutex), files can not be measured or appraised at
this point.  Eliminate this integrity gap, by denying the mprotect
PROT_EXECUTE change, if an mmap appraise policy rule exists.

On mprotect change success, return 0.  On failure, return -EACESS.
Reviewed-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

Evaluate error in init_ima() before register_blocking_lsm_notifier() and
return if not zero.

Cc: stable@vger.kernel.org # 5.3.x
Fixes: b1694245 ("ima: use the lsm policy update notifier")
Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: NJames Morris <jamorris@linux.microsoft.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

The #define for formatting log messages, pr_fmt, is duplicated in the
files under security/integrity.

This change moves the definition to security/integrity/integrity.h and
removes the duplicate definitions in the other files under
security/integrity.

With this change, the messages in the following files will be prefixed
with 'integrity'.

     security/integrity/platform_certs/platform_keyring.c
     security/integrity/platform_certs/load_powerpc.c
     security/integrity/platform_certs/load_uefi.c
     security/integrity/iint.c

     e.g. "integrity: Error adding keys to platform keyring %s\n"

And the messages in the following file will be prefixed with 'ima'.

     security/integrity/ima/ima_mok.c

     e.g. "ima: Allocating IMA blacklist keyring.\n"

For the rest of the files under security/integrity, there will be no
change in the message format.
Suggested-by: NShuah Khan <skhan@linuxfoundation.org>
Suggested-by: NJoe Perches <joe@perches.com>
Signed-off-by: NTushar Sugandhi <tusharsu@linux.microsoft.com>
Reviewed-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

process_buffer_measurement() does not have log messages for failure
conditions.

This change adds a log statement in the above function.
Suggested-by: NJoe Perches <joe@perches.com>
Signed-off-by: NTushar Sugandhi <tusharsu@linux.microsoft.com>
Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
Reviewed-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

This allows other parts of the kernel (perhaps a stacked LSM allowing
system monitoring, eg. the proposed KRSI LSM [1]) to retrieve the hash
of a given file from IMA if it's present in the iint cache.

It's true that the existence of the hash means that it's also in the
audit logs or in /sys/kernel/security/ima/ascii_runtime_measurements,
but it can be difficult to pull that information out for every
subsequent exec. This is especially true if a given host has been up
for a long time and the file was first measured a long time ago.

It should be kept in mind that this function gives access to cached
entries which can be removed, for instance on security_inode_free().

This is based on Peter Moody's patch:
 https://sourceforge.net/p/linux-ima/mailman/message/33036180/

[1] https://lkml.org/lkml/2019/9/10/393Signed-off-by: NFlorent Revest <revest@google.com>
Reviewed-by: NKP Singh <kpsingh@chromium.org>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

Limit measuring keys to those keys being loaded onto a given set of
keyrings only and when the user id (uid) matches if uid is specified
in the policy.

This patch defines a new IMA policy option namely "keyrings=" that
can be used to specify a set of keyrings. If this option is specified
in the policy for "measure func=KEY_CHECK" then only the keys
loaded onto a keyring given in the "keyrings=" option are measured.

If uid is specified in the policy then the key is measured only if
the current user id matches the one specified in the policy.

Added a new parameter namely "keyring" (name of the keyring) to
process_buffer_measurement(). The keyring name is passed to
ima_get_action() to determine the required action.
ima_match_rules() is updated to check keyring in the policy, if
specified, for KEY_CHECK function.
Signed-off-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

process_buffer_measurement() may be called prior to IMA being
initialized (for instance, when the IMA hook is called when
a key is added to the .builtin_trusted_keys keyring), which
would result in a kernel panic.

This patch adds the check in process_buffer_measurement()
to return immediately if IMA is not initialized yet.
Signed-off-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

Asymmetric private keys are used to sign multiple files. The kernel
currently supports checking against blacklisted keys. However, if the
public key is blacklisted, any file signed by the blacklisted key will
automatically fail signature verification. Blacklisting the public key
is not fine enough granularity, as we might want to only blacklist a
particular file.

This patch adds support for checking against the blacklisted hash of
the file, without the appended signature, based on the IMA policy. It
defines a new policy option "appraise_flag=check_blacklist".

In addition to the blacklisted binary hashes stored in the firmware
"dbx" variable, the Linux kernel may be configured to load blacklisted
binary hashes onto the .blacklist keyring as well. The following
example shows how to blacklist a specific kernel module hash.

  $ sha256sum kernel/kheaders.ko
  77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3
  kernel/kheaders.ko

  $ grep BLACKLIST .config
  CONFIG_SYSTEM_BLACKLIST_KEYRING=y
  CONFIG_SYSTEM_BLACKLIST_HASH_LIST="blacklist-hash-list"

  $ cat certs/blacklist-hash-list
  "bin:77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3"

Update the IMA custom measurement and appraisal policy
rules (/etc/ima-policy):

  measure func=MODULE_CHECK template=ima-modsig
  appraise func=MODULE_CHECK appraise_flag=check_blacklist
  appraise_type=imasig|modsig

After building, installing, and rebooting the kernel:

   545660333 ---lswrv      0     0   \_ blacklist:
  bin:77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3

  measure func=MODULE_CHECK template=ima-modsig
  appraise func=MODULE_CHECK appraise_flag=check_blacklist
  appraise_type=imasig|modsig

  modprobe: ERROR: could not insert 'kheaders': Permission denied

  10 0c9834db5a0182c1fb0cdc5d3adcf11a11fd83dd ima-sig
  sha256:3bc6ed4f0b4d6e31bc1dbc9ef844605abc7afdc6d81a57d77a1ec9407997c40
  2 /usr/lib/modules/5.4.0-rc3+/kernel/kernel/kheaders.ko

  10 82aad2bcc3fa8ed94762356b5c14838f3bcfa6a0 ima-modsig
  sha256:3bc6ed4f0b4d6e31bc1dbc9ef844605abc7afdc6d81a57d77a1ec9407997c40
  2 /usr/lib/modules/5.4.0rc3+/kernel/kernel/kheaders.ko  sha256:77fa889b3
  5a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3
  3082029a06092a864886f70d010702a082028b30820287020101310d300b0609608648
  016503040201300b06092a864886f70d01070131820264....

  10 25b72217cc1152b44b134ce2cd68f12dfb71acb3 ima-buf
  sha256:8b58427fedcf8f4b20bc8dc007f2e232bf7285d7b93a66476321f9c2a3aa132
  b blacklisted-hash
  77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3
Signed-off-by: NNayna Jain <nayna@linux.ibm.com>
[zohar@linux.ibm.com: updated patch description]
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1572492694-6520-8-git-send-email-zohar@linux.ibm.com

process_buffer_measurement() is limited to measuring the kexec boot
command line. This patch makes process_buffer_measurement() more
generic, allowing it to measure other types of buffer data (e.g.
blacklisted binary hashes or key hashes).

process_buffer_measurement() may be called directly from an IMA hook
or as an auxiliary measurement record. In both cases the buffer
measurement is based on policy. This patch modifies the function to
conditionally retrieve the policy defined PCR and template for the IMA
hook case.
Signed-off-by: NNayna Jain <nayna@linux.ibm.com>
[zohar@linux.ibm.com: added comment in process_buffer_measurement()]
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1572492694-6520-6-git-send-email-zohar@linux.ibm.com

Systems in lockdown mode should block the kexec of untrusted kernels.
For x86 and ARM we can ensure that a kernel is trustworthy by validating
a PE signature, but this isn't possible on other architectures. On those
platforms we can use IMA digital signatures instead. Add a function to
determine whether IMA has or will verify signatures for a given event type,
and if so permit kexec_file() even if the kernel is otherwise locked down.
This is restricted to cases where CONFIG_INTEGRITY_TRUSTED_KEYRING is set
in order to prevent an attacker from loading additional keys at runtime.
Signed-off-by: NMatthew Garrett <mjg59@google.com>
Acked-by: NMimi Zohar <zohar@linux.ibm.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
Cc: linux-integrity@vger.kernel.org
Signed-off-by: NJames Morris <jmorris@namei.org>

This is a preparatory patch for kexec_file_load() lockdown.  A locked down
kernel needs to prevent unsigned kernel images from being loaded with
kexec_file_load().  Currently, the only way to force the signature
verification is compiling with KEXEC_VERIFY_SIG.  This prevents loading
usigned images even when the kernel is not locked down at runtime.

This patch splits KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE.
Analogous to the MODULE_SIG and MODULE_SIG_FORCE for modules, KEXEC_SIG
turns on the signature verification but allows unsigned images to be
loaded.  KEXEC_SIG_FORCE disallows images without a valid signature.
Signed-off-by: NJiri Bohac <jbohac@suse.cz>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NMatthew Garrett <mjg59@google.com>
cc: kexec@lists.infradead.org
Signed-off-by: NJames Morris <jmorris@namei.org>

If the IMA template contains the "modsig" or "d-modsig" field, then the
modsig should be added to the measurement list when the file is appraised.

And that is what normally happens, but if a measurement rule caused a file
containing a modsig to be measured before a different rule causes it to be
appraised, the resulting measurement entry will not contain the modsig
because it is only fetched during appraisal. When the appraisal rule
triggers, it won't store a new measurement containing the modsig because
the file was already measured.

We need to detect that situation and store an additional measurement with
the modsig. This is done by adding an IMA_MEASURE action flag if we read a
modsig and the IMA template contains a modsig field.
Suggested-by: NMimi Zohar <zohar@linux.ibm.com>
Signed-off-by: NThiago Jung Bauermann <bauerman@linux.ibm.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

Define new "d-modsig" template field which holds the digest that is
expected to match the one contained in the modsig, and also new "modsig"
template field which holds the appended file signature.

Add a new "ima-modsig" defined template descriptor with the new fields as
well as the ones from the "ima-sig" descriptor.

Change ima_store_measurement() to accept a struct modsig * argument so that
it can be passed along to the templates via struct ima_event_data.
Suggested-by: NMimi Zohar <zohar@linux.ibm.com>
Signed-off-by: NThiago Jung Bauermann <bauerman@linux.ibm.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

Obtain the modsig and calculate its corresponding hash in
ima_collect_measurement().
Signed-off-by: NThiago Jung Bauermann <bauerman@linux.ibm.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>

Implement the appraise_type=imasig|modsig option, allowing IMA to read and
verify modsig signatures.

In case a file has both an xattr signature and an appended modsig, IMA will
only use the appended signature if the key used by the xattr signature
isn't present in the IMA or platform keyring.

Because modsig verification needs to convert from an integrity keyring id
to the keyring itself, add an integrity_keyring_from_id() function in
digsig.c so that integrity_modsig_verify() can use it.
Signed-off-by: NThiago Jung Bauermann <bauerman@linux.ibm.com>
Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>