“0d63c27d9e879a0b54eb405636d60ab12040ca46”上不存在“README.md”
- 13 11月, 2020 1 次提交
-
-
由 Chen Zhou 提交于
Fix to return a negative error code from the error handling case instead of 0 in function sel_ib_pkey_sid_slow(), as done elsewhere in this function. Cc: stable@vger.kernel.org Fixes: 409dcf31 ("selinux: Add a cache for quicker retreival of PKey SIDs") Reported-by: NHulk Robot <hulkci@huawei.com> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Signed-off-by: NPaul Moore <paul@paul-moore.com>
-
- 30 10月, 2020 1 次提交
-
-
由 Gustavo A. R. Silva 提交于
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arraysSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
-
- 18 10月, 2020 1 次提交
-
-
由 Jens Axboe 提交于
A previous commit changed the notification mode from true/false to an int, allowing notify-no, notify-yes, or signal-notify. This was backwards compatible in the sense that any existing true/false user would translate to either 0 (on notification sent) or 1, the latter which mapped to TWA_RESUME. TWA_SIGNAL was assigned a value of 2. Clean this up properly, and define a proper enum for the notification mode. Now we have: - TWA_NONE. This is 0, same as before the original change, meaning no notification requested. - TWA_RESUME. This is 1, same as before the original change, meaning that we use TIF_NOTIFY_RESUME. - TWA_SIGNAL. This uses TIF_SIGPENDING/JOBCTL_TASK_WORK for the notification. Clean up all the callers, switching their 0/1/false/true to using the appropriate TWA_* mode for notifications. Fixes: e91b4816 ("task_work: teach task_work_add() to do signal_wake_up()") Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
- 14 10月, 2020 2 次提交
-
-
由 Thomas Cedeno 提交于
Fix multiple cast-to-union warnings related to casting kuid_t and kgid_t types to kid_t union type. Also fix incompatible type warning that arises from accidental omission of "__rcu" qualifier on the struct setid_ruleset pointer in the argument list for safesetid_file_read(). Reported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NThomas Cedeno <thomascedeno@google.com> Signed-off-by: NMicah Morton <mortonm@chromium.org>
-
由 Thomas Cedeno 提交于
The SafeSetID LSM has functionality for restricting setuid() calls based on its configured security policies. This patch adds the analogous functionality for setgid() calls. This is mostly a copy-and-paste change with some code deduplication, plus slight modifications/name changes to the policy-rule-related structs (now contain GID rules in addition to the UID ones) and some type generalization since SafeSetID now needs to deal with kgid_t and kuid_t types. Signed-off-by: NThomas Cedeno <thomascedeno@google.com> Signed-off-by: NMicah Morton <mortonm@chromium.org>
-
- 12 10月, 2020 1 次提交
-
-
由 Tetsuo Handa 提交于
Since commit e2dc9bf3 ("umd: Transform fork_usermode_blob into fork_usermode_driver") started calling execve() on a program written in a local mount which is not connected to mount tree, tomoyo_realpath_from_path() started returning a pathname in "$fsname:/$pathname" format which violates TOMOYO's domainname rule that it must start with "<$namespace>" followed by zero or more repetitions of pathnames which start with '/'. Since $fsname must not contain '.' since commit 79c0b2df ("add filesystem subtype support"), tomoyo_correct_path() can recognize a token which appears '/' before '.' appears (e.g. proc:/self/exe ) as a pathname while rejecting a token which appears '.' before '/' appears (e.g. exec.realpath="/bin/bash" ) as a condition parameter. Therefore, accept domainnames which contain pathnames which do not start with '/' but contain '/' before '.' (e.g. <kernel> tmpfs:/bpfilter_umh ). Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
-
- 06 10月, 2020 1 次提交
-
-
由 Casey Schaufler 提交于
The initialization of rc in smack_from_netlbl() is pointless. Reported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
-
- 05 10月, 2020 10 次提交
-
-
由 Kees Cook 提交于
To perform partial reads, callers of kernel_read_file*() must have a non-NULL file_size argument and a preallocated buffer. The new "offset" argument can then be used to seek to specific locations in the file to fill the buffer to, at most, "buf_size" per call. Where possible, the LSM hooks can report whether a full file has been read or not so that the contents can be reasoned about. Signed-off-by: NKees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201002173828.2099543-14-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Scott Branden 提交于
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>
-
由 Kees Cook 提交于
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>
-
由 Kees Cook 提交于
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>
-
由 Kees Cook 提交于
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>
-
由 Kees Cook 提交于
In preparation for adding partial read support, add an optional output argument to kernel_read_file*() that reports the file size so callers can reason more easily about their reading progress. Signed-off-by: NKees Cook <keescook@chromium.org> Reviewed-by: NMimi Zohar <zohar@linux.ibm.com> Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org> Reviewed-by: NJames Morris <jamorris@linux.microsoft.com> Acked-by: NScott Branden <scott.branden@broadcom.com> Link: https://lore.kernel.org/r/20201002173828.2099543-8-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Kees Cook 提交于
In preparation for further refactoring of kernel_read_file*(), rename the "max_size" argument to the more accurate "buf_size", and correct its type to size_t. Add kerndoc to explain the specifics of how the arguments will be used. Note that with buf_size now size_t, it can no longer be negative (and was never called with a negative value). Adjust callers to use it as a "maximum size" when *buf is NULL. Signed-off-by: NKees Cook <keescook@chromium.org> Reviewed-by: NMimi Zohar <zohar@linux.ibm.com> Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org> Reviewed-by: NJames Morris <jamorris@linux.microsoft.com> Acked-by: NScott Branden <scott.branden@broadcom.com> Link: https://lore.kernel.org/r/20201002173828.2099543-7-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Kees Cook 提交于
In preparation for refactoring kernel_read_file*(), remove the redundant "size" argument which is not needed: it can be included in the return code, with callers adjusted. (VFS reads already cannot be larger than INT_MAX.) Signed-off-by: NKees Cook <keescook@chromium.org> Reviewed-by: NMimi Zohar <zohar@linux.ibm.com> Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org> Reviewed-by: NJames Morris <jamorris@linux.microsoft.com> Acked-by: NScott Branden <scott.branden@broadcom.com> Link: https://lore.kernel.org/r/20201002173828.2099543-6-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Scott Branden 提交于
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>
-
由 Kees Cook 提交于
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>
-
- 03 10月, 2020 2 次提交
-
-
由 Christoph Hellwig 提交于
Now that import_iovec handles compat iovecs, the native version of keyctl_instantiate_key_iov can be used for the compat case as well. Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Christoph Hellwig 提交于
Use in compat_syscall to import either native or the compat iovecs, and remove the now superflous compat_import_iovec. This removes the need for special compat logic in most callers, and the remaining ones can still be simplified by using __import_iovec with a bool compat parameter. Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 25 9月, 2020 1 次提交
-
-
由 Tianjia Zhang 提交于
Asymmetric digsig supports SM2-with-SM3 algorithm combination, so that IMA can also verify SM2's signature data. Signed-off-by: NTianjia Zhang <tianjia.zhang@linux.alibaba.com> Tested-by: NXufeng Zhang <yunbo.xufeng@linux.alibaba.com> Reviewed-by: NMimi Zohar <zohar@linux.ibm.com> Reviewed-by: NVitaly Chikunov <vt@altlinux.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 23 9月, 2020 1 次提交
-
-
由 Casey Schaufler 提交于
Use proper conditional compilation for the secmark field in the network skb. Reported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
-
- 17 9月, 2020 1 次提交
-
-
由 KP Singh 提交于
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>
-
- 16 9月, 2020 6 次提交
-
-
由 Lenny Szubowicz 提交于
Because of system-specific EFI firmware limitations, EFI volatile variables may not be capable of holding the required contents of the Machine Owner Key (MOK) certificate store when the certificate list grows above some size. Therefore, an EFI boot loader may pass the MOK certs via a EFI configuration table created specifically for this purpose to avoid this firmware limitation. An EFI configuration table is a much more primitive mechanism compared to EFI variables and is well suited for one-way passage of static information from a pre-OS environment to the kernel. This patch adds the support to load certs from the MokListRT entry in the MOK variable configuration table, if it's present. The pre-existing support to load certs from the MokListRT EFI variable remains and is used if the EFI MOK configuration table isn't present or can't be successfully used. Signed-off-by: NLenny Szubowicz <lszubowi@redhat.com> Link: https://lore.kernel.org/r/20200905013107.10457-4-lszubowi@redhat.comSigned-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Lenny Szubowicz 提交于
Move the loading of certs from the UEFI MokListRT into a separate routine to facilitate additional MokList functionality. There is no visible functional change as a result of this patch. Although the UEFI dbx certs are now loaded before the MokList certs, they are loaded onto different key rings. So the order of the keys on their respective key rings is the same. Signed-off-by: NLenny Szubowicz <lszubowi@redhat.com> Reviewed-by: NMimi Zohar <zohar@linux.ibm.com> Link: https://lore.kernel.org/r/20200905013107.10457-3-lszubowi@redhat.comSigned-off-by: NArd Biesheuvel <ardb@kernel.org>
-
由 Lakshmi Ramasubramanian 提交于
checkreqprot data member in selinux_state struct is accessed directly by SELinux functions to get and set. This could cause unexpected read or write access to this data member due to compiler optimizations and/or compiler's reordering of access to this field. Add helper functions to get and set checkreqprot data member in selinux_state struct. These helper functions use READ_ONCE and WRITE_ONCE macros to ensure atomic read or write of memory for this data member. Signed-off-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com> Suggested-by: NStephen Smalley <stephen.smalley.work@gmail.com> Suggested-by: NPaul Moore <paul@paul-moore.com> Acked-by: NStephen Smalley <stephen.smalley.work@gmail.com> Signed-off-by: NPaul Moore <paul@paul-moore.com>
-
由 Roberto Sassu 提交于
This patch checks the size for the EVM_IMA_XATTR_DIGSIG and EVM_XATTR_PORTABLE_DIGSIG types to ensure that the algorithm is read from the buffer returned by vfs_getxattr_alloc(). Cc: stable@vger.kernel.org # 4.19.x Fixes: 5feeb611 ("evm: Allow non-SHA1 digital signatures") Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com> Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
-
由 Roberto Sassu 提交于
This patch removes the unnecessary semicolon at the end of ima_get_binary_runtime_size(). Cc: stable@vger.kernel.org Fixes: d158847a ("ima: maintain memory size needed for serializing the measurement list") Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com> Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
-
由 Roberto Sassu 提交于
Errors returned by crypto_shash_update() are not checked in ima_calc_boot_aggregate_tfm() and thus can be overwritten at the next iteration of the loop. This patch adds a check after calling crypto_shash_update() and returns immediately if the result is not zero. Cc: stable@vger.kernel.org Fixes: 3323eec9 ("integrity: IMA as an integrity service provider") Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com> Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
-
- 15 9月, 2020 1 次提交
-
-
由 Alex Dewar 提交于
Issue identified with Coccinelle. Signed-off-by: NAlex Dewar <alex.dewar90@gmail.com> Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
-
- 12 9月, 2020 3 次提交
-
-
由 Casey Schaufler 提交于
Utilize the Netlabel cache mechanism for incoming packet matching. Refactor the initialization of secattr structures, as it was being done in two places. Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
-
由 Casey Schaufler 提交于
Refactor the IP send checks so that the netlabel value is set only when necessary, not on every send. Some functions get renamed as the changes made the old name misleading. Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
-
由 Casey Schaufler 提交于
Add a function smack_from_skb() that returns the Smack label identified by a network secmark. Replace the explicit uses of the secmark with this function. Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
-
- 11 9月, 2020 1 次提交
-
-
由 Stephen Smalley 提交于
Use READ_ONCE/WRITE_ONCE for all accesses to the selinux_state.policycaps booleans to prevent compiler mischief. Signed-off-by: NStephen Smalley <stephen.smalley.work@gmail.com> Signed-off-by: NPaul Moore <paul@paul-moore.com>
-
- 10 9月, 2020 2 次提交
-
-
由 Bruno Meneguele 提交于
Depending on the IMA policy rule a key may be searched for in multiple keyrings (e.g. .ima and .platform) and possibly not found. This patch improves feedback by including the keyring "description" (name) in the error message. Signed-off-by: NBruno Meneguele <bmeneg@redhat.com> [zohar@linux.ibm.com: updated commit message] Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
-
由 Bruno Meneguele 提交于
Only emit an unknown/invalid message when setting the IMA appraise mode to anything other than "enforce", when secureboot is enabled. Signed-off-by: NBruno Meneguele <bmeneg@redhat.com> [zohar@linux.ibm.com: updated commit message] Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
-
- 09 9月, 2020 2 次提交
-
-
由 Bruno Meneguele 提交于
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>
-
由 Bruno Meneguele 提交于
The "enforce" string is allowed as an option for ima_appraise= kernel paramenter per kernel-paramenters.txt and should be considered on the parameter setup checking as a matter of completeness. Also it allows futher checking on the options being passed by the user. Signed-off-by: NBruno Meneguele <bmeneg@redhat.com> Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
-
- 01 9月, 2020 3 次提交
-
-
由 Denis Efremov 提交于
Modify integrity_audit_message() to use current_uid(). Signed-off-by: NDenis Efremov <efremov@linux.com> Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
-
由 Tyler Hicks 提交于
Measuring keys is currently only supported for asymmetric keys. In the future, this might change. For now, the "func=KEY_CHECK" and "keyrings=" options are only appropriate when CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS is enabled. Make this clear at policy load so that IMA policy authors don't assume that these policy language constructs are supported. Fixes: 2b60c0ec ("IMA: Read keyrings= option from the IMA policy") Fixes: 5808611c ("IMA: Add KEY_CHECK func to measure keys") Suggested-by: NNayna Jain <nayna@linux.ibm.com> Signed-off-by: NTyler Hicks <tyhicks@linux.microsoft.com> Reviewed-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com> Reviewed-by: NNayna Jain <nayna@linux.ibm.com> Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
-
由 Tyler Hicks 提交于
The ima_keyrings buffer was used as a work buffer for strsep()-based parsing of the "keyrings=" option of an IMA policy rule. This parsing was re-performed each time an asymmetric key was added to a kernel keyring for each loaded policy rule that contained a "keyrings=" option. An example rule specifying this option is: measure func=KEY_CHECK keyrings=a|b|c The rule says to measure asymmetric keys added to any of the kernel keyrings named "a", "b", or "c". The size of the buffer size was equal to the size of the largest "keyrings=" value seen in a previously loaded rule (5 + 1 for the NUL-terminator in the previous example) and the buffer was pre-allocated at the time of policy load. The pre-allocated buffer approach suffered from a couple bugs: 1) There was no locking around the use of the buffer so concurrent key add operations, to two different keyrings, would result in the strsep() loop of ima_match_keyring() to modify the buffer at the same time. This resulted in unexpected results from ima_match_keyring() and, therefore, could cause unintended keys to be measured or keys to not be measured when IMA policy intended for them to be measured. 2) If the kstrdup() that initialized entry->keyrings in ima_parse_rule() failed, the ima_keyrings buffer was freed and set to NULL even when a valid KEY_CHECK rule was previously loaded. The next KEY_CHECK event would trigger a call to strcpy() with a NULL destination pointer and crash the kernel. Remove the need for a pre-allocated global buffer by parsing the list of keyrings in a KEY_CHECK rule at the time of policy load. The ima_rule_entry will contain an array of string pointers which point to the name of each keyring specified in the rule. No string processing needs to happen at the time of asymmetric key add so iterating through the list and doing a string comparison is all that's required at the time of policy check. In the process of changing how the "keyrings=" policy option is handled, a couple additional bugs were fixed: 1) The rule parser accepted rules containing invalid "keyrings=" values such as "a|b||c", "a|b|", or simply "|". 2) The /sys/kernel/security/ima/policy file did not display the entire "keyrings=" value if the list of keyrings was longer than what could fit in the fixed size tbuf buffer in ima_policy_show(). Fixes: 5c7bac9f ("IMA: pre-allocate buffer to hold keyrings string") Fixes: 2b60c0ec ("IMA: Read keyrings= option from the IMA policy") Signed-off-by: NTyler Hicks <tyhicks@linux.microsoft.com> Reviewed-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com> Reviewed-by: NNayna Jain <nayna@linux.ibm.com> Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
-