kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-15 19:56:03 +00:00
Code Issues Releases Packages Activity
linux/security/apparmor/include/policy.h

450 lines
12 KiB
Raw Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 441 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 <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190115.503150771@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-01 10:08:55 +02:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: support querying extended trusted helper extra data Allow a profile to carry extra data that can be queried via userspace. This provides a means to store extra data in a profile that a trusted helper can extract and use from live policy. Signed-off-by: William Hua <william.hua@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-15 16:49:28 -08:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: move lib definitions into separate lib include Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-16 00:42:13 -08:00
apparmor: switch from profiles to using labels on contexts Begin the actual switch to using domain labels by storing them on the context and converting the label to a singular profile where possible. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-06-09 08:14:28 -07:00
apparmor: add base infastructure for socket mediation version 2 - Force an abi break. Network mediation will only be available in v8 abi complaint policy. Provide a basic mediation of sockets. This is not a full net mediation but just whether a spcific family of socket can be used by an application, along with setting up some basic infrastructure for network mediation to follow. the user space rule hav the basic form of NETWORK RULE = [ QUALIFIERS ] 'network' [ DOMAIN ] [ TYPE | PROTOCOL ] DOMAIN = ( 'inet' | 'ax25' | 'ipx' | 'appletalk' | 'netrom' | 'bridge' | 'atmpvc' | 'x25' | 'inet6' | 'rose' | 'netbeui' | 'security' | 'key' | 'packet' | 'ash' | 'econet' | 'atmsvc' | 'sna' | 'irda' | 'pppox' | 'wanpipe' | 'bluetooth' | 'netlink' | 'unix' | 'rds' | 'llc' | 'can' | 'tipc' | 'iucv' | 'rxrpc' | 'isdn' | 'phonet' | 'ieee802154' | 'caif' | 'alg' | 'nfc' | 'vsock' | 'mpls' | 'ib' | 'kcm' ) ',' TYPE = ( 'stream' | 'dgram' | 'seqpacket' | 'rdm' | 'raw' | 'packet' ) PROTOCOL = ( 'tcp' | 'udp' | 'icmp' ) eg. network, network inet, Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2017-07-18 23:18:33 -07:00
apparmor: move permissions into their own file to be more easily shared Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-05-26 01:57:09 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: split apparmor policy namespaces code into its own file Policy namespaces will be diverging from profile management and expanding so put it in its own file. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-16 00:42:15 -08:00
apparmor: rename namespace to ns to improve code line lengths Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-16 00:42:16 -08:00
apparmor: split apparmor policy namespaces code into its own file Policy namespaces will be diverging from profile management and expanding so put it in its own file. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-16 00:42:15 -08:00
apparmor: add ns being viewed as a param to policy_view_capable() Prepare for a tighter pairing of user namespaces and apparmor policy namespaces, by making the ns to be viewed available and checking that the user namespace level is the same as the policy ns level. This strict pairing will be relaxed once true support of user namespaces lands. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-16 00:42:50 -08:00
apparmor: allow restricting unprivileged change_profile unprivileged unconfined can use change_profile to alter the confinement set by the mac admin. Allow restricting unprivileged unconfined by still allowing change_profile but stacking the change against unconfined. This allows unconfined to still apply system policy but allows the task to enter the new confinement. If unprivileged unconfined is required a sysctl is provided to switch to the previous behavior. Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2023-08-09 00:26:36 -07:00
apparmor: add ns being viewed as a param to policy_view_capable() Prepare for a tighter pairing of user namespaces and apparmor policy namespaces, by making the ns to be viewed available and checking that the user namespace level is the same as the policy ns level. This strict pairing will be relaxed once true support of user namespaces lands. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-16 00:42:50 -08:00
apparmor: add interface files for profiles and namespaces Add basic interface files to access namespace and profile information. The interface files are created when a profile is loaded and removed when the profile or namespace is removed. Signed-off-by: John Johansen <john.johansen@canonical.com>
2013-07-10 21:13:43 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: refactor profile mode macros Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Steve Beattie <sbeattie@ubuntu.com>
2013-02-18 16:01:34 -08:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: refactor profile mode macros Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Steve Beattie <sbeattie@ubuntu.com>
2013-02-18 16:01:34 -08:00
apparmor: add user mode flag Allow the profile to contain a user mode prompt flag. This works similar to complain mode but will try to send messages to a userspace daemon. If the daemon is not present or timesout regular informent will occur. Signed-off-by: John Johansen <john.johansen@canonical.com>
2019-12-17 15:40:41 -08:00
apparmor: refactor profile mode macros Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Steve Beattie <sbeattie@ubuntu.com>
2013-02-18 16:01:34 -08:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: switch from profiles to using labels on contexts Begin the actual switch to using domain labels by storing them on the context and converting the label to a singular profile where possible. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-06-09 08:14:28 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: allow label to carry debug flags Allow labels to have debug flags that can be used to trigger debug output only from profiles/labels that are marked. This can help reduce debug output by allowing debug to be target to a specific confinement condition. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-03-26 01:46:18 -07:00
apparmor: switch from profiles to using labels on contexts Begin the actual switch to using domain labels by storing them on the context and converting the label to a singular profile where possible. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-06-09 08:14:28 -07:00
apparmor: change how profile replacement update is done remove the use of replaced by chaining and move to profile invalidation and lookup to handle task replacement. Replacement chaining can result in large chains of profiles being pinned in memory when one profile in the chain is use. With implicit labeling this will be even more of a problem, so move to a direct lookup method. Signed-off-by: John Johansen <john.johansen@canonical.com>
2013-07-10 21:07:43 -07:00
apparmor: convert profile lists to RCU based locking Signed-off-by: John Johansen <john.johansen@canonical.com>
2013-07-10 21:06:43 -07:00
apparmor: add additional flags to extended permission. This is a step towards merging the file and policy state machines. With the switch to extended permissions the state machine's ACCEPT2 table became unused freeing it up to store state specific flags. The first flags to be stored are FLAG_OWNER and FLAG other which paves the way towards merging the file and policydb perms into a single permission table. Currently Lookups based on the objects ownership conditional will still need separate fns, this will be address in a following patch. Signed-off-by: John Johansen <john.johansen@canonical.com>
2023-07-23 02:30:33 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: allow setting any profile into the unconfined state Allow emulating the default profile behavior from boot, by allowing loading of a profile in the unconfined state into a new NS. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2013-07-10 21:12:43 -07:00
apparmor: add user mode flag Allow the profile to contain a user mode prompt flag. This works similar to complain mode but will try to send messages to a userspace daemon. If the daemon is not present or timesout regular informent will occur. Signed-off-by: John Johansen <john.johansen@canonical.com>
2019-12-17 15:40:41 -08:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: add support loading per permission tagging Add support for the per permission tag index for a given permission set. This will be used by both meta-data tagging, to allow annotating accept states with context and debug information. As well as by rule tainting and triggers to specify the taint or trigger to be applied. Since these are low frequency ancillary data items they are stored in a tighter packed format to that allows for sharing and reuse of the strings between permissions and accept states. Reducing the amount of kernel memory use at the cost of having to go through a couple if index based indirections. The tags are just strings that has no meaning with out context. When used as meta-data for auditing and debugging its entirely information for userspace, but triggers, and tainting can be used to affect the domain. However they all exist in the same packed data set and can be shared between different uses. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-04-01 15:51:41 -07:00
AppArmor: Add ability to load extended policy Add the base support for the new policy extensions. This does not bring any additional functionality, or change current semantics. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 07:07:53 -08:00
apparmor: add support loading per permission tagging Add support for the per permission tag index for a given permission set. This will be used by both meta-data tagging, to allow annotating accept states with context and debug information. As well as by rule tainting and triggers to specify the taint or trigger to be applied. Since these are low frequency ancillary data items they are stored in a tighter packed format to that allows for sharing and reuse of the strings between permissions and accept states. Reducing the amount of kernel memory use at the cost of having to go through a couple if index based indirections. The tags are just strings that has no meaning with out context. When used as meta-data for auditing and debugging its entirely information for userspace, but triggers, and tainting can be used to affect the domain. However they all exist in the same packed data set and can be shared between different uses. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-04-01 15:51:41 -07:00
AppArmor: Add ability to load extended policy Add the base support for the new policy extensions. This does not bring any additional functionality, or change current semantics. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 07:07:53 -08:00
apparmor: refcount the pdb With the move to permission tables the dfa is no longer a stand alone entity when used, needing a minimum of a permission table. However it still could be shared among different pdbs each using a different permission table. Instead of duping the permission table when sharing a pdb, add a refcount to the pdb so it can be easily shared. Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2023-04-28 05:32:52 -07:00
AppArmor: Add ability to load extended policy Add the base support for the new policy extensions. This does not bring any additional functionality, or change current semantics. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 07:07:53 -08:00
apparmor: add the ability for policy to specify a permission table Currently permissions are encoded in the dfa accept entries that are then mapped to an internal permission structure. This limits the permissions that userspace can specify, so allow userspace to directly specify the permission table. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-08-26 08:53:42 -07:00
apparmor: extend permissions to support a label and tag string add indexes for label and tag entries. Rename the domain table to the str_table as its a shared string table with label and tags. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-07-16 03:33:43 -07:00
apparmor: add support loading per permission tagging Add support for the per permission tag index for a given permission set. This will be used by both meta-data tagging, to allow annotating accept states with context and debug information. As well as by rule tainting and triggers to specify the taint or trigger to be applied. Since these are low frequency ancillary data items they are stored in a tighter packed format to that allows for sharing and reuse of the strings between permissions and accept states. Reducing the amount of kernel memory use at the cost of having to go through a couple if index based indirections. The tags are just strings that has no meaning with out context. When used as meta-data for auditing and debugging its entirely information for userspace, but triggers, and tainting can be used to affect the domain. However they all exist in the same packed data set and can be shared between different uses. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-04-01 15:51:41 -07:00
apparmor: preparse for state being more than just an integer Convert from an unsigned int to a state_t for state position. This is a step in prepping for the state position carrying some additional flags, and a limited form of backtracking to support variables. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-01-17 13:43:49 -08:00
AppArmor: Add ability to load extended policy Add the base support for the new policy extensions. This does not bring any additional functionality, or change current semantics. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 07:07:53 -08:00
apparmor: refcount the pdb With the move to permission tables the dfa is no longer a stand alone entity when used, needing a minimum of a permission table. However it still could be shared among different pdbs each using a different permission table. Instead of duping the permission table when sharing a pdb, add a refcount to the pdb so it can be easily shared. Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2023-04-28 05:32:52 -07:00
apparmor: combine file_rules and aa_policydb into a single shared struct file_rules and policydb are almost the same and will need the same features in the future so combine them. Signed-off-by: John Johansen <john.johansen@canonical.com>
2020-11-19 10:37:48 -08:00
apparmor: add support loading per permission tagging Add support for the per permission tag index for a given permission set. This will be used by both meta-data tagging, to allow annotating accept states with context and debug information. As well as by rule tainting and triggers to specify the taint or trigger to be applied. Since these are low frequency ancillary data items they are stored in a tighter packed format to that allows for sharing and reuse of the strings between permissions and accept states. Reducing the amount of kernel memory use at the cost of having to go through a couple if index based indirections. The tags are just strings that has no meaning with out context. When used as meta-data for auditing and debugging its entirely information for userspace, but triggers, and tainting can be used to affect the domain. However they all exist in the same packed data set and can be shared between different uses. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-04-01 15:51:41 -07:00
apparmor: refcount the pdb With the move to permission tables the dfa is no longer a stand alone entity when used, needing a minimum of a permission table. However it still could be shared among different pdbs each using a different permission table. Instead of duping the permission table when sharing a pdb, add a refcount to the pdb so it can be easily shared. Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2023-04-28 05:32:52 -07:00
apparmor: combine file_rules and aa_policydb into a single shared struct file_rules and policydb are almost the same and will need the same features in the future so combine them. Signed-off-by: John Johansen <john.johansen@canonical.com>
2020-11-19 10:37:48 -08:00
apparmor: add additional flags to extended permission. This is a step towards merging the file and policy state machines. With the switch to extended permissions the state machine's ACCEPT2 table became unused freeing it up to store state specific flags. The first flags to be stored are FLAG_OWNER and FLAG other which paves the way towards merging the file and policydb perms into a single permission table. Currently Lookups based on the objects ownership conditional will still need separate fns, this will be address in a following patch. Signed-off-by: John Johansen <john.johansen@canonical.com>
2023-07-23 02:30:33 -07:00
apparmor: convert policy lookup to use accept as an index Remap polidydb dfa accept table from embedded perms to an index, and then move the perm lookup to use the accept entry as an index into the perm table. This is done so that the perm table can be separated from the dfa, allowing dfa accept to index to share expanded permission sets. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-07-16 01:53:46 -07:00
apparmor: preparse for state being more than just an integer Convert from an unsigned int to a state_t for state position. This is a step in prepping for the state position carrying some additional flags, and a limited form of backtracking to support variables. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-01-17 13:43:49 -08:00
apparmor: convert policy lookup to use accept as an index Remap polidydb dfa accept table from embedded perms to an index, and then move the perm lookup to use the accept entry as an index into the perm table. This is done so that the perm table can be separated from the dfa, allowing dfa accept to index to share expanded permission sets. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-07-16 01:53:46 -07:00
apparmor: support querying extended trusted helper extra data Allow a profile to carry extra data that can be queried via userspace. This provides a means to store extra data in a profile that a trusted helper can extract and use from live policy. Signed-off-by: William Hua <william.hua@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-15 16:49:28 -08:00
apparmor: refactor profile rules and attachments In preparation for moving from a single set of rules and a single attachment to multiple rulesets and attachments separate from the profile refactor attachment information and ruleset info into their own structures. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-07-29 17:17:31 -07:00
apparmor: rework profile->rules to be a list Convert profile->rules to a list as the next step towards supporting multiple rulesets in a profile. For this step only support a single list entry item. The logic for iterating the list will come as a separate step. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-09-05 20:47:36 -07:00
apparmor: refactor profile rules and attachments In preparation for moving from a single set of rules and a single attachment to multiple rulesets and attachments separate from the profile refactor attachment information and ruleset info into their own structures. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-07-29 17:17:31 -07:00
apparmor: refcount the pdb With the move to permission tables the dfa is no longer a stand alone entity when used, needing a minimum of a permission table. However it still could be shared among different pdbs each using a different permission table. Instead of duping the permission table when sharing a pdb, add a refcount to the pdb so it can be easily shared. Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2023-04-28 05:32:52 -07:00
apparmor: refactor profile rules and attachments In preparation for moving from a single set of rules and a single attachment to multiple rulesets and attachments separate from the profile refactor attachment information and ruleset info into their own structures. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-07-29 17:17:31 -07:00
apparmor: transition from a list of rules to a vector of rules The set of rules on a profile is not dynamically extended, instead if a new ruleset is needed a new version of the profile is created. This allows us to use a vector of rules instead of a list, slightly reducing memory usage and simplifying the code. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-02-17 01:46:37 -08:00
apparmor: refactor profile rules and attachments In preparation for moving from a single set of rules and a single attachment to multiple rulesets and attachments separate from the profile refactor attachment information and ruleset info into their own structures. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-07-29 17:17:31 -07:00
apparmor: rework profile->rules to be a list Convert profile->rules to a list as the next step towards supporting multiple rulesets in a profile. For this step only support a single list entry item. The logic for iterating the list will come as a separate step. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-09-05 20:47:36 -07:00
apparmor: refactor profile rules and attachments In preparation for moving from a single set of rules and a single attachment to multiple rulesets and attachments separate from the profile refactor attachment information and ruleset info into their own structures. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-07-29 17:17:31 -07:00
apparmor: refcount the pdb With the move to permission tables the dfa is no longer a stand alone entity when used, needing a minimum of a permission table. However it still could be shared among different pdbs each using a different permission table. Instead of duping the permission table when sharing a pdb, add a refcount to the pdb so it can be easily shared. Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2023-04-28 05:32:52 -07:00
apparmor: refactor profile rules and attachments In preparation for moving from a single set of rules and a single attachment to multiple rulesets and attachments separate from the profile refactor attachment information and ruleset info into their own structures. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-07-29 17:17:31 -07:00
apparmor: change how profile replacement update is done remove the use of replaced by chaining and move to profile invalidation and lookup to handle task replacement. Replacement chaining can result in large chains of profiles being pinned in memory when one profile in the chain is use. With implicit labeling this will be even more of a problem, so move to a direct lookup method. Signed-off-by: John Johansen <john.johansen@canonical.com>
2013-07-10 21:07:43 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: refactor profile rules and attachments In preparation for moving from a single set of rules and a single attachment to multiple rulesets and attachments separate from the profile refactor attachment information and ruleset info into their own structures. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-07-29 17:17:31 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: Document that label must be last member in struct aa_profile The label struct is variable length. While its use in struct aa_profile is fixed length at 2 entries the variable length member needs to be the last member in the structure. The code already does this but the comment has it in the wrong location. Also add a comment to ensure it stays at the end of the structure. While we are at it, update the documentation for other profile members as well. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-02-16 03:40:52 -08:00
apparmor: allow profiles to provide info to disconnected paths Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-05-22 03:06:52 -07:00
apparmor: refactor profile rules and attachments In preparation for moving from a single set of rules and a single attachment to multiple rulesets and attachments separate from the profile refactor attachment information and ruleset info into their own structures. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-07-29 17:17:31 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: Document that label must be last member in struct aa_profile The label struct is variable length. While its use in struct aa_profile is fixed length at 2 entries the variable length member needs to be the last member in the structure. The code already does this but the comment has it in the wrong location. Also add a comment to ensure it stays at the end of the structure. While we are at it, update the documentation for other profile members as well. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-02-16 03:40:52 -08:00
apparmor: add interface files for profiles and namespaces Add basic interface files to access namespace and profile information. The interface files are created when a profile is loaded and removed when the profile or namespace is removed. Signed-off-by: John Johansen <john.johansen@canonical.com>
2013-07-10 21:13:43 -07:00
apparmor: Document that label must be last member in struct aa_profile The label struct is variable length. While its use in struct aa_profile is fixed length at 2 entries the variable length member needs to be the last member in the structure. The code already does this but the comment has it in the wrong location. Also add a comment to ensure it stays at the end of the structure. While we are at it, update the documentation for other profile members as well. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-02-16 03:40:52 -08:00
apparmor: support querying extended trusted helper extra data Allow a profile to carry extra data that can be queried via userspace. This provides a means to store extra data in a profile that a trusted helper can extract and use from live policy. Signed-off-by: William Hua <william.hua@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-15 16:49:28 -08:00
apparmor: Document that label must be last member in struct aa_profile The label struct is variable length. While its use in struct aa_profile is fixed length at 2 entries the variable length member needs to be the last member in the structure. The code already does this but the comment has it in the wrong location. Also add a comment to ensure it stays at the end of the structure. While we are at it, update the documentation for other profile members as well. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-02-16 03:40:52 -08:00
apparmor: transition from a list of rules to a vector of rules The set of rules on a profile is not dynamically extended, instead if a new ruleset is needed a new version of the profile is created. This allows us to use a vector of rules instead of a list, slightly reducing memory usage and simplifying the code. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-02-17 01:46:37 -08:00
apparmor: add interface files for profiles and namespaces Add basic interface files to access namespace and profile information. The interface files are created when a profile is loaded and removed when the profile or namespace is removed. Signed-off-by: John Johansen <john.johansen@canonical.com>
2013-07-10 21:13:43 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: convert profile lists to RCU based locking Signed-off-by: John Johansen <john.johansen@canonical.com>
2013-07-10 21:06:43 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: rename namespace to ns to improve code line lengths Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-16 00:42:16 -08:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: allow setting any profile into the unconfined state Allow emulating the default profile behavior from boot, by allowing loading of a profile in the unconfined state into a new NS. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2013-07-10 21:12:43 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: add support for profiles to define the kill signal Previously apparmor has only sent SIGKILL but there are cases where it can be useful to send a different signal. Allow the profile to optionally specify a different value. Signed-off-by: John Johansen <john.johansen@canonical.com>
2023-08-21 16:54:58 -07:00
apparmor: allow profiles to provide info to disconnected paths Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-05-22 03:06:52 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: refactor profile rules and attachments In preparation for moving from a single set of rules and a single attachment to multiple rulesets and attachments separate from the profile refactor attachment information and ruleset info into their own structures. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-07-29 17:17:31 -07:00
apparmor: Parse secmark policy Add support for parsing secmark policy provided by userspace, and store that in the overall policy. Signed-off-by: Matthew Garrett <mjg59@google.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2018-05-24 13:27:46 -07:00
apparmor: allow introspecting the loaded policy pre internal transform Store loaded policy and allow introspecting it through apparmorfs. This has several uses from debugging, policy validation, and policy checkpoint and restore for containers. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-16 00:42:55 -08:00
apparmor: add the ability to report a sha1 hash of loaded policy Provide userspace the ability to introspect a sha1 hash value for each profile currently loaded. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2013-08-14 11:27:36 -07:00
apparmor: add interface files for profiles and namespaces Add basic interface files to access namespace and profile information. The interface files are created when a profile is loaded and removed when the profile or namespace is removed. Signed-off-by: John Johansen <john.johansen@canonical.com>
2013-07-10 21:13:43 -07:00
apparmor: support querying extended trusted helper extra data Allow a profile to carry extra data that can be queried via userspace. This provides a means to store extra data in a profile that a trusted helper can extract and use from live policy. Signed-off-by: William Hua <william.hua@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-15 16:49:28 -08:00
apparmor: Document that label must be last member in struct aa_profile The label struct is variable length. While its use in struct aa_profile is fixed length at 2 entries the variable length member needs to be the last member in the structure. The code already does this but the comment has it in the wrong location. Also add a comment to ensure it stays at the end of the structure. While we are at it, update the documentation for other profile members as well. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-02-16 03:40:52 -08:00
apparmor: transition from a list of rules to a vector of rules The set of rules on a profile is not dynamically extended, instead if a new ruleset is needed a new version of the profile is created. This allows us to use a vector of rules instead of a list, slightly reducing memory usage and simplifying the code. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-02-17 01:46:37 -08:00
apparmor: Document that label must be last member in struct aa_profile The label struct is variable length. While its use in struct aa_profile is fixed length at 2 entries the variable length member needs to be the last member in the structure. The code already does this but the comment has it in the wrong location. Also add a comment to ensure it stays at the end of the structure. While we are at it, update the documentation for other profile members as well. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-02-16 03:40:52 -08:00
apparmor: switch from profiles to using labels on contexts Begin the actual switch to using domain labels by storing them on the context and converting the label to a singular profile where possible. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-06-09 08:14:28 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: provide finer control over policy management Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-05-26 01:45:08 -07:00
apparmor: switch from profiles to using labels on contexts Begin the actual switch to using domain labels by storing them on the context and converting the label to a singular profile where possible. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-06-09 08:14:28 -07:00
apparmor: split apparmor policy namespaces code into its own file Policy namespaces will be diverging from profile management and expanding so put it in its own file. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-16 00:42:15 -08:00
apparmor: rework profile->rules to be a list Convert profile->rules to a list as the next step towards supporting multiple rulesets in a profile. For this step only support a single list entry item. The logic for iterating the list will come as a separate step. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-09-05 20:47:36 -07:00
apparmor: switch from profiles to using labels on contexts Begin the actual switch to using domain labels by storing them on the context and converting the label to a singular profile where possible. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-06-09 08:14:28 -07:00
apparmor: refactor code that alloc null profiles Bother unconfined and learning profiles use the null profile as their base. Refactor so they are share a common base routine. This doesn't save much atm but will be important when the feature set of the parent is inherited. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-10-03 02:48:24 -07:00
apparmor: make free_profile available outside of policy.c Signed-off-by: John Johansen <john.johansen@canonical.com>
2013-07-10 21:11:43 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: add strn version of lookup_profile fn Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-16 00:42:21 -08:00
apparmor: switch from profiles to using labels on contexts Begin the actual switch to using domain labels by storing them on the context and converting the label to a singular profile where possible. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-06-09 08:14:28 -07:00
apparmor: add fn to lookup profiles by fqname Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-16 00:42:24 -08:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: switch from profiles to using labels on contexts Begin the actual switch to using domain labels by storing them on the context and converting the label to a singular profile where possible. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-06-09 08:14:28 -07:00
apparmor: provide finer control over policy management Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-05-26 01:45:08 -07:00
apparmor: switch from profiles to using labels on contexts Begin the actual switch to using domain labels by storing them on the context and converting the label to a singular profile where possible. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-06-09 08:14:28 -07:00
apparmor: split apparmor policy namespaces code into its own file Policy namespaces will be diverging from profile management and expanding so put it in its own file. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-01-16 00:42:15 -08:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: switch from profiles to using labels on contexts Begin the actual switch to using domain labels by storing them on the context and converting the label to a singular profile where possible. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-06-09 08:14:28 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: refactor profile rules and attachments In preparation for moving from a single set of rules and a single attachment to multiple rulesets and attachments separate from the profile refactor attachment information and ruleset info into their own structures. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-07-29 17:17:31 -07:00
apparmor: fix PROFILE_MEDIATES for untrusted input 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 <john.johansen@canonical.com>
2019-05-26 06:42:23 -07:00
apparmor: refcount the pdb With the move to permission tables the dfa is no longer a stand alone entity when used, needing a minimum of a permission table. However it still could be shared among different pdbs each using a different permission table. Instead of duping the permission table when sharing a pdb, add a refcount to the pdb so it can be easily shared. Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2023-04-28 05:32:52 -07:00
apparmor: fix PROFILE_MEDIATES for untrusted input 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 <john.johansen@canonical.com>
2019-05-26 06:42:23 -07:00
apparmor: refcount the pdb With the move to permission tables the dfa is no longer a stand alone entity when used, needing a minimum of a permission table. However it still could be shared among different pdbs each using a different permission table. Instead of duping the permission table when sharing a pdb, add a refcount to the pdb so it can be easily shared. Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2023-04-28 05:32:52 -07:00
apparmor: fix PROFILE_MEDIATES for untrusted input 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 <john.johansen@canonical.com>
2019-05-26 06:42:23 -07:00
apparmor: gate make fine grained unix mediation behind v9 abi Fine grained unix mediation in Ubuntu used ABI v7, and policy using this has propogated onto systems where fine grained unix mediation was not supported. The userspace policy compiler supports downgrading policy so the policy could be shared without changes. Unfortunately this had the side effect that policy was not updated for the none Ubuntu systems and enabling fine grained unix mediation on those systems means that a new kernel can break a system with existing policy that worked with the previous kernel. With fine grained af_unix mediation this regression can easily break the system causing boot to fail, as it affect unix socket files, non-file based unix sockets, and dbus communication. To aoid this regression move fine grained af_unix mediation behind a new abi. This means that the system's userspace and policy must be updated to support the new policy before it takes affect and dropping a new kernel on existing system will not result in a regression. The abi bump is done in such a way as existing policy can be activated on the system by changing the policy abi declaration and existing unix policy rules will apply. Policy then only needs to be incrementally updated, can even be backported to existing Ubuntu policy. Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-10-12 04:43:34 -07:00
apparmor: add fine grained af_unix mediation Extend af_unix mediation to support fine grained controls based on the type (abstract, anonymous, fs), the address, and the labeling on the socket. This allows for using socket addresses to label and the socket and control which subjects can communicate. The unix rule format follows standard apparmor rules except that fs based unix sockets can be mediated by existing file rules. None fs unix sockets can be mediated by a unix socket rule. Where The address of an abstract unix domain socket begins with the @ character, similar to how they are reported (as paths) by netstat -x. The address then follows and may contain pattern matching and any characters including the null character. In apparmor null characters must be specified by using an escape sequence \000 or \x00. The pattern matching is the same as is used by file path matching so * will not match / even though it has no special meaning with in an abstract socket name. Eg. allow unix addr=@*, Autobound unix domain sockets have a unix sun_path assigned to them by the kernel, as such specifying a policy based address is not possible. The autobinding of sockets can be controlled by specifying the special auto keyword. Eg. allow unix addr=auto, To indicate that the rule only applies to auto binding of unix domain sockets. It is important to note this only applies to the bind permission as once the socket is bound to an address it is indistinguishable from a socket that have an addr bound with a specified name. When the auto keyword is used with other permissions or as part of a peer addr it will be replaced with a pattern that can match an autobound socket. Eg. For some kernels allow unix rw addr=auto, It is important to note, this pattern may match abstract sockets that were not autobound but have an addr that fits what is generated by the kernel when autobinding a socket. Anonymous unix domain sockets have no sun_path associated with the socket address, however it can be specified with the special none keyword to indicate the rule only applies to anonymous unix domain sockets. Eg. allow unix addr=none, If the address component of a rule is not specified then the rule applies to autobind, abstract and anonymous sockets. The label on the socket can be compared using the standard label= rule conditional. Eg. allow unix addr=@foo peer=(label=bar), see man apparmor.d for full syntax description. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-09-07 12:46:30 -07:00
apparmor: refactor profile rules and attachments In preparation for moving from a single set of rules and a single attachment to multiple rulesets and attachments separate from the profile refactor attachment information and ruleset info into their own structures. Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-07-29 17:17:31 -07:00
apparmor: gate make fine grained unix mediation behind v9 abi Fine grained unix mediation in Ubuntu used ABI v7, and policy using this has propogated onto systems where fine grained unix mediation was not supported. The userspace policy compiler supports downgrading policy so the policy could be shared without changes. Unfortunately this had the side effect that policy was not updated for the none Ubuntu systems and enabling fine grained unix mediation on those systems means that a new kernel can break a system with existing policy that worked with the previous kernel. With fine grained af_unix mediation this regression can easily break the system causing boot to fail, as it affect unix socket files, non-file based unix sockets, and dbus communication. To aoid this regression move fine grained af_unix mediation behind a new abi. This means that the system's userspace and policy must be updated to support the new policy before it takes affect and dropping a new kernel on existing system will not result in a regression. The abi bump is done in such a way as existing policy can be activated on the system by changing the policy abi declaration and existing unix policy rules will apply. Policy then only needs to be incrementally updated, can even be backported to existing Ubuntu policy. Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-10-12 04:43:34 -07:00
apparmor: add base infastructure for socket mediation version 2 - Force an abi break. Network mediation will only be available in v8 abi complaint policy. Provide a basic mediation of sockets. This is not a full net mediation but just whether a spcific family of socket can be used by an application, along with setting up some basic infrastructure for network mediation to follow. the user space rule hav the basic form of NETWORK RULE = [ QUALIFIERS ] 'network' [ DOMAIN ] [ TYPE | PROTOCOL ] DOMAIN = ( 'inet' | 'ax25' | 'ipx' | 'appletalk' | 'netrom' | 'bridge' | 'atmpvc' | 'x25' | 'inet6' | 'rose' | 'netbeui' | 'security' | 'key' | 'packet' | 'ash' | 'econet' | 'atmsvc' | 'sna' | 'irda' | 'pppox' | 'wanpipe' | 'bluetooth' | 'netlink' | 'unix' | 'rds' | 'llc' | 'can' | 'tipc' | 'iucv' | 'rxrpc' | 'isdn' | 'phonet' | 'ieee802154' | 'caif' | 'alg' | 'nfc' | 'vsock' | 'mpls' | 'ib' | 'kcm' ) ',' TYPE = ( 'stream' | 'dgram' | 'seqpacket' | 'rdm' | 'raw' | 'packet' ) PROTOCOL = ( 'tcp' | 'udp' | 'icmp' ) eg. network, network inet, Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2017-07-18 23:18:33 -07:00
apparmor: gate make fine grained unix mediation behind v9 abi Fine grained unix mediation in Ubuntu used ABI v7, and policy using this has propogated onto systems where fine grained unix mediation was not supported. The userspace policy compiler supports downgrading policy so the policy could be shared without changes. Unfortunately this had the side effect that policy was not updated for the none Ubuntu systems and enabling fine grained unix mediation on those systems means that a new kernel can break a system with existing policy that worked with the previous kernel. With fine grained af_unix mediation this regression can easily break the system causing boot to fail, as it affect unix socket files, non-file based unix sockets, and dbus communication. To aoid this regression move fine grained af_unix mediation behind a new abi. This means that the system's userspace and policy must be updated to support the new policy before it takes affect and dropping a new kernel on existing system will not result in a regression. The abi bump is done in such a way as existing policy can be activated on the system by changing the policy abi declaration and existing unix policy rules will apply. Policy then only needs to be incrementally updated, can even be backported to existing Ubuntu policy. Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-10-12 04:43:34 -07:00
apparmor: carry mediation check on label In order to speed up the mediated check, precompute and store the result as a bit per class type. This will not only allow us to speed up the mediation check but is also a step to removing the unconfined special cases as the unconfined check can be replaced with the generic label_mediates() check. Note: label check does not currently work for capabilities and resources which need to have their mediation updated first. Signed-off-by: John Johansen <john.johansen@canonical.com>
2023-10-27 10:31:06 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: fix race between freeing data and fs accessing it 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 aand 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 <qsa@qualys.com> Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Reviewed-by: Maxime Bélair <maxime.belair@canonical.com> Reviewed-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-03-01 16:10:51 -08:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: convert profile lists to RCU based locking Signed-off-by: John Johansen <john.johansen@canonical.com>
2013-07-10 21:06:43 -07:00
apparmor: fix race between freeing data and fs accessing it 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 aand 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 <qsa@qualys.com> Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Reviewed-by: Maxime Bélair <maxime.belair@canonical.com> Reviewed-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-03-01 16:10:51 -08:00
apparmor: convert profile lists to RCU based locking Signed-off-by: John Johansen <john.johansen@canonical.com>
2013-07-10 21:06:43 -07:00
apparmor: fix race between freeing data and fs accessing it 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 aand 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 <qsa@qualys.com> Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Reviewed-by: Maxime Bélair <maxime.belair@canonical.com> Reviewed-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-03-01 16:10:51 -08:00
apparmor: convert profile lists to RCU based locking Signed-off-by: John Johansen <john.johansen@canonical.com>
2013-07-10 21:06:43 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: rework namespace free path namespaces now completely use the unconfined profile to track the refcount and rcu freeing cycle. So rework the code to simplify (track everything through the profile path right up to the end), and move the rcu_head from policy base to profile as the namespace no longer needs it. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2013-07-10 21:10:43 -07:00
apparmor: fix race between freeing data and fs accessing it 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 aand 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 <qsa@qualys.com> Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Reviewed-by: Maxime Bélair <maxime.belair@canonical.com> Reviewed-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-03-01 16:10:51 -08:00
apparmor: update how unconfined is handled ns->unconfined is being used read side without locking, nor rcu but is being updated when a namespace is removed. This works for the root ns which is never removed but has a race window and can cause failures when children namespaces are removed. Also ns and ns->unconfined have a circular refcounting dependency that is problematic and must be broken. Currently this is done incorrectly when the namespace is destroyed. Fix this by forward referencing unconfined via the replacedby infrastructure instead of directly updating the ns->unconfined pointer. Remove the circular refcount dependency by making the ns and its unconfined profile share the same refcount. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2013-07-10 21:08:43 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00
apparmor: pass cred through to audit info. The cred is needed to properly audit some messages, and will be needed in the future for uid conditional mediation. So pass it through to where the apparmor_audit_data struct gets defined. Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2022-09-19 20:48:48 -07:00
apparmor: fix unprivileged local user can do privileged policy management 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 <qsa@qualys.com> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Reviewed-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-11-07 08:36:04 -08:00
apparmor: update policy capable checks to use a label Previously the policy capable checks assumed they were using the current task. Make them take the task label so the query can be made against an arbitrary task. Signed-off-by: John Johansen <john.johansen@canonical.com>
2020-06-30 17:00:11 -07:00
AppArmor: core policy routines The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task Profiles tend to be named after an executable that they will attach to but this is not required. namespaces - a container for a set of profiles that will be used during attachment and transitions between profiles. sids - which provide a unique id for each profile Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:00 -07:00