29 Jul, 2022
1 commit
-
commit 543ce63b664e2c2f9533d089a4664b559c3e6b5b upstream.
The lockdown LSM is primarily used in conjunction with UEFI Secure Boot.
This LSM may also be used on machines without UEFI. It can also be
enabled when UEFI Secure Boot is disabled. One of lockdown's features
is to prevent kexec from loading untrusted kernels. Lockdown can be
enabled through a bootparam or after the kernel has booted through
securityfs.If IMA appraisal is used with the "ima_appraise=log" boot param,
lockdown can be defeated with kexec on any machine when Secure Boot is
disabled or unavailable. IMA prevents setting "ima_appraise=log" from
the boot param when Secure Boot is enabled, but this does not cover
cases where lockdown is used without Secure Boot.To defeat lockdown, boot without Secure Boot and add ima_appraise=log to
the kernel command line; then:$ echo "integrity" > /sys/kernel/security/lockdown
$ echo "appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig" > \
/sys/kernel/security/ima/policy
$ kexec -ls unsigned-kernelAdd a call to verify ima appraisal is set to "enforce" whenever lockdown
is enabled. This fixes CVE-2022-21505.Cc: stable@vger.kernel.org
Fixes: 29d3c1c8dfe7 ("kexec: Allow kexec_file() with appropriate IMA policy when locked down")
Signed-off-by: Eric Snowberg
Acked-by: Mimi Zohar
Reviewed-by: John Haxby
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
22 Jul, 2022
4 commits
-
[ Upstream commit 067d2521874135267e681c19d42761c601d503d6 ]
On failure to allocate the SHA1 tfm, IMA fails to initialize and exits
without freeing the ima_algo_array. Add the missing kfree() for
ima_algo_array to avoid the potential memory leak.Signed-off-by: Jianglei Nie
Fixes: 6d94809af6b0 ("ima: Allocate and initialize tfm for each PCR bank")
Signed-off-by: Mimi Zohar
Signed-off-by: Sasha Levin -
[ Upstream commit af16df54b89dee72df253abc5e7b5e8a6d16c11c ]
Currently, an unsigned kernel could be kexec'ed when IMA arch specific
policy is configured unless lockdown is enabled. Enforce kernel
signature verification check in the kexec_file_load syscall when IMA
arch specific policy is configured.Fixes: 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")
Reported-and-suggested-by: Mimi Zohar
Signed-off-by: Coiby Xu
Signed-off-by: Mimi Zohar
Signed-off-by: Sasha Levin -
[ Upstream commit d2ee2cfc4aa85ff6a2a3b198a3a524ec54e3d999 ]
When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be
negative, which may cause the integer overflow problem.Fixes: 39b07096364a ("ima: Implement support for module-style appended signatures")
Signed-off-by: Huaxin Lu
Signed-off-by: Mimi Zohar
Signed-off-by: Sasha Levin -
commit 51dd64bb99e4478fc5280171acd8e1b529eadaf7 upstream.
This reverts commit ccf11dbaa07b328fa469415c362d33459c140a37.
Commit ccf11dbaa07b ("evm: Fix memleak in init_desc") said there is
memleak in init_desc. That may be incorrect, as we can see, tmp_tfm is
saved in one of the two global variables hmac_tfm or evm_tfm[hash_algo],
then if init_desc is called next time, there is no need to alloc tfm
again, so in the error path of kmalloc desc or crypto_shash_init(desc),
It is not a problem without freeing tmp_tfm.And also that commit did not reset the global variable to NULL after
freeing tmp_tfm and this makes *tfm a dangling pointer which may cause a
UAF issue.Reported-by: Guozihua (Scott)
Signed-off-by: Xiu Jianfeng
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
09 Jun, 2022
2 commits
-
commit 891163adf180bc369b2f11c9dfce6d2758d2a5bd upstream.
The original 'ima' measurement list template contains a hash, defined
as 20 bytes, and a null terminated pathname, limited to 255
characters. Other measurement list templates permit both larger hashes
and longer pathnames. When the "ima" template is configured as the
default, a new measurement list template (ima_template=) must be
specified before specifying a larger hash algorithm (ima_hash=) on the
boot command line.To avoid this boot command line ordering issue, remove the legacy "ima"
template configuration option, allowing it to still be specified on the
boot command line.The root cause of this issue is that during the processing of ima_hash,
we would try to check whether the hash algorithm is compatible with the
template. If the template is not set at the moment we do the check, we
check the algorithm against the configured default template. If the
default template is "ima", then we reject any hash algorithm other than
sha1 and md5.For example, if the compiled default template is "ima", and the default
algorithm is sha1 (which is the current default). In the cmdline, we put
in "ima_hash=sha256 ima_template=ima-ng". The expected behavior would be
that ima starts with ima-ng as the template and sha256 as the hash
algorithm. However, during the processing of "ima_hash=",
"ima_template=" has not been processed yet, and hash_setup would check
the configured hash algorithm against the compiled default: ima, and
reject sha256. So at the end, the hash algorithm that is actually used
will be sha1.With template "ima" removed from the configured default, we ensure that
the default tempalte would at least be "ima-ng" which allows for
basically any hash algorithm.This change would not break the algorithm compatibility checks for IMA.
Fixes: 4286587dccd43 ("ima: add Kconfig default measurement list template")
Signed-off-by: GUO Zihua
Cc:
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman -
commit 155ca952c7ca19aa32ecfb7373a32bbc2e1ec6eb upstream.
On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables
at early boot to load UEFI Secure Boot certificates, a page fault occurs
in Apple firmware code and EFI runtime services are disabled with the
following logs:[Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000
WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0
(Removed some logs from here)
Call Trace:
page_fault_oops+0x4f/0x2c0
? search_bpf_extables+0x6b/0x80
? search_module_extables+0x50/0x80
? search_exception_tables+0x5b/0x60
kernelmode_fixup_or_oops+0x9e/0x110
__bad_area_nosemaphore+0x155/0x190
bad_area_nosemaphore+0x16/0x20
do_kern_addr_fault+0x8c/0xa0
exc_page_fault+0xd8/0x180
asm_exc_page_fault+0x1e/0x30
(Removed some logs from here)
? __efi_call+0x28/0x30
? switch_mm+0x20/0x30
? efi_call_rts+0x19a/0x8e0
? process_one_work+0x222/0x3f0
? worker_thread+0x4a/0x3d0
? kthread+0x17a/0x1a0
? process_one_work+0x3f0/0x3f0
? set_kthread_struct+0x40/0x40
? ret_from_fork+0x22/0x30
---[ end trace 1f82023595a5927f ]---
efi: Froze efi_rts_wq and disabled EFI Runtime Services
integrity: Couldn't get size: 0x8000000000000015
integrity: MODSIGN: Couldn't get UEFI db list
efi: EFI Runtime Services are disabled!
integrity: Couldn't get size: 0x8000000000000015
integrity: Couldn't get UEFI dbx list
integrity: Couldn't get size: 0x8000000000000015
integrity: Couldn't get mokx list
integrity: Couldn't get size: 0x80000000So we avoid reading these UEFI variables and thus prevent the crash.
Cc: stable@vger.kernel.org
Signed-off-by: Aditya Garg
Reviewed-by: Mimi Zohar
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
08 Apr, 2022
1 commit
-
[ Upstream commit f2544f5e6c691679d56bb38637d2f347075b36fa ]
__setup() handlers should return 1 if the parameter is handled.
Returning 0 causes the entire string to be added to init's
environment strings (limited to 32 strings), unnecessarily polluting it.Using the documented string "evm=fix" causes an Unknown parameter message:
Unknown kernel command line parameters
"BOOT_IMAGE=/boot/bzImage-517rc5 evm=fix", will be passed to user space.and that string is added to init's environment string space:
Run /sbin/init as init process
with arguments:
/sbin/init
with environment:
HOME=/
TERM=linux
BOOT_IMAGE=/boot/bzImage-517rc5
evm=fixWith this change, using "evm=fix" acts as expected and an invalid
option ("evm=evm") causes a warning to be printed:
evm: invalid "evm" mode
but init's environment is not polluted with this string, as expected.Fixes: 7102ebcd65c1 ("evm: permit only valid security.evm xattrs to be updated")
Signed-off-by: Randy Dunlap
Reported-by: Igor Zhbanov
Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Signed-off-by: Mimi Zohar
Signed-off-by: Sasha Levin
16 Feb, 2022
5 commits
-
commit 89677197ae709eb1ab3646952c44f6a171c9e74c upstream.
Before printing a policy rule scan for inactive LSM labels in the policy
rule. Inactive LSM labels are identified by args_p != NULL and
rule == NULL.Fixes: 483ec26eed42 ("ima: ima/lsm policy rule loading logic bug fixes")
Signed-off-by: Stefan Berger
Cc: # v5.6+
Acked-by: Christian Brauner
[zohar@linux.ibm.com: Updated "Fixes" tag]
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman -
commit bb8e52e4906f148c2faf6656b5106cf7233e9301 upstream.
Commit c2426d2ad5027 ("ima: added support for new kernel cmdline parameter
ima_template_fmt") introduced an additional check on the ima_template
variable to avoid multiple template selection.Unfortunately, ima_template could be also set by the setup function of the
ima_hash= parameter, when it calls ima_template_desc_current(). This causes
attempts to choose a new template with ima_template= or with
ima_template_fmt=, after ima_hash=, to be ignored.Achieve the goal of the commit mentioned with the new static variable
template_setup_done, so that template selection requests after ima_hash=
are not ignored.Finally, call ima_init_template_list(), if not already done, to initialize
the list of templates before lookup_template_desc() is called.Reported-by: Guo Zihua
Signed-off-by: Roberto Sassu
Cc: stable@vger.kernel.org
Fixes: c2426d2ad5027 ("ima: added support for new kernel cmdline parameter ima_template_fmt")
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman -
commit f7333b9572d0559e00352a926c92f29f061b4569 upstream.
The removal of ima_dir currently fails since ima_policy still exists, so
remove the ima_policy file before removing the directory.Fixes: 4af4662fa4a9 ("integrity: IMA policy")
Signed-off-by: Stefan Berger
Cc:
Acked-by: Christian Brauner
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman -
commit 926fd9f23b27ca6587492c3f58f4c7f4cd01dad5 upstream.
Don't leak a reference to the key if its algorithm is unknown.
Fixes: 947d70597236 ("ima: Support EC keys for signature verification")
Cc: # v5.13+
Signed-off-by: Eric Biggers
Reviewed-by: Stefan Berger
Reviewed-by: Tianjia Zhang
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman -
commit 83230351c523b04ff8a029a4bdf97d881ecb96fc upstream.
audit_log_start() returns audit_buffer pointer on success or NULL on
error, so it is better to check the return value of it.Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
Signed-off-by: Xiaoke Wang
Cc:
Reviewed-by: Paul Moore
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
19 Nov, 2021
2 commits
-
[ Upstream commit eb0782bbdfd0d7c4786216659277c3fd585afc0e ]
The current IMA ruleset is identified by the variable "ima_rules"
that default to "&ima_default_rules". When loading a custom policy
for the first time, the variable is updated to "&ima_policy_rules"
instead. That update isn't RCU-safe, and deadlocks are possible.
Indeed, some functions like ima_match_policy() may loop indefinitely
when traversing "ima_default_rules" with list_for_each_entry_rcu().When iterating over the default ruleset back to head, if the list
head is "ima_default_rules", and "ima_rules" have been updated to
"&ima_policy_rules", the loop condition (&entry->list != ima_rules)
stays always true, traversing won't terminate, causing a soft lockup
and RCU stalls.Introduce a temporary value for "ima_rules" when iterating over
the ruleset to avoid the deadlocks.Signed-off-by: liqiong
Reviewed-by: THOBY Simon
Fixes: 38d859f991f3 ("IMA: policy can now be updated multiple times")
Reported-by: kernel test robot (Fix sparse: incompatible types in comparison expression.)
Signed-off-by: Mimi Zohar
Signed-off-by: Sasha Levin -
commit 32ba540f3c2a7ef61ed5a577ce25069a3d714fc9 upstream.
The evm_fixmode is only configurable by command-line option and it is never
modified outside initcalls, so declaring it with __ro_after_init is better.Signed-off-by: Austin Kim
Cc: stable@vger.kernel.org
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
03 Sep, 2021
1 commit
-
Pull integrity subsystem updates from Mimi Zohar:
- Limit the allowed hash algorithms when writing security.ima xattrs or
verifying them, based on the IMA policy and the configured hash
algorithms.- Return the calculated "critical data" measurement hash and size to
avoid code duplication. (Preparatory change for a proposed LSM.)- and a single patch to address a compiler warning.
* tag 'integrity-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity:
IMA: reject unknown hash algorithms in ima_get_hash_algo
IMA: prevent SETXATTR_CHECK policy rules with unavailable algorithms
IMA: introduce a new policy option func=SETXATTR_CHECK
IMA: add a policy option to restrict xattr hash algorithms on appraisal
IMA: add support to restrict the hash algorithms used for file appraisal
IMA: block writes of the security.ima xattr with unsupported algorithms
IMA: remove the dependency on CRYPTO_MD5
ima: Add digest and digest_len params to the functions to measure a buffer
ima: Return int in the functions to measure a buffer
ima: Introduce ima_get_current_hash_algo()
IMA: remove -Wmissing-prototypes warning
01 Sep, 2021
1 commit
-
…/device-mapper/linux-dm
Pull device mapper updates from Mike Snitzer:
- Add DM infrastructure for IMA-based remote attestion. These changes
are the basis for deploying DM-based storage in a "cloud" that must
validate configurations end-users run to maintain trust. These DM
changes allow supported DM targets' configurations to be measured via
IMA. But the policy and enforcement (of which configurations are
valid) is managed by something outside the kernel (e.g. Keylime).- Fix DM crypt scalability regression on systems with many cpus due to
percpu_counter spinlock contention in crypt_page_alloc().- Use in_hardirq() instead of deprecated in_irq() in DM crypt.
- Add event counters to DM writecache to allow users to further assess
how the writecache is performing.- Various code cleanup in DM writecache's main IO mapping function.
* tag 'for-5.15/dm-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm crypt: use in_hardirq() instead of deprecated in_irq()
dm ima: update dm documentation for ima measurement support
dm ima: update dm target attributes for ima measurements
dm ima: add a warning in dm_init if duplicate ima events are not measured
dm ima: prefix ima event name related to device mapper with dm_
dm ima: add version info to dm related events in ima log
dm ima: prefix dm table hashes in ima log with hash algorithm
dm crypt: Avoid percpu_counter spinlock contention in crypt_page_alloc()
dm: add documentation for IMA measurement support
dm: update target status functions to support IMA measurement
dm ima: measure data on device rename
dm ima: measure data on table clear
dm ima: measure data on device remove
dm ima: measure data on device resume
dm ima: measure data on table load
dm writecache: add event counters
dm writecache: report invalid return from writecache_map helpers
dm writecache: further writecache_map() cleanup
dm writecache: factor out writecache_map_remap_origin()
dm writecache: split up writecache_map() to improve code readability
27 Aug, 2021
1 commit
-
When print GUIDs supply pointer to the efi_guid_t (guid_t) type rather
its internal members.Signed-off-by: Andy Shevchenko
Reviewed-by: Serge Hallyn
Signed-off-by: Ard Biesheuvel
24 Aug, 2021
1 commit
-
The new function validate_hash_algo() assumed that ima_get_hash_algo()
always return a valid 'enum hash_algo', but it returned the
user-supplied value present in the digital signature without
any bounds checks.Update ima_get_hash_algo() to always return a valid hash algorithm,
defaulting on 'ima_hash_algo' when the user-supplied value inside
the xattr is invalid.Signed-off-by: THOBY Simon
Reported-by: syzbot+e8bafe7b82c739eaf153@syzkaller.appspotmail.com
Fixes: 50f742dd9147 ("IMA: block writes of the security.ima xattr with unsupported algorithms")
Reviewed-by: Lakshmi Ramasubramanian
Signed-off-by: Mimi Zohar
17 Aug, 2021
6 commits
-
SETXATTR_CHECK policy rules assume that any algorithm listed in the
'appraise_algos' flag must be accepted when performing setxattr() on
the security.ima xattr. However nothing checks that they are
available in the current kernel. A userland application could hash
a file with a digest that the kernel wouldn't be able to verify.
However, if SETXATTR_CHECK is not in use, the kernel already forbids
that xattr write.Verify that algorithms listed in appraise_algos are available to the
current kernel and reject the policy update otherwise. This will fix
the inconsistency between SETXATTR_CHECK and non-SETXATTR_CHECK
behaviors.That filtering is only performed in ima_parse_appraise_algos() when
updating policies so that we do not have to pay the price of
allocating a hash object every time validate_hash_algo() is called
in ima_inode_setxattr().Signed-off-by: THOBY Simon
Signed-off-by: Mimi Zohar -
While users can restrict the accepted hash algorithms for the
security.ima xattr file signature when appraising said file, users
cannot restrict the algorithms that can be set on that attribute:
any algorithm built in the kernel is accepted on a write.Define a new value for the ima policy option 'func' that restricts
globally the hash algorithms accepted when writing the security.ima
xattr.When a policy contains a rule of the form
appraise func=SETXATTR_CHECK appraise_algos=sha256,sha384,sha512
only values corresponding to one of these three digest algorithms
will be accepted for writing the security.ima xattr. Attempting to
write the attribute using another algorithm (or "free-form" data)
will be denied with an audit log message. In the absence of such a
policy rule, the default is still to only accept hash algorithms
built in the kernel (with all the limitations that entails).Signed-off-by: THOBY Simon
Reviewed-by: Lakshmi Ramasubramanian
Signed-off-by: Mimi Zohar -
The kernel has the ability to restrict the set of hash algorithms it
accepts for the security.ima xattr when it appraises files.Define a new IMA policy rule option "appraise_algos=", using the
mentioned mechanism to expose a user-toggable policy knob to opt-in
to that restriction and select the desired set of algorithms that
must be accepted.When a policy rule uses the 'appraise_algos' option, appraisal of a
file referenced by that rule will now fail if the digest algorithm
employed to hash the file was not one of those explicitly listed in
the option. In its absence, any hash algorithm compiled in the
kernel will be accepted.For example, on a system where SELinux is properly deployed, the rule
appraise func=BPRM_CHECK obj_type=iptables_exec_t \
appraise_algos=sha256,sha384
will block the execution of iptables if the xattr security.ima of its
executables were not hashed with either sha256 or sha384.Signed-off-by: THOBY Simon
Reviewed-by: Lakshmi Ramasubramanian
Signed-off-by: Mimi Zohar -
The kernel accepts any hash algorithm as a value for the security.ima
xattr. Users may wish to restrict the accepted algorithms to only
support strong cryptographic ones.Provide the plumbing to restrict the permitted set of hash algorithms
used for verifying file hashes and signatures stored in security.ima
xattr.Signed-off-by: THOBY Simon
Reviewed-by: Lakshmi Ramasubramanian
Signed-off-by: Mimi Zohar -
By default, writes to the extended attributes security.ima will be
allowed even if the hash algorithm used for the xattr is not compiled
in the kernel (which does not make sense because the kernel would not
be able to appraise that file as it lacks support for validating the
hash).Prevent and audit writes to the security.ima xattr if the hash algorithm
used in the new value is not available in the current kernel.Signed-off-by: THOBY Simon
Reviewed-by: Lakshmi Ramasubramanian
Signed-off-by: Mimi Zohar -
MD5 is a weak digest algorithm that shouldn't be used for cryptographic
operation. It hinders the efficiency of a patch set that aims to limit
the digests allowed for the extended file attribute namely security.ima.
MD5 is no longer a requirement for IMA, nor should it be used there.The sole place where we still use the MD5 algorithm inside IMA is setting
the ima_hash algorithm to MD5, if the user supplies 'ima_hash=md5'
parameter on the command line. With commit ab60368ab6a4 ("ima: Fallback
to the builtin hash algorithm"), setting "ima_hash=md5" fails gracefully
when CRYPTO_MD5 is not set:
ima: Can not allocate md5 (reason: -2)
ima: Allocating md5 failed, going to use default hash algorithm sha256Remove the CRYPTO_MD5 dependency for IMA.
Signed-off-by: THOBY Simon
Reviewed-by: Lakshmi Ramasubramanian
[zohar@linux.ibm.com: include commit number in patch description for
stable.]
Cc: stable@vger.kernel.org # 4.17
Signed-off-by: Mimi Zohar
11 Aug, 2021
1 commit
-
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: Tushar Sugandhi
Signed-off-by: Colin Ian King # leak fix
Signed-off-by: Mike Snitzer
23 Jul, 2021
4 commits
-
This patch performs the final modification necessary to pass the buffer
measurement to callers, so that they provide a functionality similar to
ima_file_hash(). It adds the 'digest' and 'digest_len' parameters to
ima_measure_critical_data() and process_buffer_measurement().These functions calculate the digest even if there is no suitable rule in
the IMA policy and, in this case, they simply return 1 before generating a
new measurement entry.Signed-off-by: Roberto Sassu
Reviewed-by: Lakshmi Ramasubramanian
Signed-off-by: Mimi Zohar -
ima_measure_critical_data() and process_buffer_measurement() currently
don't return a result as, unlike appraisal-related functions, the result is
not used by callers to deny an operation. Measurement-related functions
instead rely on the audit subsystem to notify the system administrator when
an error occurs.However, ima_measure_critical_data() and process_buffer_measurement() are a
special case, as these are the only functions that can return a buffer
measurement (for files, there is ima_file_hash()). In a subsequent patch,
they will be modified to return the calculated digest.In preparation to return the result of the digest calculation, this patch
modifies the return type from void to int, and returns 0 if the buffer has
been successfully measured, a negative value otherwise.Given that the result of the measurement is still not necessary, this patch
does not modify the behavior of existing callers by processing the returned
value. For those, the return value is ignored.Signed-off-by: Roberto Sassu
Reviewed-by: Lakshmi Ramasubramanian
Acked-by: Paul Moore (for the SELinux bits)
Signed-off-by: Mimi Zohar -
Buffer measurements, unlike file measurements, are not accessible after the
measurement is done, as buffers are not suitable for use with the
integrity_iint_cache structure (there is no index, for files it is the
inode number). In the subsequent patches, the measurement (digest) will be
returned directly by the functions that perform the buffer measurement,
ima_measure_critical_data() and process_buffer_measurement().A caller of those functions also needs to know the algorithm used to
calculate the digest. Instead of adding the algorithm as a new parameter to
the functions, this patch provides it separately with the new function
ima_get_current_hash_algo().Since the hash algorithm does not change after the IMA setup phase, there
is no risk of races (obtaining a digest calculated with a different
algorithm than the one returned).Signed-off-by: Roberto Sassu
Reviewed-by: Lakshmi Ramasubramanian
[zohar@linux.ibm.com: annotate ima_hash_algo as __ro_after_init]
Signed-off-by: Mimi Zohar -
With W=1 build, the compiler throws warning message as below:
security/integrity/ima/ima_mok.c:24:12: warning:
no previous prototype for ‘ima_mok_init’ [-Wmissing-prototypes]
__init int ima_mok_init(void)Silence the warning by adding static keyword to ima_mok_init().
Signed-off-by: Austin Kim
Fixes: 41c89b64d718 ("IMA: create machine owner and blacklist keyrings")
Cc: stable@vger.kernel.org
Signed-off-by: Mimi Zohar
21 Jun, 2021
1 commit
-
The kernel and the user obtain an xattr value in two different ways:
kernel (EVM): uses vfs_getxattr_alloc() which obtains the xattr value from
the filesystem handler (raw value);user (ima-evm-utils): uses vfs_getxattr() which obtains the xattr value
from the LSMs (normalized value).Normally, this does not have an impact unless security.selinux is set with
setfattr, with a value not terminated by '\0' (this is not the recommended
way, security.selinux should be set with the appropriate tools such as
chcon and restorecon).In this case, the kernel and the user see two different xattr values: the
former sees the xattr value without '\0' (raw value), the latter sees the
value with '\0' (value normalized by SELinux).This could result in two different verification outcomes from EVM and
ima-evm-utils, if a signature was calculated with a security.selinux value
terminated by '\0' and the value set in the filesystem is not terminated by
'\0'. The former would report verification failure due to the missing '\0',
while the latter would report verification success (because it gets the
normalized value with '\0').This patch mitigates this issue by comparing in evm_calc_hmac_or_hash() the
size of the xattr returned by the two xattr functions and by warning the
user if there is a discrepancy.Signed-off-by: Roberto Sassu
Suggested-by: Mimi Zohar
Signed-off-by: Mimi Zohar
20 Jun, 2021
1 commit
-
Output the data used in calculating the EVM digest and the resulting
digest as ascii hexadecimal strings.Suggested-by: Lakshmi Ramasubramanian (CONFIG_DYNAMIC_DEBUG)
Reviewed-by: Lakshmi Ramasubramanian
Reported-by: kernel test robot (Use %zu for size_t)
Signed-off-by: Mimi Zohar
12 Jun, 2021
1 commit
-
IMA measures contents of a given file/buffer/critical-data record,
and properly re-measures it on change. However, IMA does not measure
the duplicate value for a given record, since TPM extend is a very
expensive operation. For example, if the record changes from value
'v#1' to 'v#2', and then back to 'v#1', IMA will not measure and log
the last change to 'v#1', since the hash of 'v#1' for that record is
already present in the IMA htable. This limits the ability of an
external attestation service to accurately determine the current state
of the system. The service would incorrectly conclude that the latest
value of the given record on the system is 'v#2', and act accordingly.Define and use a new Kconfig option IMA_DISABLE_HTABLE to permit
duplicate records in the IMA measurement list.In addition to the duplicate measurement records described above,
other duplicate file measurement records may be included in the log,
when CONFIG_IMA_DISABLE_HTABLE is enabled. For example,
- i_version is not enabled,
- i_generation changed,
- same file present on different filesystems,
- an inode is evicted from dcacheSigned-off-by: Tushar Sugandhi
Reviewed-by: Petr Vorel
[zohar@linux.ibm.com: updated list of duplicate measurement records]
Signed-off-by: Mimi Zohar
11 Jun, 2021
2 commits
-
The function prototype for ima_add_kexec_buffer() is present
in 'linux/ima.h'. But this header file is not included in
ima_kexec.c where the function is implemented. This results
in the following compiler warning when "-Wmissing-prototypes" flag
is turned on:security/integrity/ima/ima_kexec.c:81:6: warning: no previous prototype
for function 'ima_add_kexec_buffer' [-Wmissing-prototypes]Include the header file 'linux/ima.h' in ima_kexec.c to fix
the compiler warning.Fixes: dce92f6b11c3 (arm64: Enable passing IMA log to next kernel on kexec)
Reported-by: kernel test robot
Signed-off-by: Lakshmi Ramasubramanian
Acked-by: Rob Herring
Signed-off-by: Mimi Zohar -
Differentiate between an invalid EVM portable signature failure
from other EVM HMAC/signature failures.Reviewed-by: Roberto Sassu
Signed-off-by: Mimi Zohar
09 Jun, 2021
5 commits
-
In preparation to enable -Wimplicit-fallthrough for Clang, fix a
fall-through warning by explicitly adding a break statement instead
of just letting the code fall through to the next case.Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Kees Cook
Signed-off-by: Mimi Zohar -
This patch fixes the sparse warning:
sparse: warning: Using plain integer as NULL pointer
Signed-off-by: Roberto Sassu
Signed-off-by: Mimi Zohar -
This patch fixes the sparse warning for ima_post_key_create_or_update() by
adding the header file that defines the prototype (linux/ima.h).Signed-off-by: Roberto Sassu
Signed-off-by: Mimi Zohar -
The endianness of a variable written to the measurement list cannot be
determined at compile time, as it depends on the value of the
ima_canonical_fmt global variable (set through a kernel option with the
same name if the machine is big endian).If ima_canonical_fmt is false, the endianness of a variable is the same as
the machine; if ima_canonical_fmt is true, the endianness is little endian.
The warning arises due to this type of instruction:var = cpu_to_leXX(var)
which tries to assign a value in little endian to a variable with native
endianness (little or big endian).Given that the variables set with this instruction are not used in any
operation but just written to a buffer, it is safe to force the type of the
value being set to be the same of the type of the variable with:var = (__force )cpu_to_leXX(var)
Reported-by: kernel test robot
Signed-off-by: Roberto Sassu
Signed-off-by: Mimi Zohar -
The code expects that the values being parsed from a buffer when the
ima_canonical_fmt global variable is true are in little endian. Thus, this
patch sets the casting types accordingly.Reported-by: kernel test robot
Signed-off-by: Roberto Sassu
Signed-off-by: Mimi Zohar
