user/sven/linux.git/security, branch v5.18.6

selinux: free contexts previously transferred in selinux_add_opt()

2022-06-22T12:28:10Z

commit cad140d00899e7a9cb6fe93b282051df589e671c upstream. `selinux_add_opt()` stopped taking ownership of the passed context since commit 70f4169ab421 ("selinux: parse contexts for mount options early"). unreferenced object 0xffff888114dfd140 (size 64): comm "mount", pid 15182, jiffies 4295687028 (age 796.340s) hex dump (first 32 bytes): 73 79 73 74 65 6d 5f 75 3a 6f 62 6a 65 63 74 5f system_u:object_ 72 3a 74 65 73 74 5f 66 69 6c 65 73 79 73 74 65 r:test_filesyste backtrace: [] kmemdup_nul+0x24/0x80 [] selinux_sb_eat_lsm_opts+0x293/0x560 [] security_sb_eat_lsm_opts+0x58/0x80 [] generic_parse_monolithic+0x82/0x180 [] do_new_mount+0x1f5/0x550 [] path_mount+0x2ab/0x1570 [] __x64_sys_mount+0x20e/0x280 [] do_syscall_64+0x34/0x80 [] entry_SYSCALL_64_after_hwframe+0x46/0xb0 unreferenced object 0xffff888108e71640 (size 64): comm "fsmount", pid 7607, jiffies 4295044974 (age 1601.016s) hex dump (first 32 bytes): 73 79 73 74 65 6d 5f 75 3a 6f 62 6a 65 63 74 5f system_u:object_ 72 3a 74 65 73 74 5f 66 69 6c 65 73 79 73 74 65 r:test_filesyste backtrace: [] memdup_user+0x21/0x90 [] strndup_user+0x47/0xa0 [] __do_sys_fsconfig+0x485/0x9f0 [] do_syscall_64+0x34/0x80 [] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Cc: stable@vger.kernel.org Fixes: 70f4169ab421 ("selinux: parse contexts for mount options early") Signed-off-by: Christian Göttsche Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman

KEYS: trusted: tpm2: Fix migratable logic

2022-06-14T16:45:17Z

commit dda5384313a40ecbaafd8a9a80f47483255e4c4d upstream. When creating (sealing) a new trusted key, migratable trusted keys have the FIXED_TPM and FIXED_PARENT attributes set, and non-migratable keys don't. This is backwards, and also causes creation to fail when creating a migratable key under a migratable parent. (The TPM thinks you are trying to seal a non-migratable blob under a migratable parent.) The following simple patch fixes the logic, and has been tested for all four combinations of migratable and non-migratable trusted keys and parent storage keys. With this logic, you will get a proper failure if you try to create a non-migratable trusted key under a migratable parent storage key, and all other combinations work correctly. Cc: stable@vger.kernel.org # v5.13+ Fixes: e5fb5d2c5a03 ("security: keys: trusted: Make sealed key properly interoperable") Signed-off-by: David Safford Reviewed-by: Ahmad Fatoum Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

ima: remove the IMA_TEMPLATE Kconfig option

2022-06-09T08:30:49Z

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

landlock: Fix same-layer rule unions

2022-06-09T08:30:48Z

commit 8ba0005ff418ec356e176b26eaa04a6ac755d05b upstream. The original behavior was to check if the full set of requested accesses was allowed by at least a rule of every relevant layer. This didn't take into account requests for multiple accesses and same-layer rules allowing the union of these accesses in a complementary way. As a result, multiple accesses requested on a file hierarchy matching rules that, together, allowed these accesses, but without a unique rule allowing all of them, was illegitimately denied. This case should be rare in practice and it can only be triggered by the path_rename or file_open hook implementations. For instance, if, for the same layer, a rule allows execution beneath /a/b and another rule allows read beneath /a, requesting access to read and execute at the same time for /a/b should be allowed for this layer. This was an inconsistency because the union of same-layer rule accesses was already allowed if requested once at a time anyway. This fix changes the way allowed accesses are gathered over a path walk. To take into account all these rule accesses, we store in a matrix all layer granting the set of requested accesses, according to the handled accesses. To avoid heap allocation, we use an array on the stack which is 2*13 bytes. A following commit bringing the LANDLOCK_ACCESS_FS_REFER access right will increase this size to reach 112 bytes (2*14*4) in case of link or rename actions. Add a new layout1.layer_rule_unions test to check that accesses from different rules pertaining to the same layer are ORed in a file hierarchy. Also test that it is not the case for rules from different layers. Reviewed-by: Paul Moore Link: https://lore.kernel.org/r/20220506161102.525323-5-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman

landlock: Create find_rule() from unmask_layers()

2022-06-09T08:30:48Z

commit 2cd7cd6eed88b8383cfddce589afe9c0ae1d19b4 upstream. This refactoring will be useful in a following commit. Reviewed-by: Paul Moore Link: https://lore.kernel.org/r/20220506161102.525323-4-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman

landlock: Reduce the maximum number of layers to 16

2022-06-09T08:30:47Z

commit 75c542d6c6cc48720376862d5496d51509160dfd upstream. The maximum number of nested Landlock domains is currently 64. Because of the following fix and to help reduce the stack size, let's reduce it to 16. This seems large enough for a lot of use cases (e.g. sandboxed init service, spawning a sandboxed SSH service, in nested sandboxed containers). Reducing the number of nested domains may also help to discover misuse of Landlock (e.g. creating a domain per rule). Add and use a dedicated layer_mask_t typedef to fit with the number of layers. This might be useful when changing it and to keep it consistent with the maximum number of layers. Reviewed-by: Paul Moore Link: https://lore.kernel.org/r/20220506161102.525323-3-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman

landlock: Define access_mask_t to enforce a consistent access mask size

2022-06-09T08:30:47Z

commit 5f2ff33e10843ef51275c8611bdb7b49537aba5d upstream. Create and use the access_mask_t typedef to enforce a consistent access mask size and uniformly use a 16-bits type. This will helps transition to a 32-bits value one day. Add a build check to make sure all (filesystem) access rights fit in. This will be extended with a following commit. Reviewed-by: Paul Moore Link: https://lore.kernel.org/r/20220506161102.525323-2-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman

landlock: Change landlock_restrict_self(2) check ordering

2022-06-09T08:30:47Z

commit eba39ca4b155c54adf471a69e91799cc1727873f upstream. According to the Landlock goal to be a security feature available to unprivileges processes, it makes more sense to first check for no_new_privs before checking anything else (i.e. syscall arguments). Merge inval_fd_enforce and unpriv_enforce_without_no_new_privs tests into the new restrict_self_checks_ordering. This is similar to the previous commit checking other syscalls. Link: https://lore.kernel.org/r/20220506160820.524344-10-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman

landlock: Change landlock_add_rule(2) argument check ordering

2022-06-09T08:30:47Z

commit 589172e5636c4d16c40b90e87543d43defe2d968 upstream. This makes more sense to first check the ruleset FD and then the rule attribute. It will be useful to factor out code for other rule types. Add inval_add_rule_arguments tests, extension of empty_path_beneath_attr tests, to also check error ordering for landlock_add_rule(2). Link: https://lore.kernel.org/r/20220506160820.524344-9-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman

landlock: Fix landlock_add_rule(2) documentation

2022-06-09T08:30:46Z

commit a13e248ff90e81e9322406c0e618cf2168702f4e upstream. It is not mandatory to pass a file descriptor obtained with the O_PATH flag. Also, replace rule's accesses with ruleset's accesses. Link: https://lore.kernel.org/r/20220506160820.524344-2-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman