kernel/linux.git/security, branch v5.19.13

Smack: Provide read control for io_uring_cmd

2022-09-15T08:47:18+00:00

commit dd9373402280cf4715fdc8fd5070f7d039e43511 upstream. Limit io_uring "cmd" options to files for which the caller has Smack read access. There may be cases where the cmd option may be closer to a write access than a read, but there is no way to make that determination. Cc: stable@vger.kernel.org Fixes: ee692a21e9bf ("fs,io_uring: add infrastructure for uring-cmd") Signed-off-by: Casey Schaufler Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman

selinux: implement the security_uring_cmd() LSM hook

2022-09-15T08:47:18+00:00

commit f4d653dcaa4e4056e1630423e6a8ece4869b544f upstream. Add a SELinux access control for the iouring IORING_OP_URING_CMD command. This includes the addition of a new permission in the existing "io_uring" object class: "cmd". The subject of the new permission check is the domain of the process requesting access, the object is the open file which points to the device/file that is the target of the IORING_OP_URING_CMD operation. A sample policy rule is shown below: allow :io_uring { cmd }; Cc: stable@vger.kernel.org Fixes: ee692a21e9bf ("fs,io_uring: add infrastructure for uring-cmd") Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman

lsm,io_uring: add LSM hooks for the new uring_cmd file op

2022-09-15T08:47:18+00:00

commit 2a5840124009f133bd09fd855963551fb2cefe22 upstream. io-uring cmd support was added through ee692a21e9bf ("fs,io_uring: add infrastructure for uring-cmd"), this extended the struct file_operations to allow a new command which each subsystem can use to enable command passthrough. Add an LSM specific for the command passthrough which enables LSMs to inspect the command details. This was discussed long ago without no clear pointer for something conclusive, so this enables LSMs to at least reject this new file operation. [0] https://lkml.kernel.org/r/8adf55db-7bab-f59d-d612-ed906b948d19@schaufler-ca.com Cc: stable@vger.kernel.org Fixes: ee692a21e9bf ("fs,io_uring: add infrastructure for uring-cmd") Signed-off-by: Luis Chamberlain Acked-by: Jens Axboe Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman

landlock: Fix file reparenting without explicit LANDLOCK_ACCESS_FS_REFER

2022-09-08T09:24:02+00:00

commit 55e55920bbe3ccf516022c51f5527e7d026b8f1d upstream. This change fixes a mis-handling of the LANDLOCK_ACCESS_FS_REFER right when multiple rulesets/domains are stacked. The expected behaviour was that an additional ruleset can only restrict the set of permitted operations, but in this particular case, it was potentially possible to re-gain the LANDLOCK_ACCESS_FS_REFER right. With the introduction of LANDLOCK_ACCESS_FS_REFER, we added the first globally denied-by-default access right. Indeed, this lifted an initial Landlock limitation to rename and link files, which was initially always denied when the source or the destination were different directories. This led to an inconsistent backward compatibility behavior which was only taken into account if no domain layer were using the new LANDLOCK_ACCESS_FS_REFER right. However, when restricting a thread with a new ruleset handling LANDLOCK_ACCESS_FS_REFER, all inherited parent rulesets/layers not explicitly handling LANDLOCK_ACCESS_FS_REFER would behave as if they were handling this access right and with all their rules allowing it. This means that renaming and linking files could became allowed by these parent layers, but all the other required accesses must also be granted: all layers must allow file removal or creation, and renaming and linking operations cannot lead to privilege escalation according to the Landlock policy. See detailed explanation in commit b91c3e4ea756 ("landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER"). To say it another way, this bug may lift the renaming and linking limitations of the initial Landlock version, and a same ruleset can enforce different restrictions depending on previous or next enforced ruleset (i.e. inconsistent behavior). The LANDLOCK_ACCESS_FS_REFER right cannot give access to data not already allowed, but this doesn't follow the contract of the first Landlock ABI. This fix puts back the limitation for sandboxes that didn't opt-in for this additional right. For instance, if a first ruleset allows LANDLOCK_ACCESS_FS_MAKE_REG on /dst and LANDLOCK_ACCESS_FS_REMOVE_FILE on /src, renaming /src/file to /dst/file is denied. However, without this fix, stacking a new ruleset which allows LANDLOCK_ACCESS_FS_REFER on / would now permit the sandboxed thread to rename /src/file to /dst/file . This change fixes the (absolute) rule access rights, which now always forbid LANDLOCK_ACCESS_FS_REFER except when it is explicitly allowed when creating a rule. Making all domain handle LANDLOCK_ACCESS_FS_REFER was an initial approach but there is two downsides: * it makes the code more complex because we still want to check that a rule allowing LANDLOCK_ACCESS_FS_REFER is legitimate according to the ruleset's handled access rights (i.e. ABI v1 != ABI v2); * it would not allow to identify if the user created a ruleset explicitly handling LANDLOCK_ACCESS_FS_REFER or not, which will be an issue to audit Landlock. Instead, this change adds an ACCESS_INITIALLY_DENIED list of denied-by-default rights, which (only) contains LANDLOCK_ACCESS_FS_REFER. All domains are treated as if they are also handling this list, but without modifying their fs_access_masks field. A side effect is that the errno code returned by rename(2) or link(2) *may* be changed from EXDEV to EACCES according to the enforced restrictions. Indeed, we now have the mechanic to identify if an access is denied because of a required right (e.g. LANDLOCK_ACCESS_FS_MAKE_REG, LANDLOCK_ACCESS_FS_REMOVE_FILE) or if it is denied because of missing LANDLOCK_ACCESS_FS_REFER rights. This may result in different errno codes than for the initial Landlock version, but this approach is more consistent and better for rename/link compatibility reasons, and it wasn't possible before (hence no backport to ABI v1). The layout1.rename_file test reflects this change. Add 4 layout1.refer_denied_by_default* test suites to check that the behavior of a ruleset not handling LANDLOCK_ACCESS_FS_REFER (ABI v1) is unchanged even if another layer handles LANDLOCK_ACCESS_FS_REFER (i.e. ABI v1 precedence). Make sure rule's absolute access rights are correct by testing with and without a matching path. Add test_rename() and test_exchange() helpers. Extend layout1.inval tests to check that a denied-by-default access right is not necessarily part of a domain's handled access rights. Test coverage for security/landlock is 95.3% of 599 lines according to gcc/gcov-11. Fixes: b91c3e4ea756 ("landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER") Reviewed-by: Paul Moore Reviewed-by: Günther Noack Link: https://lore.kernel.org/r/20220831203840.1370732-1-mic@digikod.net Cc: stable@vger.kernel.org [mic: Constify and slightly simplify test helpers] Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman

apparmor: Fix memleak in aa_simple_write_to_buffer()

2022-08-25T09:45:11+00:00

commit 417ea9fe972d2654a268ad66e89c8fcae67017c3 upstream. When copy_from_user failed, the memory is freed by kvfree. however the management struct and data blob are allocated independently, so only kvfree(data) cause a memleak issue here. Use aa_put_loaddata(data) to fix this issue. Fixes: a6a52579e52b5 ("apparmor: split load data into management struct and data blob") Signed-off-by: Xiu Jianfeng Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman

apparmor: fix reference count leak in aa_pivotroot()

2022-08-25T09:45:11+00:00

commit 11c3627ec6b56c1525013f336f41b79a983b4d46 upstream. The aa_pivotroot() function has a reference counting bug in a specific path. When aa_replace_current_label() returns on success, the function forgets to decrement the reference count of “target”, which is increased earlier by build_pivotroot(), causing a reference leak. Fix it by decreasing the refcount of “target” in that path. Fixes: 2ea3ffb7782a ("apparmor: add mount mediation") Co-developed-by: Xiyu Yang Signed-off-by: Xiyu Yang Co-developed-by: Xin Tan Signed-off-by: Xin Tan Signed-off-by: Xin Xiong Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman

apparmor: fix overlapping attachment computation

2022-08-25T09:45:11+00:00

commit 2504db207146543736e877241f3b3de005cbe056 upstream. When finding the profile via patterned attachments, the longest left match is being set to the static compile time value and not using the runtime computed value. Fix this by setting the candidate value to the greater of the precomputed value or runtime computed value. Fixes: 21f606610502 ("apparmor: improve overlapping domain attachment resolution") Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman

apparmor: fix setting unconfined mode on a loaded profile

2022-08-25T09:45:11+00:00

commit 3bbb7b2e9bbcd22e539e23034da753898fe3b4dc upstream. When loading a profile that is set to unconfined mode, that label flag is not set when it should be. Ensure it is set so that when used in a label the unconfined check will be applied correctly. Fixes: 038165070aa5 ("apparmor: allow setting any profile into the unconfined state") Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman

apparmor: fix aa_label_asxprint return check

2022-08-25T09:45:11+00:00

commit 3e2a3a0830a2090e766d0d887d52c67de2a6f323 upstream. Clang static analysis reports this issue label.c:1802:3: warning: 2nd function call argument is an uninitialized value pr_info("%s", str); ^~~~~~~~~~~~~~~~~~ str is set from a successful call to aa_label_asxprint(&str, ...) On failure a negative value is returned, not a -1. So change the check. Fixes: f1bd904175e8 ("apparmor: add the base fns() for domain labels") Signed-off-by: Tom Rix Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman

apparmor: Fix failed mount permission check error message

2022-08-25T09:45:11+00:00

commit ec240b5905bbb09a03dccffee03062cf39e38dc2 upstream. When the mount check fails due to a permission check failure instead of explicitly at one of the subcomponent checks, AppArmor is reporting a failure in the flags match. However this is not true and AppArmor can not attribute the error at this point to any particular component, and should only indicate the mount failed due to missing permissions. Fixes: 2ea3ffb7782a ("apparmor: add mount mediation") Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman