kernel/linux.git/security/apparmor/include/policy.h, branch v5.10.257

apparmor: fix race between freeing data and fs accessing it

2026-04-18T08:31:14+00:00

commit 8e135b8aee5a06c52a4347a5a6d51223c6f36ba3 upstream. Backport for conflicts introdued by - conversion from sha1 to sha256 introduced in e44a4dc4b36c ("apparmor: switch SECURITY_APPARMOR_HASH from sha1 to sha256 ") - adding of conditioanl that nests the conflicting code inside an if condition d61c57fde819 ("apparmor: make export of raw binary profile to userspace optional") AppArmor was putting the reference to i_private data on its end after removing the original entry from the file system. However the inode can and does live beyond that point and it is possible that some of the fs call back functions will be invoked after the reference has been put, which results in a race between freeing the data and accessing it through the fs. While the rawdata/loaddata is the most likely candidate to fail the race, as it has the fewest references. If properly crafted it might be possible to trigger a race for the other types stored in i_private. Fix this by moving the put of i_private referenced data to the correct place which is during inode eviction. Fixes: c961ee5f21b20 ("apparmor: convert from securityfs to apparmorfs for policy ns files") Reported-by: Qualys Security Advisory Reviewed-by: Georgia Garcia Reviewed-by: Maxime Bélair Reviewed-by: Cengiz Can Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman

apparmor: fix unprivileged local user can do privileged policy management

2026-04-18T08:31:14+00:00

commit 6601e13e82841879406bf9f369032656f441a425 upstream. Backport for api changes introduced in - 90c436a64a6e ("apparmor: pass cred through to audit info.") - 92de220a7f33 ("apparmor: update policy capable checks to use a label") An unprivileged local user can load, replace, and remove profiles by opening the apparmorfs interfaces, via a confused deputy attack, by passing the opened fd to a privileged process, and getting the privileged process to write to the interface. This does require a privileged target that can be manipulated to do the write for the unprivileged process, but once such access is achieved full policy management is possible and all the possible implications that implies: removing confinement, DoS of system or target applications by denying all execution, by-passing the unprivileged user namespace restriction, to exploiting kernel bugs for a local privilege escalation. The policy management interface can not have its permissions simply changed from 0666 to 0600 because non-root processes need to be able to load policy to different policy namespaces. Instead ensure the task writing the interface has privileges that are a subset of the task that opened the interface. This is already done via policy for confined processes, but unconfined can delegate access to the opened fd, by-passing the usual policy check. Fixes: b7fd2c0340eac ("apparmor: add per policy ns .load, .replace, .remove interface files") Reported-by: Qualys Security Advisory Tested-by: Salvatore Bonaccorso Reviewed-by: Georgia Garcia Reviewed-by: Cengiz Can Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman

apparmor: fix overlapping attachment computation

2022-08-25T09:37:53+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 PROFILE_MEDIATES for untrusted input

2019-06-18T23:04:16+00:00

While commit 11c236b89d7c2 ("apparmor: add a default null dfa") ensure every profile has a policy.dfa it does not resize the policy.start[] to have entries for every possible start value. Which means PROFILE_MEDIATES is not safe to use on untrusted input. Unforunately commit b9590ad4c4f2 ("apparmor: remove POLICY_MEDIATES_SAFE") did not take into account the start value usage. The input string in profile_query_cb() is user controlled and is not properly checked to be within the limited start[] entries, even worse it can't be as userspace policy is allowed to make us of entries types the kernel does not know about. This mean usespace can currently cause the kernel to access memory up to 240 entries beyond the start array bounds. Cc: stable@vger.kernel.org Fixes: b9590ad4c4f2 ("apparmor: remove POLICY_MEDIATES_SAFE") Signed-off-by: John Johansen

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 441

2019-06-05T15:37:17+00:00

Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation version 2 of the license extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 315 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Allison Randal Reviewed-by: Armijn Hemel Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190115.503150771@linutronix.de Signed-off-by: Greg Kroah-Hartman

apparmor: Parse secmark policy

2018-10-03T13:18:38+00:00

Add support for parsing secmark policy provided by userspace, and store that in the overall policy. Signed-off-by: Matthew Garrett Signed-off-by: John Johansen

apparmor: remove POLICY_MEDIATES_SAFE

2018-03-14T00:25:49+00:00

The unpack code now makes sure every profile has a dfa so the safe version of POLICY_MEDIATES is no longer needed. Signed-off-by: John Johansen

apparmor: add base infastructure for socket mediation

2018-03-14T00:25:48+00:00

apparmor: convert attaching profiles via xattrs to use dfa matching

2018-02-09T19:30:02+00:00

This converts profile attachment based on xattrs to a fixed extended conditional using dfa matching. This has a couple of advantages - pattern matching can be used for the xattr match - xattrs can be optional for an attachment or marked as required - the xattr attachment conditional will be able to be combined with other extended conditionals when the flexible extended conditional work lands. The xattr fixed extended conditional is appended to the xmatch conditional. If an xattr attachment is specified the profile xmatch will be generated regardless of whether there is a pattern match on the executable name. Signed-off-by: John Johansen Acked-by: Seth Arnold

apparmor: Add support for attaching profiles via xattr, presence and value

2018-02-09T19:30:02+00:00

Make it possible to tie Apparmor profiles to the presence of one or more extended attributes, and optionally their values. An example usecase for this is to automatically transition to a more privileged Apparmor profile if an executable has a valid IMA signature, which can then be appraised by the IMA subsystem. Signed-off-by: Matthew Garrett Signed-off-by: John Johansen