kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
linux/security/apparmor/match.c

832 lines
21 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: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: misc cleanup of match tidying up comments, includes and defines Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2013-02-18 16:08:34 -08:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
AppArmor: Allow apparmor to handle unaligned dfa tables The dfa tables can originate from kernel or userspace and 8-byte alignment isn't always guaranteed and as such may trigger unaligned memory accesses on various architectures. Resulting in the following [   73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720 [   74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common [   74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE [   74.536543] Call Trace: [   74.568561] [<0000000000434c24>] dump_stack+0x8/0x18 [   74.633757] [<0000000000476438>] __warn+0xd8/0x100 [   74.696664] [<00000000004296d4>] warn_slowpath_fmt+0x34/0x74 [   74.771006] [<00000000008db28c>] aa_dfa_unpack+0x6cc/0x720 [   74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0 [   74.910545] [<00000000008e7740>] unpack_profile+0xbe0/0x1300 [   74.984888] [<00000000008e82e0>] aa_unpack+0xe0/0x6a0 [   75.051226] [<00000000008e3ec4>] aa_replace_profiles+0x64/0x1160 [   75.130144] [<00000000008d4d90>] policy_update+0xf0/0x280 [   75.201057] [<00000000008d4fc8>] profile_replace+0xa8/0x100 [   75.274258] [<0000000000766bd0>] vfs_write+0x90/0x420 [   75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0 [   75.406932] [<0000000000767174>] sys_write+0x14/0x40 [   75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [   75.548802] ---[ end trace 0000000000000000 ]--- [   75.609503] dfa blob stream 0xfff0000008926b96 not aligned. [   75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720 Work around it by using the get_unaligned_xx() helpers. Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Closes: https://github.com/sparclinux/issues/issues/30 Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-11-25 16:11:07 +01:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -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: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: reserve and mask off the top 8 bits of the base field The top 8 bits of the base field have never been used, in fact can't be used, by the current 'dfa16' format. However they will be used in the future as flags, so mask them off when using base as an index value. Note: the use of the top 8 bits, without masking is trapped by the verify checks that base entries are within the size bounds. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2013-02-18 16:12:34 -08:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: propagate -ENOMEM correctly in unpack_table Currently, if the `kvzalloc` in `unpack_table` fails, it returns NULL. This is masked by `aa_dfa_unpack` which interprets NULL as a -EPROTO, leading to confusing error messages in `apparmor_parser` [1]. The fixed behavior correctly propagates -ENOMEM on allocation failure. Link: https://gitlab.com/apparmor/apparmor/-/issues/592 Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Maxime Bélair <maxime.belair@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-02-11 14:19:32 +01:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: add kvzalloc to handle zeroing for kvmalloc Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Steve Beattie <sbeattie@ubuntu.com>
2013-02-18 16:04:34 -08:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: propagate -ENOMEM correctly in unpack_table Currently, if the `kvzalloc` in `unpack_table` fails, it returns NULL. This is masked by `aa_dfa_unpack` which interprets NULL as a -EPROTO, leading to confusing error messages in `apparmor_parser` [1]. The fixed behavior correctly propagates -ENOMEM on allocation failure. Link: https://gitlab.com/apparmor/apparmor/-/issues/592 Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Maxime Bélair <maxime.belair@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-02-11 14:19:32 +01:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
AppArmor: Allow apparmor to handle unaligned dfa tables The dfa tables can originate from kernel or userspace and 8-byte alignment isn't always guaranteed and as such may trigger unaligned memory accesses on various architectures. Resulting in the following [   73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720 [   74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common [   74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE [   74.536543] Call Trace: [   74.568561] [<0000000000434c24>] dump_stack+0x8/0x18 [   74.633757] [<0000000000476438>] __warn+0xd8/0x100 [   74.696664] [<00000000004296d4>] warn_slowpath_fmt+0x34/0x74 [   74.771006] [<00000000008db28c>] aa_dfa_unpack+0x6cc/0x720 [   74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0 [   74.910545] [<00000000008e7740>] unpack_profile+0xbe0/0x1300 [   74.984888] [<00000000008e82e0>] aa_unpack+0xe0/0x6a0 [   75.051226] [<00000000008e3ec4>] aa_replace_profiles+0x64/0x1160 [   75.130144] [<00000000008d4d90>] policy_update+0xf0/0x280 [   75.201057] [<00000000008d4fc8>] profile_replace+0xa8/0x100 [   75.274258] [<0000000000766bd0>] vfs_write+0x90/0x420 [   75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0 [   75.406932] [<0000000000767174>] sys_write+0x14/0x40 [   75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [   75.548802] ---[ end trace 0000000000000000 ]--- [   75.609503] dfa blob stream 0xfff0000008926b96 not aligned. [   75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720 Work around it by using the get_unaligned_xx() helpers. Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Closes: https://github.com/sparclinux/issues/issues/30 Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-11-25 16:11:07 +01:00
apparmor: add missing id bounds check on dfa verification Signed-off-by: John Johansen <john.johansen@canonical.com>
2016-06-02 02:37:02 -07:00
AppArmor: Allow apparmor to handle unaligned dfa tables The dfa tables can originate from kernel or userspace and 8-byte alignment isn't always guaranteed and as such may trigger unaligned memory accesses on various architectures. Resulting in the following [   73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720 [   74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common [   74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE [   74.536543] Call Trace: [   74.568561] [<0000000000434c24>] dump_stack+0x8/0x18 [   74.633757] [<0000000000476438>] __warn+0xd8/0x100 [   74.696664] [<00000000004296d4>] warn_slowpath_fmt+0x34/0x74 [   74.771006] [<00000000008db28c>] aa_dfa_unpack+0x6cc/0x720 [   74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0 [   74.910545] [<00000000008e7740>] unpack_profile+0xbe0/0x1300 [   74.984888] [<00000000008e82e0>] aa_unpack+0xe0/0x6a0 [   75.051226] [<00000000008e3ec4>] aa_replace_profiles+0x64/0x1160 [   75.130144] [<00000000008d4d90>] policy_update+0xf0/0x280 [   75.201057] [<00000000008d4fc8>] profile_replace+0xa8/0x100 [   75.274258] [<0000000000766bd0>] vfs_write+0x90/0x420 [   75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0 [   75.406932] [<0000000000767174>] sys_write+0x14/0x40 [   75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [   75.548802] ---[ end trace 0000000000000000 ]--- [   75.609503] dfa blob stream 0xfff0000008926b96 not aligned. [   75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720 Work around it by using the get_unaligned_xx() helpers. Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Closes: https://github.com/sparclinux/issues/issues/30 Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-11-25 16:11:07 +01:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: ensure that dfa state tables have entries Currently it is possible to specify a state machine table with 0 length, this is not valid as optional tables are specified by not defining the table as present. Further this allows by-passing the base tables range check against the next/check tables. Fixes: d901d6a298dc ("apparmor: dfa split verification of table headers") Reported-by: Mike Salvatore <mike.salvatore@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2020-03-30 23:37:54 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
mm: introduce kv[mz]alloc helpers Patch series "kvmalloc", v5. There are many open coded kmalloc with vmalloc fallback instances in the tree. Most of them are not careful enough or simply do not care about the underlying semantic of the kmalloc/page allocator which means that a) some vmalloc fallbacks are basically unreachable because the kmalloc part will keep retrying until it succeeds b) the page allocator can invoke a really disruptive steps like the OOM killer to move forward which doesn't sound appropriate when we consider that the vmalloc fallback is available. As it can be seen implementing kvmalloc requires quite an intimate knowledge if the page allocator and the memory reclaim internals which strongly suggests that a helper should be implemented in the memory subsystem proper. Most callers, I could find, have been converted to use the helper instead. This is patch 6. There are some more relying on __GFP_REPEAT in the networking stack which I have converted as well and Eric Dumazet was not opposed [2] to convert them as well. [1] http://lkml.kernel.org/r/20170130094940.13546-1-mhocko@kernel.org [2] http://lkml.kernel.org/r/1485273626.16328.301.camel@edumazet-glaptop3.roam.corp.google.com This patch (of 9): Using kmalloc with the vmalloc fallback for larger allocations is a common pattern in the kernel code. Yet we do not have any common helper for that and so users have invented their own helpers. Some of them are really creative when doing so. Let's just add kv[mz]alloc and make sure it is implemented properly. This implementation makes sure to not make a large memory pressure for > PAGE_SZE requests (__GFP_NORETRY) and also to not warn about allocation failures. This also rules out the OOM killer as the vmalloc is a more approapriate fallback than a disruptive user visible action. This patch also changes some existing users and removes helpers which are specific for them. In some cases this is not possible (e.g. ext4_kvmalloc, libcfs_kvzalloc) because those seems to be broken and require GFP_NO{FS,IO} context which is not vmalloc compatible in general (note that the page table allocation is GFP_KERNEL). Those need to be fixed separately. While we are at it, document that __vmalloc{_node} about unsupported gfp mask because there seems to be a lot of confusion out there. kvmalloc_node will warn about GFP_KERNEL incompatible (which are not superset) flags to catch new abusers. Existing ones would have to die slowly. [sfr@canb.auug.org.au: f2fs fixup] Link: http://lkml.kernel.org/r/20170320163735.332e64b7@canb.auug.org.au Link: http://lkml.kernel.org/r/20170306103032.2540-2-mhocko@kernel.org Signed-off-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Andreas Dilger <adilger@dilger.ca> [ext4 part] Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: John Hubbard <jhubbard@nvidia.com> Cc: David Miller <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-05-08 15:57:09 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: do not expose kernel stack Do not copy uninitalized fields th.td_hilen, th.td_data. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: John Johansen <john.johansen@canonical.com>
2016-06-10 23:34:26 +02:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: Fix & Optimize table creation from possibly unaligned memory Source blob may come from userspace and might be unaligned. Try to optize the copying process by avoiding unaligned memory accesses. - Added Fixes tag - Added "Fix &" to description as this doesn't just optimize but fixes a potential unaligned memory access Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Signed-off-by: Helge Deller <deller@gmx.de> [jj: remove duplicate word "convert" in comment trigger checkpatch warning] Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-11-26 21:15:04 +01:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: Fix & Optimize table creation from possibly unaligned memory Source blob may come from userspace and might be unaligned. Try to optize the copying process by avoiding unaligned memory accesses. - Added Fixes tag - Added "Fix &" to description as this doesn't just optimize but fixes a potential unaligned memory access Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Signed-off-by: Helge Deller <deller@gmx.de> [jj: remove duplicate word "convert" in comment trigger checkpatch warning] Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-11-26 21:15:04 +01:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: Fix & Optimize table creation from possibly unaligned memory Source blob may come from userspace and might be unaligned. Try to optize the copying process by avoiding unaligned memory accesses. - Added Fixes tag - Added "Fix &" to description as this doesn't just optimize but fixes a potential unaligned memory access Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Signed-off-by: Helge Deller <deller@gmx.de> [jj: remove duplicate word "convert" in comment trigger checkpatch warning] Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-11-26 21:15:04 +01:00
apparmor: propagate -ENOMEM correctly in unpack_table Currently, if the `kvzalloc` in `unpack_table` fails, it returns NULL. This is masked by `aa_dfa_unpack` which interprets NULL as a -EPROTO, leading to confusing error messages in `apparmor_parser` [1]. The fixed behavior correctly propagates -ENOMEM on allocation failure. Link: https://gitlab.com/apparmor/apparmor/-/issues/592 Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Maxime Bélair <maxime.belair@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-02-11 14:19:32 +01:00
apparmor: don't check for vmalloc_addr if kvzalloc() failed Signed-off-by: John Johansen <john.johansen@canonical.com>
2016-06-15 09:57:55 +03:00
apparmor: propagate -ENOMEM correctly in unpack_table Currently, if the `kvzalloc` in `unpack_table` fails, it returns NULL. This is masked by `aa_dfa_unpack` which interprets NULL as a -EPROTO, leading to confusing error messages in `apparmor_parser` [1]. The fixed behavior correctly propagates -ENOMEM on allocation failure. Link: https://gitlab.com/apparmor/apparmor/-/issues/592 Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Maxime Bélair <maxime.belair@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-02-11 14:19:32 +01:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
apparmor: Fix kernel-doc warnings in apparmor/match.c Fix kernel-doc warnings: security/apparmor/match.c:148: warning: Function parameter or member 'tables' not described in 'verify_table_headers' security/apparmor/match.c:289: warning: Excess function parameter 'kr' description in 'aa_dfa_free_kref' security/apparmor/match.c:289: warning: Function parameter or member 'kref' not described in 'aa_dfa_free_kref' Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2023-06-25 09:13:45 +08:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
apparmor: Fix an error code in verify_table_headers() We accidentally return a positive EPROTO instead of a negative -EPROTO. Since 71 is not an error pointer, that means it eventually results in an Oops in the caller. Fixes: d901d6a298dc ("apparmor: dfa split verification of table headers") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2018-03-19 12:12:31 +03:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
apparmor: fix dfa size check AppArmor dfas need a minimum of two states to be valid. State 0 is the default trap state, and State 1 the default start state. When verifying the dfa ensure that this is the case. Fixes: c27c6bd2c4d6b ("apparmor: ensure that dfa state tables have entries") Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-03-04 19:24:01 -07:00
apparmor: ensure that dfa state tables have entries Currently it is possible to specify a state machine table with 0 length, this is not valid as optional tables are specified by not defining the table as present. Further this allows by-passing the base tables range check against the next/check tables. Fixes: d901d6a298dc ("apparmor: dfa split verification of table headers") Reported-by: Mike Salvatore <mike.salvatore@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2020-03-30 23:37:54 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
apparmor: fix missing bounds check on DEFAULT table in verify_dfa() The verify_dfa() function only checks DEFAULT_TABLE bounds when the state is not differentially encoded. When the verification loop traverses the differential encoding chain, it reads k = DEFAULT_TABLE[j] and uses k as an array index without validation. A malformed DFA with DEFAULT_TABLE[j] >= state_count, therefore, causes both out-of-bounds reads and writes. [ 57.179855] ================================================================== [ 57.180549] BUG: KASAN: slab-out-of-bounds in verify_dfa+0x59a/0x660 [ 57.180904] Read of size 4 at addr ffff888100eadec4 by task su/993 [ 57.181554] CPU: 1 UID: 0 PID: 993 Comm: su Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 57.181558] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 57.181563] Call Trace: [ 57.181572] <TASK> [ 57.181577] dump_stack_lvl+0x5e/0x80 [ 57.181596] print_report+0xc8/0x270 [ 57.181605] ? verify_dfa+0x59a/0x660 [ 57.181608] kasan_report+0x118/0x150 [ 57.181620] ? verify_dfa+0x59a/0x660 [ 57.181623] verify_dfa+0x59a/0x660 [ 57.181627] aa_dfa_unpack+0x1610/0x1740 [ 57.181629] ? __kmalloc_cache_noprof+0x1d0/0x470 [ 57.181640] unpack_pdb+0x86d/0x46b0 [ 57.181647] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181653] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181656] ? aa_unpack_nameX+0x1a8/0x300 [ 57.181659] aa_unpack+0x20b0/0x4c30 [ 57.181662] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181664] ? stack_depot_save_flags+0x33/0x700 [ 57.181681] ? kasan_save_track+0x4f/0x80 [ 57.181683] ? kasan_save_track+0x3e/0x80 [ 57.181686] ? __kasan_kmalloc+0x93/0xb0 [ 57.181688] ? __kvmalloc_node_noprof+0x44a/0x780 [ 57.181693] ? aa_simple_write_to_buffer+0x54/0x130 [ 57.181697] ? policy_update+0x154/0x330 [ 57.181704] aa_replace_profiles+0x15a/0x1dd0 [ 57.181707] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181710] ? __kvmalloc_node_noprof+0x44a/0x780 [ 57.181712] ? aa_loaddata_alloc+0x77/0x140 [ 57.181715] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181717] ? _copy_from_user+0x2a/0x70 [ 57.181730] policy_update+0x17a/0x330 [ 57.181733] profile_replace+0x153/0x1a0 [ 57.181735] ? rw_verify_area+0x93/0x2d0 [ 57.181740] vfs_write+0x235/0xab0 [ 57.181745] ksys_write+0xb0/0x170 [ 57.181748] do_syscall_64+0x8e/0x660 [ 57.181762] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 57.181765] RIP: 0033:0x7f6192792eb2 Remove the MATCH_FLAG_DIFF_ENCODE condition to validate all DEFAULT_TABLE entries unconditionally. Fixes: 031dcc8f4e84 ("apparmor: dfa add support for state differential encoding") 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: Massimiliano Pellizzer <massimiliano.pellizzer@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-01-29 16:51:11 +01:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
apparmor: fix missing bounds check on DEFAULT table in verify_dfa() The verify_dfa() function only checks DEFAULT_TABLE bounds when the state is not differentially encoded. When the verification loop traverses the differential encoding chain, it reads k = DEFAULT_TABLE[j] and uses k as an array index without validation. A malformed DFA with DEFAULT_TABLE[j] >= state_count, therefore, causes both out-of-bounds reads and writes. [ 57.179855] ================================================================== [ 57.180549] BUG: KASAN: slab-out-of-bounds in verify_dfa+0x59a/0x660 [ 57.180904] Read of size 4 at addr ffff888100eadec4 by task su/993 [ 57.181554] CPU: 1 UID: 0 PID: 993 Comm: su Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 57.181558] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 57.181563] Call Trace: [ 57.181572] <TASK> [ 57.181577] dump_stack_lvl+0x5e/0x80 [ 57.181596] print_report+0xc8/0x270 [ 57.181605] ? verify_dfa+0x59a/0x660 [ 57.181608] kasan_report+0x118/0x150 [ 57.181620] ? verify_dfa+0x59a/0x660 [ 57.181623] verify_dfa+0x59a/0x660 [ 57.181627] aa_dfa_unpack+0x1610/0x1740 [ 57.181629] ? __kmalloc_cache_noprof+0x1d0/0x470 [ 57.181640] unpack_pdb+0x86d/0x46b0 [ 57.181647] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181653] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181656] ? aa_unpack_nameX+0x1a8/0x300 [ 57.181659] aa_unpack+0x20b0/0x4c30 [ 57.181662] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181664] ? stack_depot_save_flags+0x33/0x700 [ 57.181681] ? kasan_save_track+0x4f/0x80 [ 57.181683] ? kasan_save_track+0x3e/0x80 [ 57.181686] ? __kasan_kmalloc+0x93/0xb0 [ 57.181688] ? __kvmalloc_node_noprof+0x44a/0x780 [ 57.181693] ? aa_simple_write_to_buffer+0x54/0x130 [ 57.181697] ? policy_update+0x154/0x330 [ 57.181704] aa_replace_profiles+0x15a/0x1dd0 [ 57.181707] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181710] ? __kvmalloc_node_noprof+0x44a/0x780 [ 57.181712] ? aa_loaddata_alloc+0x77/0x140 [ 57.181715] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181717] ? _copy_from_user+0x2a/0x70 [ 57.181730] policy_update+0x17a/0x330 [ 57.181733] profile_replace+0x153/0x1a0 [ 57.181735] ? rw_verify_area+0x93/0x2d0 [ 57.181740] vfs_write+0x235/0xab0 [ 57.181745] ksys_write+0xb0/0x170 [ 57.181748] do_syscall_64+0x8e/0x660 [ 57.181762] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 57.181765] RIP: 0033:0x7f6192792eb2 Remove the MATCH_FLAG_DIFF_ENCODE condition to validate all DEFAULT_TABLE entries unconditionally. Fixes: 031dcc8f4e84 ("apparmor: dfa add support for state differential encoding") 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: Massimiliano Pellizzer <massimiliano.pellizzer@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-01-29 16:51:11 +01:00
apparmor: add a valid state flags check Add a check to ensure only known state flags are set on each state in the dfa. Signed-off-by: John Johansen <john.johansen@canonical.com>
2019-08-31 15:55:06 -07:00
apparmor: add consistency check between state and dfa diff encode flags Check that a states diff encode flag is only set if diff encode is enabled in the dfa header. Signed-off-by: John Johansen <john.johansen@canonical.com>
2019-08-31 15:55:45 -07:00
apparmor: add outofband transition and use it in xattr match There are cases where the a special out of band transition that can not be triggered by input is useful in separating match conditions in the dfa encoding. The null_transition is currently used as an out of band transition for match conditions that can not contain a \0 in their input but apparmor needs an out of band transition for cases where the match condition is allowed to contain any input character. Achieve this by allowing for an explicit transition out of input range that can only be triggered by code. Signed-off-by: John Johansen <john.johansen@canonical.com>
2019-07-30 02:42:13 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
apparmor: dfa add support for state differential encoding State differential encoding can provide better compression for apparmor policy, without having significant impact on match time. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 12:10:50 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
apparmor: dfa add support for state differential encoding State differential encoding can provide better compression for apparmor policy, without having significant impact on match time. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 12:10:50 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
apparmor: fix differential encoding verification Differential encoding allows loops to be created if it is abused. To prevent this the unpack should verify that a diff-encode chain terminates. Unfortunately the differential encode verification had two bugs. 1. it conflated states that had gone through check and already been marked, with states that were currently being checked and marked. This means that loops in the current chain being verified are treated as a chain that has already been verified. 2. the order bailout on already checked states compared current chain check iterators j,k instead of using the outer loop iterator i. Meaning a step backwards in states in the current chain verification was being mistaken for moving to an already verified state. Move to a double mark scheme where already verified states get a different mark, than the current chain being kept. This enables us to also drop the backwards verification check that was the cause of the second error as any already verified state is already marked. Fixes: 031dcc8f4e84 ("apparmor: dfa add support for state differential encoding") 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-10-17 01:53:00 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
apparmor: fix differential encoding verification Differential encoding allows loops to be created if it is abused. To prevent this the unpack should verify that a diff-encode chain terminates. Unfortunately the differential encode verification had two bugs. 1. it conflated states that had gone through check and already been marked, with states that were currently being checked and marked. This means that loops in the current chain being verified are treated as a chain that has already been verified. 2. the order bailout on already checked states compared current chain check iterators j,k instead of using the outer loop iterator i. Meaning a step backwards in states in the current chain verification was being mistaken for moving to an already verified state. Move to a double mark scheme where already verified states get a different mark, than the current chain being kept. This enables us to also drop the backwards verification check that was the cause of the second error as any already verified state is already marked. Fixes: 031dcc8f4e84 ("apparmor: dfa add support for state differential encoding") 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-10-17 01:53:00 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
apparmor: fix differential encoding verification Differential encoding allows loops to be created if it is abused. To prevent this the unpack should verify that a diff-encode chain terminates. Unfortunately the differential encode verification had two bugs. 1. it conflated states that had gone through check and already been marked, with states that were currently being checked and marked. This means that loops in the current chain being verified are treated as a chain that has already been verified. 2. the order bailout on already checked states compared current chain check iterators j,k instead of using the outer loop iterator i. Meaning a step backwards in states in the current chain verification was being mistaken for moving to an already verified state. Move to a double mark scheme where already verified states get a different mark, than the current chain being kept. This enables us to also drop the backwards verification check that was the cause of the second error as any already verified state is already marked. Fixes: 031dcc8f4e84 ("apparmor: dfa add support for state differential encoding") 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-10-17 01:53:00 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
apparmor: dfa add support for state differential encoding State differential encoding can provide better compression for apparmor policy, without having significant impact on match time. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 12:10:50 -07:00
apparmor: fix differential encoding verification Differential encoding allows loops to be created if it is abused. To prevent this the unpack should verify that a diff-encode chain terminates. Unfortunately the differential encode verification had two bugs. 1. it conflated states that had gone through check and already been marked, with states that were currently being checked and marked. This means that loops in the current chain being verified are treated as a chain that has already been verified. 2. the order bailout on already checked states compared current chain check iterators j,k instead of using the outer loop iterator i. Meaning a step backwards in states in the current chain verification was being mistaken for moving to an already verified state. Move to a double mark scheme where already verified states get a different mark, than the current chain being kept. This enables us to also drop the backwards verification check that was the cause of the second error as any already verified state is already marked. Fixes: 031dcc8f4e84 ("apparmor: dfa add support for state differential encoding") 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-10-17 01:53:00 -07:00
apparmor: dfa add support for state differential encoding State differential encoding can provide better compression for apparmor policy, without having significant impact on match time. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 12:10:50 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: Fix kernel-doc warnings in apparmor/match.c Fix kernel-doc warnings: security/apparmor/match.c:148: warning: Function parameter or member 'tables' not described in 'verify_table_headers' security/apparmor/match.c:289: warning: Excess function parameter 'kr' description in 'aa_dfa_free_kref' security/apparmor/match.c:289: warning: Function parameter or member 'kref' not described in 'aa_dfa_free_kref' Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2023-06-25 09:13:45 +08:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
doc: ReSTify apparmor.txt Adjusts for ReST markup and moves under LSM admin guide. Acked-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2017-05-13 04:51:45 -07:00
Fix common misspellings Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-30 22:57:33 -03:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
Convert 'alloc_obj' family to use the new default GFP_KERNEL argument This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21 16:37:42 -08:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
AppArmor: Allow apparmor to handle unaligned dfa tables The dfa tables can originate from kernel or userspace and 8-byte alignment isn't always guaranteed and as such may trigger unaligned memory accesses on various architectures. Resulting in the following [   73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720 [   74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common [   74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE [   74.536543] Call Trace: [   74.568561] [<0000000000434c24>] dump_stack+0x8/0x18 [   74.633757] [<0000000000476438>] __warn+0xd8/0x100 [   74.696664] [<00000000004296d4>] warn_slowpath_fmt+0x34/0x74 [   74.771006] [<00000000008db28c>] aa_dfa_unpack+0x6cc/0x720 [   74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0 [   74.910545] [<00000000008e7740>] unpack_profile+0xbe0/0x1300 [   74.984888] [<00000000008e82e0>] aa_unpack+0xe0/0x6a0 [   75.051226] [<00000000008e3ec4>] aa_replace_profiles+0x64/0x1160 [   75.130144] [<00000000008d4d90>] policy_update+0xf0/0x280 [   75.201057] [<00000000008d4fc8>] profile_replace+0xa8/0x100 [   75.274258] [<0000000000766bd0>] vfs_write+0x90/0x420 [   75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0 [   75.406932] [<0000000000767174>] sys_write+0x14/0x40 [   75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [   75.548802] ---[ end trace 0000000000000000 ]--- [   75.609503] dfa blob stream 0xfff0000008926b96 not aligned. [   75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720 Work around it by using the get_unaligned_xx() helpers. Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Closes: https://github.com/sparclinux/issues/issues/30 Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-11-25 16:11:07 +01:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
AppArmor: Allow apparmor to handle unaligned dfa tables The dfa tables can originate from kernel or userspace and 8-byte alignment isn't always guaranteed and as such may trigger unaligned memory accesses on various architectures. Resulting in the following [   73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720 [   74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common [   74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE [   74.536543] Call Trace: [   74.568561] [<0000000000434c24>] dump_stack+0x8/0x18 [   74.633757] [<0000000000476438>] __warn+0xd8/0x100 [   74.696664] [<00000000004296d4>] warn_slowpath_fmt+0x34/0x74 [   74.771006] [<00000000008db28c>] aa_dfa_unpack+0x6cc/0x720 [   74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0 [   74.910545] [<00000000008e7740>] unpack_profile+0xbe0/0x1300 [   74.984888] [<00000000008e82e0>] aa_unpack+0xe0/0x6a0 [   75.051226] [<00000000008e3ec4>] aa_replace_profiles+0x64/0x1160 [   75.130144] [<00000000008d4d90>] policy_update+0xf0/0x280 [   75.201057] [<00000000008d4fc8>] profile_replace+0xa8/0x100 [   75.274258] [<0000000000766bd0>] vfs_write+0x90/0x420 [   75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0 [   75.406932] [<0000000000767174>] sys_write+0x14/0x40 [   75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [   75.548802] ---[ end trace 0000000000000000 ]--- [   75.609503] dfa blob stream 0xfff0000008926b96 not aligned. [   75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720 Work around it by using the get_unaligned_xx() helpers. Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Closes: https://github.com/sparclinux/issues/issues/30 Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-11-25 16:11:07 +01:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
AppArmor: Allow apparmor to handle unaligned dfa tables The dfa tables can originate from kernel or userspace and 8-byte alignment isn't always guaranteed and as such may trigger unaligned memory accesses on various architectures. Resulting in the following [   73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720 [   74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common [   74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE [   74.536543] Call Trace: [   74.568561] [<0000000000434c24>] dump_stack+0x8/0x18 [   74.633757] [<0000000000476438>] __warn+0xd8/0x100 [   74.696664] [<00000000004296d4>] warn_slowpath_fmt+0x34/0x74 [   74.771006] [<00000000008db28c>] aa_dfa_unpack+0x6cc/0x720 [   74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0 [   74.910545] [<00000000008e7740>] unpack_profile+0xbe0/0x1300 [   74.984888] [<00000000008e82e0>] aa_unpack+0xe0/0x6a0 [   75.051226] [<00000000008e3ec4>] aa_replace_profiles+0x64/0x1160 [   75.130144] [<00000000008d4d90>] policy_update+0xf0/0x280 [   75.201057] [<00000000008d4fc8>] profile_replace+0xa8/0x100 [   75.274258] [<0000000000766bd0>] vfs_write+0x90/0x420 [   75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0 [   75.406932] [<0000000000767174>] sys_write+0x14/0x40 [   75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [   75.548802] ---[ end trace 0000000000000000 ]--- [   75.609503] dfa blob stream 0xfff0000008926b96 not aligned. [   75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720 Work around it by using the get_unaligned_xx() helpers. Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Closes: https://github.com/sparclinux/issues/issues/30 Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-11-25 16:11:07 +01:00
apparmor: add outofband transition and use it in xattr match There are cases where the a special out of band transition that can not be triggered by input is useful in separating match conditions in the dfa encoding. The null_transition is currently used as an out of band transition for match conditions that can not contain a \0 in their input but apparmor needs an out of band transition for cases where the match condition is allowed to contain any input character. Achieve this by allowing for an explicit transition out of input range that can only be triggered by code. Signed-off-by: John Johansen <john.johansen@canonical.com>
2019-07-30 02:42:13 -07:00
apparmor: dfa add support for state differential encoding State differential encoding can provide better compression for apparmor policy, without having significant impact on match time. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 12:10:50 -07:00
apparmor: add outofband transition and use it in xattr match There are cases where the a special out of band transition that can not be triggered by input is useful in separating match conditions in the dfa encoding. The null_transition is currently used as an out of band transition for match conditions that can not contain a \0 in their input but apparmor needs an out of band transition for cases where the match condition is allowed to contain any input character. Achieve this by allowing for an explicit transition out of input range that can only be triggered by code. Signed-off-by: John Johansen <john.johansen@canonical.com>
2019-07-30 02:42:13 -07:00
AppArmor: Allow apparmor to handle unaligned dfa tables The dfa tables can originate from kernel or userspace and 8-byte alignment isn't always guaranteed and as such may trigger unaligned memory accesses on various architectures. Resulting in the following [   73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720 [   74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common [   74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE [   74.536543] Call Trace: [   74.568561] [<0000000000434c24>] dump_stack+0x8/0x18 [   74.633757] [<0000000000476438>] __warn+0xd8/0x100 [   74.696664] [<00000000004296d4>] warn_slowpath_fmt+0x34/0x74 [   74.771006] [<00000000008db28c>] aa_dfa_unpack+0x6cc/0x720 [   74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0 [   74.910545] [<00000000008e7740>] unpack_profile+0xbe0/0x1300 [   74.984888] [<00000000008e82e0>] aa_unpack+0xe0/0x6a0 [   75.051226] [<00000000008e3ec4>] aa_replace_profiles+0x64/0x1160 [   75.130144] [<00000000008d4d90>] policy_update+0xf0/0x280 [   75.201057] [<00000000008d4fc8>] profile_replace+0xa8/0x100 [   75.274258] [<0000000000766bd0>] vfs_write+0x90/0x420 [   75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0 [   75.406932] [<0000000000767174>] sys_write+0x14/0x40 [   75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [   75.548802] ---[ end trace 0000000000000000 ]--- [   75.609503] dfa blob stream 0xfff0000008926b96 not aligned. [   75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720 Work around it by using the get_unaligned_xx() helpers. Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Closes: https://github.com/sparclinux/issues/issues/30 Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-11-25 16:11:07 +01:00
apparmor: add outofband transition and use it in xattr match There are cases where the a special out of band transition that can not be triggered by input is useful in separating match conditions in the dfa encoding. The null_transition is currently used as an out of band transition for match conditions that can not contain a \0 in their input but apparmor needs an out of band transition for cases where the match condition is allowed to contain any input character. Achieve this by allowing for an explicit transition out of input range that can only be triggered by code. Signed-off-by: John Johansen <john.johansen@canonical.com>
2019-07-30 02:42:13 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: propagate -ENOMEM correctly in unpack_table Currently, if the `kvzalloc` in `unpack_table` fails, it returns NULL. This is masked by `aa_dfa_unpack` which interprets NULL as a -EPROTO, leading to confusing error messages in `apparmor_parser` [1]. The fixed behavior correctly propagates -ENOMEM on allocation failure. Link: https://gitlab.com/apparmor/apparmor/-/issues/592 Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Maxime Bélair <maxime.belair@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-02-11 14:19:32 +01:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: propagate -ENOMEM correctly in unpack_table Currently, if the `kvzalloc` in `unpack_table` fails, it returns NULL. This is masked by `aa_dfa_unpack` which interprets NULL as a -EPROTO, leading to confusing error messages in `apparmor_parser` [1]. The fixed behavior correctly propagates -ENOMEM on allocation failure. Link: https://gitlab.com/apparmor/apparmor/-/issues/592 Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Maxime Bélair <maxime.belair@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-02-11 14:19:32 +01:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa split verification of table headers separate the different types of verification so they are logically separate and can be reused separate of each other. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 13:01:01 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: dfa move character match into a macro Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 11:58:33 -07:00
apparmor: dfa add support for state differential encoding State differential encoding can provide better compression for apparmor policy, without having significant impact on match time. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 12:10:50 -07:00
apparmor: dfa move character match into a macro Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 11:58:33 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -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: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -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: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -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: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: fix side-effect bug in match_char() macro usage The match_char() macro evaluates its character parameter multiple times when traversing differential encoding chains. When invoked with *str++, the string pointer advances on each iteration of the inner do-while loop, causing the DFA to check different characters at each iteration and therefore skip input characters. This results in out-of-bounds reads when the pointer advances past the input buffer boundary. [ 94.984676] ================================================================== [ 94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760 [ 94.985655] Read of size 1 at addr ffff888100342000 by task file/976 [ 94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 94.986329] Call Trace: [ 94.986341] <TASK> [ 94.986347] dump_stack_lvl+0x5e/0x80 [ 94.986374] print_report+0xc8/0x270 [ 94.986384] ? aa_dfa_match+0x5ae/0x760 [ 94.986388] kasan_report+0x118/0x150 [ 94.986401] ? aa_dfa_match+0x5ae/0x760 [ 94.986405] aa_dfa_match+0x5ae/0x760 [ 94.986408] __aa_path_perm+0x131/0x400 [ 94.986418] aa_path_perm+0x219/0x2f0 [ 94.986424] apparmor_file_open+0x345/0x570 [ 94.986431] security_file_open+0x5c/0x140 [ 94.986442] do_dentry_open+0x2f6/0x1120 [ 94.986450] vfs_open+0x38/0x2b0 [ 94.986453] ? may_open+0x1e2/0x2b0 [ 94.986466] path_openat+0x231b/0x2b30 [ 94.986469] ? __x64_sys_openat+0xf8/0x130 [ 94.986477] do_file_open+0x19d/0x360 [ 94.986487] do_sys_openat2+0x98/0x100 [ 94.986491] __x64_sys_openat+0xf8/0x130 [ 94.986499] do_syscall_64+0x8e/0x660 [ 94.986515] ? count_memcg_events+0x15f/0x3c0 [ 94.986526] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986540] ? handle_mm_fault+0x1639/0x1ef0 [ 94.986551] ? vma_start_read+0xf0/0x320 [ 94.986558] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986561] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986563] ? fpregs_assert_state_consistent+0x50/0xe0 [ 94.986572] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986574] ? arch_exit_to_user_mode_prepare+0x9/0xb0 [ 94.986587] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986588] ? irqentry_exit+0x3c/0x590 [ 94.986595] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 94.986597] RIP: 0033:0x7fda4a79c3ea Fix by extracting the character value before invoking match_char, ensuring single evaluation per outer loop. Fixes: 074c1cd798cb ("apparmor: dfa move character match into a macro") 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: Massimiliano Pellizzer <massimiliano.pellizzer@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-01-29 17:08:25 +01:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: fix side-effect bug in match_char() macro usage The match_char() macro evaluates its character parameter multiple times when traversing differential encoding chains. When invoked with *str++, the string pointer advances on each iteration of the inner do-while loop, causing the DFA to check different characters at each iteration and therefore skip input characters. This results in out-of-bounds reads when the pointer advances past the input buffer boundary. [ 94.984676] ================================================================== [ 94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760 [ 94.985655] Read of size 1 at addr ffff888100342000 by task file/976 [ 94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 94.986329] Call Trace: [ 94.986341] <TASK> [ 94.986347] dump_stack_lvl+0x5e/0x80 [ 94.986374] print_report+0xc8/0x270 [ 94.986384] ? aa_dfa_match+0x5ae/0x760 [ 94.986388] kasan_report+0x118/0x150 [ 94.986401] ? aa_dfa_match+0x5ae/0x760 [ 94.986405] aa_dfa_match+0x5ae/0x760 [ 94.986408] __aa_path_perm+0x131/0x400 [ 94.986418] aa_path_perm+0x219/0x2f0 [ 94.986424] apparmor_file_open+0x345/0x570 [ 94.986431] security_file_open+0x5c/0x140 [ 94.986442] do_dentry_open+0x2f6/0x1120 [ 94.986450] vfs_open+0x38/0x2b0 [ 94.986453] ? may_open+0x1e2/0x2b0 [ 94.986466] path_openat+0x231b/0x2b30 [ 94.986469] ? __x64_sys_openat+0xf8/0x130 [ 94.986477] do_file_open+0x19d/0x360 [ 94.986487] do_sys_openat2+0x98/0x100 [ 94.986491] __x64_sys_openat+0xf8/0x130 [ 94.986499] do_syscall_64+0x8e/0x660 [ 94.986515] ? count_memcg_events+0x15f/0x3c0 [ 94.986526] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986540] ? handle_mm_fault+0x1639/0x1ef0 [ 94.986551] ? vma_start_read+0xf0/0x320 [ 94.986558] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986561] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986563] ? fpregs_assert_state_consistent+0x50/0xe0 [ 94.986572] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986574] ? arch_exit_to_user_mode_prepare+0x9/0xb0 [ 94.986587] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986588] ? irqentry_exit+0x3c/0x590 [ 94.986595] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 94.986597] RIP: 0033:0x7fda4a79c3ea Fix by extracting the character value before invoking match_char, ensuring single evaluation per outer loop. Fixes: 074c1cd798cb ("apparmor: dfa move character match into a macro") 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: Massimiliano Pellizzer <massimiliano.pellizzer@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-01-29 17:08:25 +01:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
AppArmor: Update dfa matching routines. Update aa_dfa_match so that it doesn't result in an input string being walked twice (once to get its length and another time to match) Add a single step functions aa_dfa_next Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 06:20:26 -08:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
AppArmor: Update dfa matching routines. Update aa_dfa_match so that it doesn't result in an input string being walked twice (once to get its length and another time to match) Add a single step functions aa_dfa_next Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 06:20:26 -08:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -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: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
AppArmor: Update dfa matching routines. Update aa_dfa_match so that it doesn't result in an input string being walked twice (once to get its length and another time to match) Add a single step functions aa_dfa_next Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 06:20:26 -08:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -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: Update dfa matching routines. Update aa_dfa_match so that it doesn't result in an input string being walked twice (once to get its length and another time to match) Add a single step functions aa_dfa_next Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 06:20:26 -08: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: Update dfa matching routines. Update aa_dfa_match so that it doesn't result in an input string being walked twice (once to get its length and another time to match) Add a single step functions aa_dfa_next Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 06:20:26 -08:00
apparmor: fix side-effect bug in match_char() macro usage The match_char() macro evaluates its character parameter multiple times when traversing differential encoding chains. When invoked with *str++, the string pointer advances on each iteration of the inner do-while loop, causing the DFA to check different characters at each iteration and therefore skip input characters. This results in out-of-bounds reads when the pointer advances past the input buffer boundary. [ 94.984676] ================================================================== [ 94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760 [ 94.985655] Read of size 1 at addr ffff888100342000 by task file/976 [ 94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 94.986329] Call Trace: [ 94.986341] <TASK> [ 94.986347] dump_stack_lvl+0x5e/0x80 [ 94.986374] print_report+0xc8/0x270 [ 94.986384] ? aa_dfa_match+0x5ae/0x760 [ 94.986388] kasan_report+0x118/0x150 [ 94.986401] ? aa_dfa_match+0x5ae/0x760 [ 94.986405] aa_dfa_match+0x5ae/0x760 [ 94.986408] __aa_path_perm+0x131/0x400 [ 94.986418] aa_path_perm+0x219/0x2f0 [ 94.986424] apparmor_file_open+0x345/0x570 [ 94.986431] security_file_open+0x5c/0x140 [ 94.986442] do_dentry_open+0x2f6/0x1120 [ 94.986450] vfs_open+0x38/0x2b0 [ 94.986453] ? may_open+0x1e2/0x2b0 [ 94.986466] path_openat+0x231b/0x2b30 [ 94.986469] ? __x64_sys_openat+0xf8/0x130 [ 94.986477] do_file_open+0x19d/0x360 [ 94.986487] do_sys_openat2+0x98/0x100 [ 94.986491] __x64_sys_openat+0xf8/0x130 [ 94.986499] do_syscall_64+0x8e/0x660 [ 94.986515] ? count_memcg_events+0x15f/0x3c0 [ 94.986526] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986540] ? handle_mm_fault+0x1639/0x1ef0 [ 94.986551] ? vma_start_read+0xf0/0x320 [ 94.986558] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986561] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986563] ? fpregs_assert_state_consistent+0x50/0xe0 [ 94.986572] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986574] ? arch_exit_to_user_mode_prepare+0x9/0xb0 [ 94.986587] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986588] ? irqentry_exit+0x3c/0x590 [ 94.986595] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 94.986597] RIP: 0033:0x7fda4a79c3ea Fix by extracting the character value before invoking match_char, ensuring single evaluation per outer loop. Fixes: 074c1cd798cb ("apparmor: dfa move character match into a macro") 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: Massimiliano Pellizzer <massimiliano.pellizzer@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-01-29 17:08:25 +01:00
AppArmor: Update dfa matching routines. Update aa_dfa_match so that it doesn't result in an input string being walked twice (once to get its length and another time to match) Add a single step functions aa_dfa_next Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 06:20:26 -08:00
apparmor: fix side-effect bug in match_char() macro usage The match_char() macro evaluates its character parameter multiple times when traversing differential encoding chains. When invoked with *str++, the string pointer advances on each iteration of the inner do-while loop, causing the DFA to check different characters at each iteration and therefore skip input characters. This results in out-of-bounds reads when the pointer advances past the input buffer boundary. [ 94.984676] ================================================================== [ 94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760 [ 94.985655] Read of size 1 at addr ffff888100342000 by task file/976 [ 94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 94.986329] Call Trace: [ 94.986341] <TASK> [ 94.986347] dump_stack_lvl+0x5e/0x80 [ 94.986374] print_report+0xc8/0x270 [ 94.986384] ? aa_dfa_match+0x5ae/0x760 [ 94.986388] kasan_report+0x118/0x150 [ 94.986401] ? aa_dfa_match+0x5ae/0x760 [ 94.986405] aa_dfa_match+0x5ae/0x760 [ 94.986408] __aa_path_perm+0x131/0x400 [ 94.986418] aa_path_perm+0x219/0x2f0 [ 94.986424] apparmor_file_open+0x345/0x570 [ 94.986431] security_file_open+0x5c/0x140 [ 94.986442] do_dentry_open+0x2f6/0x1120 [ 94.986450] vfs_open+0x38/0x2b0 [ 94.986453] ? may_open+0x1e2/0x2b0 [ 94.986466] path_openat+0x231b/0x2b30 [ 94.986469] ? __x64_sys_openat+0xf8/0x130 [ 94.986477] do_file_open+0x19d/0x360 [ 94.986487] do_sys_openat2+0x98/0x100 [ 94.986491] __x64_sys_openat+0xf8/0x130 [ 94.986499] do_syscall_64+0x8e/0x660 [ 94.986515] ? count_memcg_events+0x15f/0x3c0 [ 94.986526] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986540] ? handle_mm_fault+0x1639/0x1ef0 [ 94.986551] ? vma_start_read+0xf0/0x320 [ 94.986558] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986561] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986563] ? fpregs_assert_state_consistent+0x50/0xe0 [ 94.986572] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986574] ? arch_exit_to_user_mode_prepare+0x9/0xb0 [ 94.986587] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986588] ? irqentry_exit+0x3c/0x590 [ 94.986595] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 94.986597] RIP: 0033:0x7fda4a79c3ea Fix by extracting the character value before invoking match_char, ensuring single evaluation per outer loop. Fixes: 074c1cd798cb ("apparmor: dfa move character match into a macro") 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: Massimiliano Pellizzer <massimiliano.pellizzer@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-01-29 17:08:25 +01:00
AppArmor: Update dfa matching routines. Update aa_dfa_match so that it doesn't result in an input string being walked twice (once to get its length and another time to match) Add a single step functions aa_dfa_next Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 06:20:26 -08:00
apparmor: fix typo "traverse" Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> Acked-by: Christian Boltz <apparmor@cboltz.de> Signed-off-by: John Johansen <john.johansen@canonical.com>
2018-04-12 12:34:32 +02:00
AppArmor: Update dfa matching routines. Update aa_dfa_match so that it doesn't result in an input string being walked twice (once to get its length and another time to match) Add a single step functions aa_dfa_next Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 06:20:26 -08: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: Update dfa matching routines. Update aa_dfa_match so that it doesn't result in an input string being walked twice (once to get its length and another time to match) Add a single step functions aa_dfa_next Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 06:20:26 -08:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
AppArmor: Update dfa matching routines. Update aa_dfa_match so that it doesn't result in an input string being walked twice (once to get its length and another time to match) Add a single step functions aa_dfa_next Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 06:20:26 -08:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
AppArmor: Update dfa matching routines. Update aa_dfa_match so that it doesn't result in an input string being walked twice (once to get its length and another time to match) Add a single step functions aa_dfa_next Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 06:20:26 -08:00
apparmor: dfa move character match into a macro Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-08-08 11:58:33 -07:00
AppArmor: Update dfa matching routines. Update aa_dfa_match so that it doesn't result in an input string being walked twice (once to get its length and another time to match) Add a single step functions aa_dfa_next Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
2012-02-16 06:20:26 -08:00
AppArmor: dfa match engine A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field. This allows AppArmor to do pattern matching in linear time, and also avoids stack issues that an nfa based engine may have. The dfa engine uses a byte based comparison, with all values being valid. Any potential character encoding are handled user side when the dfa tables are created. By convention AppArmor uses \0 to separate two dependent path matches since \0 is not a valid path character (this is done in the link permission check). The dfa tables are generated in user space and are verified at load time to be internally consistent. There are several future improvements planned for the dfa engine: * The dfa engine may be converted to a hybrid nfa-dfa engine, with a fixed size limited stack. This would allow for size time tradeoffs, by inserting limited nfa states to help control state explosion that can occur with dfas. * The dfa engine may pickup the ability to do limited dynamic variable matching, instead of fixing all variables at policy load time. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-07-29 14:48:01 -07:00
apparmor: add first substr match to dfa Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2017-09-06 02:53:15 -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 outofband transition and use it in xattr match There are cases where the a special out of band transition that can not be triggered by input is useful in separating match conditions in the dfa encoding. The null_transition is currently used as an out of band transition for match conditions that can not contain a \0 in their input but apparmor needs an out of band transition for cases where the match condition is allowed to contain any input character. Achieve this by allowing for an explicit transition out of input range that can only be triggered by code. Signed-off-by: John Johansen <john.johansen@canonical.com>
2019-07-30 02:42:13 -07:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
apparmor: add outofband transition and use it in xattr match There are cases where the a special out of band transition that can not be triggered by input is useful in separating match conditions in the dfa encoding. The null_transition is currently used as an out of band transition for match conditions that can not contain a \0 in their input but apparmor needs an out of band transition for cases where the match condition is allowed to contain any input character. Achieve this by allowing for an explicit transition out of input range that can only be triggered by code. Signed-off-by: John Johansen <john.johansen@canonical.com>
2019-07-30 02:42:13 -07:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
apparmor: add outofband transition and use it in xattr match There are cases where the a special out of band transition that can not be triggered by input is useful in separating match conditions in the dfa encoding. The null_transition is currently used as an out of band transition for match conditions that can not contain a \0 in their input but apparmor needs an out of band transition for cases where the match condition is allowed to contain any input character. Achieve this by allowing for an explicit transition out of input range that can only be triggered by code. Signed-off-by: John Johansen <john.johansen@canonical.com>
2019-07-30 02:42:13 -07:00
apparmor: add first substr match to dfa Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2017-09-06 02:53:15 -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 first substr match to dfa Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2017-09-06 02:53:15 -07:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
apparmor: add first substr match to dfa Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2017-09-06 02:53:15 -07:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
apparmor: add first substr match to dfa Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2017-09-06 02:53:15 -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 first substr match to dfa Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2017-09-06 02:53:15 -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 first substr match to dfa Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2017-09-06 02:53:15 -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 first substr match to dfa Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2017-09-06 02:53:15 -07:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
apparmor: add first substr match to dfa Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2017-09-06 02:53:15 -07:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
apparmor: add first substr match to dfa Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2017-09-06 02:53:15 -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 first substr match to dfa Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2017-09-06 02:53:15 -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 first substr match to dfa Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
2017-09-06 02:53:15 -07:00
apparmor: improve overlapping domain attachment resolution Overlapping domain attachments using the current longest left exact match fail in some simple cases, and with the fix to ensure consistent behavior by failing unresolvable attachments it becomes important to do a better job. eg. under the current match the following are unresolvable where the alternation is clearly a better match under the most specific left match rule. /** /{bin/,}usr/ Use a counting match that detects when a loop in the state machine is enter, and return the match count to provide a better specific left match resolution. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-11-18 19:43:13 -08:00
apparmor: fix loop detection used in conflicting attachment resolution Conflicting attachment resolution is based on the number of states traversed to reach an accepting state in the attachment DFA, accounting for DFA loops traversed during the matching process. However, the loop counting logic had multiple bugs: - The inc_wb_pos macro increments both position and length, but length is supposed to saturate upon hitting buffer capacity, instead of wrapping around. - If no revisited state is found when traversing the history, is_loop would still return true, as if there was a loop found the length of the history buffer, instead of returning false and signalling that no loop was found. As a result, the adjustment step of aa_dfa_leftmatch would sometimes produce negative counts with loop- free DFAs that traversed enough states. - The iteration in the is_loop for loop is supposed to stop before i = wb->len, so the conditional should be < instead of <=. This patch fixes the above bugs as well as the following nits: - The count and size fields in struct match_workbuf were not used, so they can be removed. - The history buffer in match_workbuf semantically stores aa_state_t and not unsigned ints, even if aa_state_t is currently unsigned int. - The local variables in is_loop are counters, and thus should be unsigned ints instead of aa_state_t's. Fixes: 21f606610502 ("apparmor: improve overlapping domain attachment resolution") Signed-off-by: Ryan Lee <ryan.lee@canonical.com> Co-developed-by: John Johansen <john.johansen@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-05-01 12:54:39 -07:00
apparmor: ensure WB_HISTORY_SIZE value is a power of 2 WB_HISTORY_SIZE was defined to be a value not a power of 2, despite a comment in the declaration of struct match_workbuf stating it is and a modular arithmetic usage in the inc_wb_pos macro assuming that it is. Bump WB_HISTORY_SIZE's value up to 32 and add a BUILD_BUG_ON_NOT_POWER_OF_2 line to ensure that any future changes to the value of WB_HISTORY_SIZE respect this requirement. Fixes: 136db994852a ("apparmor: increase left match history buffer size") Signed-off-by: Ryan Lee <ryan.lee@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-05-01 12:54:38 -07:00
apparmor: increase left match history buffer size There have been cases reported where a history buffer size of 8 was not enough to resolve conflict overlaps. Increase the buffer to and get rid of the size element which is currently just storing the constant WB_HISTORY_SIZE. Signed-off-by: John Johansen <john.johansen@canonical.com>
2019-05-31 06:54:54 -07:00
apparmor: fix loop detection used in conflicting attachment resolution Conflicting attachment resolution is based on the number of states traversed to reach an accepting state in the attachment DFA, accounting for DFA loops traversed during the matching process. However, the loop counting logic had multiple bugs: - The inc_wb_pos macro increments both position and length, but length is supposed to saturate upon hitting buffer capacity, instead of wrapping around. - If no revisited state is found when traversing the history, is_loop would still return true, as if there was a loop found the length of the history buffer, instead of returning false and signalling that no loop was found. As a result, the adjustment step of aa_dfa_leftmatch would sometimes produce negative counts with loop- free DFAs that traversed enough states. - The iteration in the is_loop for loop is supposed to stop before i = wb->len, so the conditional should be < instead of <=. This patch fixes the above bugs as well as the following nits: - The count and size fields in struct match_workbuf were not used, so they can be removed. - The history buffer in match_workbuf semantically stores aa_state_t and not unsigned ints, even if aa_state_t is currently unsigned int. - The local variables in is_loop are counters, and thus should be unsigned ints instead of aa_state_t's. Fixes: 21f606610502 ("apparmor: improve overlapping domain attachment resolution") Signed-off-by: Ryan Lee <ryan.lee@canonical.com> Co-developed-by: John Johansen <john.johansen@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-05-01 12:54:39 -07:00
apparmor: improve overlapping domain attachment resolution Overlapping domain attachments using the current longest left exact match fail in some simple cases, and with the fix to ensure consistent behavior by failing unresolvable attachments it becomes important to do a better job. eg. under the current match the following are unresolvable where the alternation is clearly a better match under the most specific left match rule. /** /{bin/,}usr/ Use a counting match that detects when a loop in the state machine is enter, and return the match count to provide a better specific left match resolution. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-11-18 19:43:13 -08:00
apparmor: fix loop detection used in conflicting attachment resolution Conflicting attachment resolution is based on the number of states traversed to reach an accepting state in the attachment DFA, accounting for DFA loops traversed during the matching process. However, the loop counting logic had multiple bugs: - The inc_wb_pos macro increments both position and length, but length is supposed to saturate upon hitting buffer capacity, instead of wrapping around. - If no revisited state is found when traversing the history, is_loop would still return true, as if there was a loop found the length of the history buffer, instead of returning false and signalling that no loop was found. As a result, the adjustment step of aa_dfa_leftmatch would sometimes produce negative counts with loop- free DFAs that traversed enough states. - The iteration in the is_loop for loop is supposed to stop before i = wb->len, so the conditional should be < instead of <=. This patch fixes the above bugs as well as the following nits: - The count and size fields in struct match_workbuf were not used, so they can be removed. - The history buffer in match_workbuf semantically stores aa_state_t and not unsigned ints, even if aa_state_t is currently unsigned int. - The local variables in is_loop are counters, and thus should be unsigned ints instead of aa_state_t's. Fixes: 21f606610502 ("apparmor: improve overlapping domain attachment resolution") Signed-off-by: Ryan Lee <ryan.lee@canonical.com> Co-developed-by: John Johansen <john.johansen@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-05-01 12:54:39 -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: improve overlapping domain attachment resolution Overlapping domain attachments using the current longest left exact match fail in some simple cases, and with the fix to ensure consistent behavior by failing unresolvable attachments it becomes important to do a better job. eg. under the current match the following are unresolvable where the alternation is clearly a better match under the most specific left match rule. /** /{bin/,}usr/ Use a counting match that detects when a loop in the state machine is enter, and return the match count to provide a better specific left match resolution. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-11-18 19:43:13 -08:00
apparmor: fix loop detection used in conflicting attachment resolution Conflicting attachment resolution is based on the number of states traversed to reach an accepting state in the attachment DFA, accounting for DFA loops traversed during the matching process. However, the loop counting logic had multiple bugs: - The inc_wb_pos macro increments both position and length, but length is supposed to saturate upon hitting buffer capacity, instead of wrapping around. - If no revisited state is found when traversing the history, is_loop would still return true, as if there was a loop found the length of the history buffer, instead of returning false and signalling that no loop was found. As a result, the adjustment step of aa_dfa_leftmatch would sometimes produce negative counts with loop- free DFAs that traversed enough states. - The iteration in the is_loop for loop is supposed to stop before i = wb->len, so the conditional should be < instead of <=. This patch fixes the above bugs as well as the following nits: - The count and size fields in struct match_workbuf were not used, so they can be removed. - The history buffer in match_workbuf semantically stores aa_state_t and not unsigned ints, even if aa_state_t is currently unsigned int. - The local variables in is_loop are counters, and thus should be unsigned ints instead of aa_state_t's. Fixes: 21f606610502 ("apparmor: improve overlapping domain attachment resolution") Signed-off-by: Ryan Lee <ryan.lee@canonical.com> Co-developed-by: John Johansen <john.johansen@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-05-01 12:54:39 -07:00
apparmor: improve overlapping domain attachment resolution Overlapping domain attachments using the current longest left exact match fail in some simple cases, and with the fix to ensure consistent behavior by failing unresolvable attachments it becomes important to do a better job. eg. under the current match the following are unresolvable where the alternation is clearly a better match under the most specific left match rule. /** /{bin/,}usr/ Use a counting match that detects when a loop in the state machine is enter, and return the match count to provide a better specific left match resolution. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-11-18 19:43:13 -08:00
apparmor: fix loop detection used in conflicting attachment resolution Conflicting attachment resolution is based on the number of states traversed to reach an accepting state in the attachment DFA, accounting for DFA loops traversed during the matching process. However, the loop counting logic had multiple bugs: - The inc_wb_pos macro increments both position and length, but length is supposed to saturate upon hitting buffer capacity, instead of wrapping around. - If no revisited state is found when traversing the history, is_loop would still return true, as if there was a loop found the length of the history buffer, instead of returning false and signalling that no loop was found. As a result, the adjustment step of aa_dfa_leftmatch would sometimes produce negative counts with loop- free DFAs that traversed enough states. - The iteration in the is_loop for loop is supposed to stop before i = wb->len, so the conditional should be < instead of <=. This patch fixes the above bugs as well as the following nits: - The count and size fields in struct match_workbuf were not used, so they can be removed. - The history buffer in match_workbuf semantically stores aa_state_t and not unsigned ints, even if aa_state_t is currently unsigned int. - The local variables in is_loop are counters, and thus should be unsigned ints instead of aa_state_t's. Fixes: 21f606610502 ("apparmor: improve overlapping domain attachment resolution") Signed-off-by: Ryan Lee <ryan.lee@canonical.com> Co-developed-by: John Johansen <john.johansen@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-05-01 12:54:39 -07:00
apparmor: improve overlapping domain attachment resolution Overlapping domain attachments using the current longest left exact match fail in some simple cases, and with the fix to ensure consistent behavior by failing unresolvable attachments it becomes important to do a better job. eg. under the current match the following are unresolvable where the alternation is clearly a better match under the most specific left match rule. /** /{bin/,}usr/ Use a counting match that detects when a loop in the state machine is enter, and return the match count to provide a better specific left match resolution. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-11-18 19:43:13 -08:00
apparmor: fix loop detection used in conflicting attachment resolution Conflicting attachment resolution is based on the number of states traversed to reach an accepting state in the attachment DFA, accounting for DFA loops traversed during the matching process. However, the loop counting logic had multiple bugs: - The inc_wb_pos macro increments both position and length, but length is supposed to saturate upon hitting buffer capacity, instead of wrapping around. - If no revisited state is found when traversing the history, is_loop would still return true, as if there was a loop found the length of the history buffer, instead of returning false and signalling that no loop was found. As a result, the adjustment step of aa_dfa_leftmatch would sometimes produce negative counts with loop- free DFAs that traversed enough states. - The iteration in the is_loop for loop is supposed to stop before i = wb->len, so the conditional should be < instead of <=. This patch fixes the above bugs as well as the following nits: - The count and size fields in struct match_workbuf were not used, so they can be removed. - The history buffer in match_workbuf semantically stores aa_state_t and not unsigned ints, even if aa_state_t is currently unsigned int. - The local variables in is_loop are counters, and thus should be unsigned ints instead of aa_state_t's. Fixes: 21f606610502 ("apparmor: improve overlapping domain attachment resolution") Signed-off-by: Ryan Lee <ryan.lee@canonical.com> Co-developed-by: John Johansen <john.johansen@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-05-01 12:54:39 -07:00
apparmor: improve overlapping domain attachment resolution Overlapping domain attachments using the current longest left exact match fail in some simple cases, and with the fix to ensure consistent behavior by failing unresolvable attachments it becomes important to do a better job. eg. under the current match the following are unresolvable where the alternation is clearly a better match under the most specific left match rule. /** /{bin/,}usr/ Use a counting match that detects when a loop in the state machine is enter, and return the match count to provide a better specific left match resolution. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-11-18 19:43:13 -08:00
apparmor: fix loop detection used in conflicting attachment resolution Conflicting attachment resolution is based on the number of states traversed to reach an accepting state in the attachment DFA, accounting for DFA loops traversed during the matching process. However, the loop counting logic had multiple bugs: - The inc_wb_pos macro increments both position and length, but length is supposed to saturate upon hitting buffer capacity, instead of wrapping around. - If no revisited state is found when traversing the history, is_loop would still return true, as if there was a loop found the length of the history buffer, instead of returning false and signalling that no loop was found. As a result, the adjustment step of aa_dfa_leftmatch would sometimes produce negative counts with loop- free DFAs that traversed enough states. - The iteration in the is_loop for loop is supposed to stop before i = wb->len, so the conditional should be < instead of <=. This patch fixes the above bugs as well as the following nits: - The count and size fields in struct match_workbuf were not used, so they can be removed. - The history buffer in match_workbuf semantically stores aa_state_t and not unsigned ints, even if aa_state_t is currently unsigned int. - The local variables in is_loop are counters, and thus should be unsigned ints instead of aa_state_t's. Fixes: 21f606610502 ("apparmor: improve overlapping domain attachment resolution") Signed-off-by: Ryan Lee <ryan.lee@canonical.com> Co-developed-by: John Johansen <john.johansen@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-05-01 12:54:39 -07:00
apparmor: improve overlapping domain attachment resolution Overlapping domain attachments using the current longest left exact match fail in some simple cases, and with the fix to ensure consistent behavior by failing unresolvable attachments it becomes important to do a better job. eg. under the current match the following are unresolvable where the alternation is clearly a better match under the most specific left match rule. /** /{bin/,}usr/ Use a counting match that detects when a loop in the state machine is enter, and return the match count to provide a better specific left match resolution. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-11-18 19:43:13 -08: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: improve overlapping domain attachment resolution Overlapping domain attachments using the current longest left exact match fail in some simple cases, and with the fix to ensure consistent behavior by failing unresolvable attachments it becomes important to do a better job. eg. under the current match the following are unresolvable where the alternation is clearly a better match under the most specific left match rule. /** /{bin/,}usr/ Use a counting match that detects when a loop in the state machine is enter, and return the match count to provide a better specific left match resolution. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-11-18 19:43:13 -08:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -07:00
apparmor: improve overlapping domain attachment resolution Overlapping domain attachments using the current longest left exact match fail in some simple cases, and with the fix to ensure consistent behavior by failing unresolvable attachments it becomes important to do a better job. eg. under the current match the following are unresolvable where the alternation is clearly a better match under the most specific left match rule. /** /{bin/,}usr/ Use a counting match that detects when a loop in the state machine is enter, and return the match count to provide a better specific left match resolution. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-11-18 19:43:13 -08:00
apparmor: add support for 2^24 states to the dfa state machine. Currently the dfa state machine is limited by its default, next, and check tables using u16. Allow loading of u32 tables, and if u16 tables are loaded map them to u32. The number of states allowed does not increase to 2^32 because the base table uses the top 8 bits of its u32 for flags. Moving the flags into a separate table allowing a full 2^32 bit range wil be done in a separate patch. Link: https://gitlab.com/apparmor/apparmor/-/issues/419 Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-08-23 21:40:47 -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: improve overlapping domain attachment resolution Overlapping domain attachments using the current longest left exact match fail in some simple cases, and with the fix to ensure consistent behavior by failing unresolvable attachments it becomes important to do a better job. eg. under the current match the following are unresolvable where the alternation is clearly a better match under the most specific left match rule. /** /{bin/,}usr/ Use a counting match that detects when a loop in the state machine is enter, and return the match count to provide a better specific left match resolution. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-11-18 19:43:13 -08: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: improve overlapping domain attachment resolution Overlapping domain attachments using the current longest left exact match fail in some simple cases, and with the fix to ensure consistent behavior by failing unresolvable attachments it becomes important to do a better job. eg. under the current match the following are unresolvable where the alternation is clearly a better match under the most specific left match rule. /** /{bin/,}usr/ Use a counting match that detects when a loop in the state machine is enter, and return the match count to provide a better specific left match resolution. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-11-18 19:43:13 -08: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: improve overlapping domain attachment resolution Overlapping domain attachments using the current longest left exact match fail in some simple cases, and with the fix to ensure consistent behavior by failing unresolvable attachments it becomes important to do a better job. eg. under the current match the following are unresolvable where the alternation is clearly a better match under the most specific left match rule. /** /{bin/,}usr/ Use a counting match that detects when a loop in the state machine is enter, and return the match count to provide a better specific left match resolution. Signed-off-by: John Johansen <john.johansen@canonical.com>
2017-11-18 19:43:13 -08:00