mir/apparmor
2
0
Fork 0
mirror of https://gitlab.com/apparmor/apparmor synced 2025-08-22 10:07:12 +00:00
Code Issues Releases Wiki Activity
apparmor/parser/tst/minimize.sh

249 lines
9.0 KiB
Bash
Raw Normal View History

parser: use /bin/sh for minimize test There are no bashisms in the minimize.sh test script, so convert to using to /bin/sh Signed-off-by: Steve Beattie <steve.beattie@canonical.com> Bug: https://gitlab.com/apparmor/apparmor/issues/18
2019-01-31 23:23:23 -08:00
#!/bin/sh
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
Subject: parameterize parser tests to support different binaries This patch replaces the hardcoded path to the in-tree apparmor parser in several of the script based test scripts with the APPARMOR_PARSER environment variable, keeping the hardcoded location as the default. It also adds support for overriding the location of the parser via the same environment variable. The make infrastructure is updated to use this, though uses a different variable (PARSER) to drive it. Thus 'make check PARSER=/some/path/to/an/alternate/apparmor_parser' will run all the parser tests on that binary. This is useful for running the testsuite in an automated post-install environment. (It should be noted that doing so will still build and run the unit test binaries based on the source tree.) Signed-off-by: Steve Beattie <sbeattie@ubuntu.com> Acked-By: John Johansen <john.johansen@canonical.com>
2012-11-05 17:22:37 -08:00
#
APPARMOR_PARSER="${APPARMOR_PARSER:-../apparmor_parser}"
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
# Format of -D dfa-states
# dfa-states output is split into 2 parts:
treewide: spelling/typo fixes in comments and docs With the exception of the documentation fixes, these should all be invisible to users. Signed-off-by: Steve Beattie <steve.beattie@canonical.com> Acked-by: Christian Boltz <apparmor@cboltz.de> MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/687
2020-11-19 12:30:04 -08:00
# the accept state information
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
# {state} (allow deny audit XXX) ignore XXX for now
# followed by the transition table information
# {Y} -> {Z}: 0xXX Char #0xXX is the hex dump of Char
# where the start state is always shown as
# {1} <==
#
# Eg. echo "/t { /a r, /b w, /c a, /d l, /e k, /f m, deny /** w, }" | ./apparmor_parser -QT -O minimize -D dfa-states --quiet
#
# {1} <== (allow/deny/audit/quiet)
# {3} (0x 0/2800a/0/2800a)
# {4} (0x 10004/2800a/0/2800a)
# {7} (0x 40010/2800a/0/2800a)
# {8} (0x 80020/2800a/0/2800a)
# {9} (0x 100040/2800a/0/2800a)
# {c} (0x 40030/0/0/0)
#
# {1} -> {2}: 0x2f /
# {2} -> {4}: 0x61 a
# {2} -> {3}: 0x62 b
# {2} -> {3}: 0x63 c
# {2} -> {7}: 0x64 d
# {2} -> {8}: 0x65 e
# {2} -> {9}: 0x66 f
# {2} -> {3}: [^\0x0/]
# {3} -> {3}: [^\0x0]
# {4} -> {3}: [^\0x0]
# {7} -> {a}: 0x0
# {7} -> {3}: []
# {8} -> {3}: [^\0x0]
# {9} -> {3}: [^\0x0]
# {a} -> {b}: 0x2f /
# {b} -> {c}: [^/]
# {c} -> {c}: []
#
# These tests currently only look at the accept state permissions
#
# To view any of these DFAs as graphs replace --D dfa-states with -D dfa-graph
treewide: spelling/typo fixes in comments and docs With the exception of the documentation fixes, these should all be invisible to users. Signed-off-by: Steve Beattie <steve.beattie@canonical.com> Acked-by: Christian Boltz <apparmor@cboltz.de> MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/687
2020-11-19 12:30:04 -08:00
# strip of the test stuff around the parser command and use the dot
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
# command to convert
# Eg.
# echo "/t { /a r, /b w, /c a, /d l, /e k, /f m, deny /** w, }" | ./apparmor_parser -QT -O minimize -D dfa-graph --quiet 2>min.graph
# dot -T png -o min.png min.graph
# and then view min.png in your favorite viewer
#
#------------------------------------------------------------------------
# test to see if minimization is eliminating non-redundant accept state
# Test xtrans and regular perms separately. The are the same basic failure
# but can xtrans has an extra code path.
#
# The permission test is setup to have all the none xtrans permissions show
# up once on unique paths and have a global write permission that adds to
# it.
# This should result in a un-minimized dump looking like. Notice it has 6
# states with accept information, 1 for each rule except for the 'w'
# permission which is combined into a single state for /b and /**
#
# {1} <== (allow/deny/audit/quiet)
# {3} (0x 2800a/0/0/0)
# {4} (0x 3800e/0/0/0)
# {5} (0x 6801a/0/0/0)
# {6} (0x a802a/0/0/0)
# {7} (0x 12804a/0/0/0)
# {a} (0x 40030/0/0/0)
# A dump of minimization that is not respecting the uniqueness of the
# permissions on the states looks like below. Notice it has only 3 states
# with accept information
# {1} <== (allow/deny/audit/quiet)
# {3} (0x 1b806e/0/0/0)
# {5} (0x 6801a/0/0/0)
# {a} (0x 40030/0/0/0)
echo -n "Minimize profiles basic perms "
parser: Add support for automatic @{attach_path} variable Have the parser extract the attachment path from the profile declaration and make it available as a variable within the profile. This allows profile rules to use the executable attachment path in rules. eg. ``` profile ex /bin/** { @{attach_path} r, # ... } profile /path/to/bin { @{attach_path} r, # ... } ``` if a profile does not define an attachment like ``` profile noattach { @{attach_path} r, } ``` the apparmor_parser will fail the compile with the error. ``` Found reference to variable attach_path, but is never declared ``` The attachment xattr/label conditionals are not made available at this time as regular file path rules can not use them. Similarly a @{exec_path} variable is made available. It is different than @{attach_path} in that it is intended to be a kernel variable that represents the specific executable that was matched at run time. However to support policy on kernels that don't define the kernel variable it has a fallback value that is the same as @{attach_path}. This patch is a follow on to MR:1637 (https://gitlab.com/apparmor/apparmor/-/merge_requests/1637) and is similar to how the apparmor.d project uses the manually setup @{exec_path} variable. We can bike shed over the variable name. @{attach_path} was chosen here because this is the attachment conditional path for the executable, not the executable's actual path. While @{exec_path} is intended to be the applications actual executable path. support the @{exec_path} kernel variable (all of them atm). Notes: The minimize.sh tests are changed because this patch causes path based profile names to create an attachment. This could be done by doing the attach_variable expansion in the alternate location marked by the patch, but since the kernel is going to start doing this for all profiles that don't have an attachment it is better for the parser to do it, as it can optimize better. This patch may cause breakage if policy declares either @{attach_path} or @{exec_path} this will not be dealt with here, but in a subsequent patch that allows variables to have a local scope so that the compiler defined vars will just get declared locally. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-04-20 16:34:51 -07:00
if [ "$(echo "profile t { /a r, /b w, /c a, /d l, /e k, /f m, /** w, }" | ${APPARMOR_PARSER} -M features_files/features.nopolicydb -QT -O minimize -D dfa-states 2>&1 | grep -v '<==' | grep -c '^{.*}(.*)$')" -ne 6 ] ; then
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
echo "failed"
exit 1;
fi
echo "ok"
# same test as above except with audit perms added
# {1} <== (allow/deny/audit/quiet)
# {3} (0x 2800a/0/2800a/0)
# {4} (0x 3800e/0/2800a/0)
# {7} (0x 6801a/0/2800a/0)
# {8} (0x a802a/0/2800a/0)
# {9} (0x 12804a/0/2800a/0)
# {c} (0x 40030/0/0/0)
echo -n "Minimize profiles audit perms "
parser: Add support for automatic @{attach_path} variable Have the parser extract the attachment path from the profile declaration and make it available as a variable within the profile. This allows profile rules to use the executable attachment path in rules. eg. ``` profile ex /bin/** { @{attach_path} r, # ... } profile /path/to/bin { @{attach_path} r, # ... } ``` if a profile does not define an attachment like ``` profile noattach { @{attach_path} r, } ``` the apparmor_parser will fail the compile with the error. ``` Found reference to variable attach_path, but is never declared ``` The attachment xattr/label conditionals are not made available at this time as regular file path rules can not use them. Similarly a @{exec_path} variable is made available. It is different than @{attach_path} in that it is intended to be a kernel variable that represents the specific executable that was matched at run time. However to support policy on kernels that don't define the kernel variable it has a fallback value that is the same as @{attach_path}. This patch is a follow on to MR:1637 (https://gitlab.com/apparmor/apparmor/-/merge_requests/1637) and is similar to how the apparmor.d project uses the manually setup @{exec_path} variable. We can bike shed over the variable name. @{attach_path} was chosen here because this is the attachment conditional path for the executable, not the executable's actual path. While @{exec_path} is intended to be the applications actual executable path. support the @{exec_path} kernel variable (all of them atm). Notes: The minimize.sh tests are changed because this patch causes path based profile names to create an attachment. This could be done by doing the attach_variable expansion in the alternate location marked by the patch, but since the kernel is going to start doing this for all profiles that don't have an attachment it is better for the parser to do it, as it can optimize better. This patch may cause breakage if policy declares either @{attach_path} or @{exec_path} this will not be dealt with here, but in a subsequent patch that allows variables to have a local scope so that the compiler defined vars will just get declared locally. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-04-20 16:34:51 -07:00
if [ "$(echo "profile t { /a r, /b w, /c a, /d l, /e k, /f m, audit /** w, }" | ${APPARMOR_PARSER} -M features_files/features.nopolicydb -QT -O minimize -D dfa-states 2>&1 | grep -v '<==' | grep -c '^{.*}(.*)$')" -ne 6 ] ; then
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
echo "failed"
exit 1;
fi
echo "ok"
# same test as above except with deny 'w' perm added to /**, this does not
treewide: spelling/typo fixes in comments and docs With the exception of the documentation fixes, these should all be invisible to users. Signed-off-by: Steve Beattie <steve.beattie@canonical.com> Acked-by: Christian Boltz <apparmor@cboltz.de> MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/687
2020-11-19 12:30:04 -08:00
# eliminates the states with 'w' and 'a' because the quiet information is
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
# being carried
#
# {1} <== (allow/deny/audit/quiet)
# {3} (0x 0/2800a/0/2800a)
# {4} (0x 10004/2800a/0/2800a)
# {7} (0x 40010/2800a/0/2800a)
# {8} (0x 80020/2800a/0/2800a)
# {9} (0x 100040/2800a/0/2800a)
# {c} (0x 40030/0/0/0)
echo -n "Minimize profiles deny perms "
parser: Add support for automatic @{attach_path} variable Have the parser extract the attachment path from the profile declaration and make it available as a variable within the profile. This allows profile rules to use the executable attachment path in rules. eg. ``` profile ex /bin/** { @{attach_path} r, # ... } profile /path/to/bin { @{attach_path} r, # ... } ``` if a profile does not define an attachment like ``` profile noattach { @{attach_path} r, } ``` the apparmor_parser will fail the compile with the error. ``` Found reference to variable attach_path, but is never declared ``` The attachment xattr/label conditionals are not made available at this time as regular file path rules can not use them. Similarly a @{exec_path} variable is made available. It is different than @{attach_path} in that it is intended to be a kernel variable that represents the specific executable that was matched at run time. However to support policy on kernels that don't define the kernel variable it has a fallback value that is the same as @{attach_path}. This patch is a follow on to MR:1637 (https://gitlab.com/apparmor/apparmor/-/merge_requests/1637) and is similar to how the apparmor.d project uses the manually setup @{exec_path} variable. We can bike shed over the variable name. @{attach_path} was chosen here because this is the attachment conditional path for the executable, not the executable's actual path. While @{exec_path} is intended to be the applications actual executable path. support the @{exec_path} kernel variable (all of them atm). Notes: The minimize.sh tests are changed because this patch causes path based profile names to create an attachment. This could be done by doing the attach_variable expansion in the alternate location marked by the patch, but since the kernel is going to start doing this for all profiles that don't have an attachment it is better for the parser to do it, as it can optimize better. This patch may cause breakage if policy declares either @{attach_path} or @{exec_path} this will not be dealt with here, but in a subsequent patch that allows variables to have a local scope so that the compiler defined vars will just get declared locally. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-04-20 16:34:51 -07:00
if [ "$(echo "profile t { /a r, /b w, /c a, /d l, /e k, /f m, deny /** w, }" | ${APPARMOR_PARSER} -M features_files/features.nopolicydb -QT -O minimize -D dfa-states 2>&1 | grep -v '<==' | grep -c '^{.*}(.*)$')" -ne 6 ] ; then
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
echo "failed"
exit 1;
fi
echo "ok"
# same test as above except with audit deny 'w' perm added to /**, with the
treewide: spelling/typo fixes in comments and docs With the exception of the documentation fixes, these should all be invisible to users. Signed-off-by: Steve Beattie <steve.beattie@canonical.com> Acked-by: Christian Boltz <apparmor@cboltz.de> MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/687
2020-11-19 12:30:04 -08:00
# parameter this eliminates the states with 'w' and 'a' because
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
# the quiet information is NOT being carried
#
# {1} <== (allow/deny/audit/quiet)
# {4} (0x 10004/0/0/0)
# {7} (0x 40010/0/0/0)
# {8} (0x 80020/0/0/0)
# {9} (0x 100040/0/0/0)
# {c} (0x 40030/0/0/0)
echo -n "Minimize profiles audit deny perms "
parser: Add support for automatic @{attach_path} variable Have the parser extract the attachment path from the profile declaration and make it available as a variable within the profile. This allows profile rules to use the executable attachment path in rules. eg. ``` profile ex /bin/** { @{attach_path} r, # ... } profile /path/to/bin { @{attach_path} r, # ... } ``` if a profile does not define an attachment like ``` profile noattach { @{attach_path} r, } ``` the apparmor_parser will fail the compile with the error. ``` Found reference to variable attach_path, but is never declared ``` The attachment xattr/label conditionals are not made available at this time as regular file path rules can not use them. Similarly a @{exec_path} variable is made available. It is different than @{attach_path} in that it is intended to be a kernel variable that represents the specific executable that was matched at run time. However to support policy on kernels that don't define the kernel variable it has a fallback value that is the same as @{attach_path}. This patch is a follow on to MR:1637 (https://gitlab.com/apparmor/apparmor/-/merge_requests/1637) and is similar to how the apparmor.d project uses the manually setup @{exec_path} variable. We can bike shed over the variable name. @{attach_path} was chosen here because this is the attachment conditional path for the executable, not the executable's actual path. While @{exec_path} is intended to be the applications actual executable path. support the @{exec_path} kernel variable (all of them atm). Notes: The minimize.sh tests are changed because this patch causes path based profile names to create an attachment. This could be done by doing the attach_variable expansion in the alternate location marked by the patch, but since the kernel is going to start doing this for all profiles that don't have an attachment it is better for the parser to do it, as it can optimize better. This patch may cause breakage if policy declares either @{attach_path} or @{exec_path} this will not be dealt with here, but in a subsequent patch that allows variables to have a local scope so that the compiler defined vars will just get declared locally. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-04-20 16:34:51 -07:00
if [ "$(echo "profile t { /a r, /b w, /c a, /d l, /e k, /f m, audit deny /** w, }" | ${APPARMOR_PARSER} -M features_files/features.nopolicydb -QT -O minimize -O filter-deny -D dfa-states 2>&1 | grep -v '<==' | grep -c '^{.*}(.*)$')" -ne 5 ] ; then
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
echo "failed"
exit 1;
fi
echo "ok"
parser: minimization - remove unnecessary second minimization pass Moving apply_and_clear_deny() before the first minimization pass, which was necessary to propperly support building accept information for older none extended permission dfas, allows us to also get rid of doing a second minimization pass if we want to force clearing explicit deny info from extended permission tables. Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-05-10 03:06:22 -07:00
# ---------------------- extended perms ------------------------------
# Test that not filtering deny results in more states. This test is testing
# without filtering. The following test does the filtering
#
# {1} <== (allow/deny/prompt/audit/quiet)
# {3} (0x 0/2800a///0/0/0)
# {4} (0x 10004/2800a///0/0/0)
# {7} (0x 40010/2800a///0/0/0)
# {8} (0x 80020/2800a///0/0/0)
# {9} (0x 100040/2800a///0/0/0)
# {12} (0x 40030/0///0/0/0)
# {2} (0x 4/0//0/0/0) <- from policydb still showing up bug
## NOTE: change count from 6 to 7 when extend perms is not dependent on
## prompt rules being present
echo -n "Minimize profiles extended no-filter audit deny perms "
parser: Add support for automatic @{attach_path} variable Have the parser extract the attachment path from the profile declaration and make it available as a variable within the profile. This allows profile rules to use the executable attachment path in rules. eg. ``` profile ex /bin/** { @{attach_path} r, # ... } profile /path/to/bin { @{attach_path} r, # ... } ``` if a profile does not define an attachment like ``` profile noattach { @{attach_path} r, } ``` the apparmor_parser will fail the compile with the error. ``` Found reference to variable attach_path, but is never declared ``` The attachment xattr/label conditionals are not made available at this time as regular file path rules can not use them. Similarly a @{exec_path} variable is made available. It is different than @{attach_path} in that it is intended to be a kernel variable that represents the specific executable that was matched at run time. However to support policy on kernels that don't define the kernel variable it has a fallback value that is the same as @{attach_path}. This patch is a follow on to MR:1637 (https://gitlab.com/apparmor/apparmor/-/merge_requests/1637) and is similar to how the apparmor.d project uses the manually setup @{exec_path} variable. We can bike shed over the variable name. @{attach_path} was chosen here because this is the attachment conditional path for the executable, not the executable's actual path. While @{exec_path} is intended to be the applications actual executable path. support the @{exec_path} kernel variable (all of them atm). Notes: The minimize.sh tests are changed because this patch causes path based profile names to create an attachment. This could be done by doing the attach_variable expansion in the alternate location marked by the patch, but since the kernel is going to start doing this for all profiles that don't have an attachment it is better for the parser to do it, as it can optimize better. This patch may cause breakage if policy declares either @{attach_path} or @{exec_path} this will not be dealt with here, but in a subsequent patch that allows variables to have a local scope so that the compiler defined vars will just get declared locally. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-04-20 16:34:51 -07:00
if [ "$(echo "profile t { /a r, /b w, /c a, /d l, /e k, /f m, audit deny /** w, }" | ${APPARMOR_PARSER} -M features_files/features.extended-perms-no-policydb -QT -O minimize -O no-filter-deny -D dfa-states 2>&1 | grep -v '<==' | grep -c '^{.*}(.*)$')" -ne 7 ] ; then
parser: minimization - remove unnecessary second minimization pass Moving apply_and_clear_deny() before the first minimization pass, which was necessary to propperly support building accept information for older none extended permission dfas, allows us to also get rid of doing a second minimization pass if we want to force clearing explicit deny info from extended permission tables. Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-05-10 03:06:22 -07:00
echo "failed"
exit 1;
fi
echo "ok"
# same test as above except with filter-deny which should result in one less
# accept state
#
# {1} <== (allow/deny/prompt/audit/quiet)
# {4} (0x 10004/0///0/0/0)
# {7} (0x 40010/0///0/0/0)
# {8} (0x 80020/0///0/0/0)
# {9} (0x 100040/0///0/0/0)
# {12} (0x 40030/0///0/0/0)
# {2} (0x 4/0//0/0/0) <- from policydb still showing up bug
echo -n "Minimize profiles extended filter audit deny perms "
parser: Add support for automatic @{attach_path} variable Have the parser extract the attachment path from the profile declaration and make it available as a variable within the profile. This allows profile rules to use the executable attachment path in rules. eg. ``` profile ex /bin/** { @{attach_path} r, # ... } profile /path/to/bin { @{attach_path} r, # ... } ``` if a profile does not define an attachment like ``` profile noattach { @{attach_path} r, } ``` the apparmor_parser will fail the compile with the error. ``` Found reference to variable attach_path, but is never declared ``` The attachment xattr/label conditionals are not made available at this time as regular file path rules can not use them. Similarly a @{exec_path} variable is made available. It is different than @{attach_path} in that it is intended to be a kernel variable that represents the specific executable that was matched at run time. However to support policy on kernels that don't define the kernel variable it has a fallback value that is the same as @{attach_path}. This patch is a follow on to MR:1637 (https://gitlab.com/apparmor/apparmor/-/merge_requests/1637) and is similar to how the apparmor.d project uses the manually setup @{exec_path} variable. We can bike shed over the variable name. @{attach_path} was chosen here because this is the attachment conditional path for the executable, not the executable's actual path. While @{exec_path} is intended to be the applications actual executable path. support the @{exec_path} kernel variable (all of them atm). Notes: The minimize.sh tests are changed because this patch causes path based profile names to create an attachment. This could be done by doing the attach_variable expansion in the alternate location marked by the patch, but since the kernel is going to start doing this for all profiles that don't have an attachment it is better for the parser to do it, as it can optimize better. This patch may cause breakage if policy declares either @{attach_path} or @{exec_path} this will not be dealt with here, but in a subsequent patch that allows variables to have a local scope so that the compiler defined vars will just get declared locally. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-04-20 16:34:51 -07:00
if [ "$(echo "profile t { /a r, /b w, /c a, /d l, /e k, /f m, audit deny /** w, }" | ${APPARMOR_PARSER} -M features_files/features.extended-perms-no-policydb -QT -O minimize -O filter-deny -D dfa-states 2>&1 | grep -v '<==' | grep -c '^{.*}(.*)$')" -ne 6 ] ; then
parser: minimization - remove unnecessary second minimization pass Moving apply_and_clear_deny() before the first minimization pass, which was necessary to propperly support building accept information for older none extended permission dfas, allows us to also get rid of doing a second minimization pass if we want to force clearing explicit deny info from extended permission tables. Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-05-10 03:06:22 -07:00
echo "failed"
exit 1;
fi
echo "ok"
# ======================= x transition ===============================
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
# The x transition test profile is setup so that there are 3 conflicting x
# permissions, two are on paths that won't collide during dfa creation. The
treewide: spelling/typo fixes in comments and docs With the exception of the documentation fixes, these should all be invisible to users. Signed-off-by: Steve Beattie <steve.beattie@canonical.com> Acked-by: Christian Boltz <apparmor@cboltz.de> MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/687
2020-11-19 12:30:04 -08:00
# 3rd is a generic permission that should be overridden during dfa creation.
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
#
# This should result in a dfa that specifies transitions on 'a' and 'b' to
# unique states that store the alternate accept information. However
# minimization can remove the unique accept permission states if x permissions
# are treated as a single accept state.
#
# The minimized dump should retain the 'a' and 'b' transitions accept states.
# notice the below dump has 3 states with accept information {3}, {4}, {5}
#
# {1} <== (allow/deny/audit/quiet)
# {3} (0x 2914a45/0/0/0)
# {4} (0x 4115045/0/0/0)
# {5} (0x 2514945/0/0/0)
#
# A dump of minimization that is not respecting the uniqueness of the
# permissions on the states transitioned to by 'a' and 'b' looks like
# below. Notice that only state {3} has accept information
# {1} <== (allow/deny/audit/quiet)
# {3} (0x 2514945/0/0/0)
#
echo -n "Minimize profiles xtrans "
parser: Add support for automatic @{attach_path} variable Have the parser extract the attachment path from the profile declaration and make it available as a variable within the profile. This allows profile rules to use the executable attachment path in rules. eg. ``` profile ex /bin/** { @{attach_path} r, # ... } profile /path/to/bin { @{attach_path} r, # ... } ``` if a profile does not define an attachment like ``` profile noattach { @{attach_path} r, } ``` the apparmor_parser will fail the compile with the error. ``` Found reference to variable attach_path, but is never declared ``` The attachment xattr/label conditionals are not made available at this time as regular file path rules can not use them. Similarly a @{exec_path} variable is made available. It is different than @{attach_path} in that it is intended to be a kernel variable that represents the specific executable that was matched at run time. However to support policy on kernels that don't define the kernel variable it has a fallback value that is the same as @{attach_path}. This patch is a follow on to MR:1637 (https://gitlab.com/apparmor/apparmor/-/merge_requests/1637) and is similar to how the apparmor.d project uses the manually setup @{exec_path} variable. We can bike shed over the variable name. @{attach_path} was chosen here because this is the attachment conditional path for the executable, not the executable's actual path. While @{exec_path} is intended to be the applications actual executable path. support the @{exec_path} kernel variable (all of them atm). Notes: The minimize.sh tests are changed because this patch causes path based profile names to create an attachment. This could be done by doing the attach_variable expansion in the alternate location marked by the patch, but since the kernel is going to start doing this for all profiles that don't have an attachment it is better for the parser to do it, as it can optimize better. This patch may cause breakage if policy declares either @{attach_path} or @{exec_path} this will not be dealt with here, but in a subsequent patch that allows variables to have a local scope so that the compiler defined vars will just get declared locally. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-04-20 16:34:51 -07:00
if [ "$(echo "profile t { /b px, /* Pixr, /a Cx -> foo, }" | ${APPARMOR_PARSER} -M features_files/features.nopolicydb -QT -O minimize -D dfa-states 2>&1 | grep -v '<==' | grep -c '^{.*}(.*)$')" -ne 3 ] ; then
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
echo "failed"
exit 1;
fi
echo "ok"
# same test as above + audit
echo -n "Minimize profiles audit xtrans "
parser: Add support for automatic @{attach_path} variable Have the parser extract the attachment path from the profile declaration and make it available as a variable within the profile. This allows profile rules to use the executable attachment path in rules. eg. ``` profile ex /bin/** { @{attach_path} r, # ... } profile /path/to/bin { @{attach_path} r, # ... } ``` if a profile does not define an attachment like ``` profile noattach { @{attach_path} r, } ``` the apparmor_parser will fail the compile with the error. ``` Found reference to variable attach_path, but is never declared ``` The attachment xattr/label conditionals are not made available at this time as regular file path rules can not use them. Similarly a @{exec_path} variable is made available. It is different than @{attach_path} in that it is intended to be a kernel variable that represents the specific executable that was matched at run time. However to support policy on kernels that don't define the kernel variable it has a fallback value that is the same as @{attach_path}. This patch is a follow on to MR:1637 (https://gitlab.com/apparmor/apparmor/-/merge_requests/1637) and is similar to how the apparmor.d project uses the manually setup @{exec_path} variable. We can bike shed over the variable name. @{attach_path} was chosen here because this is the attachment conditional path for the executable, not the executable's actual path. While @{exec_path} is intended to be the applications actual executable path. support the @{exec_path} kernel variable (all of them atm). Notes: The minimize.sh tests are changed because this patch causes path based profile names to create an attachment. This could be done by doing the attach_variable expansion in the alternate location marked by the patch, but since the kernel is going to start doing this for all profiles that don't have an attachment it is better for the parser to do it, as it can optimize better. This patch may cause breakage if policy declares either @{attach_path} or @{exec_path} this will not be dealt with here, but in a subsequent patch that allows variables to have a local scope so that the compiler defined vars will just get declared locally. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-04-20 16:34:51 -07:00
if [ "$(echo "profile t { /b px, audit /* Pixr, /a Cx -> foo, }" | ${APPARMOR_PARSER} -M features_files/features.nopolicydb -QT -O minimize -D dfa-states 2>&1 | grep -v '<==' | grep -c '^{.*}(.*)$')" -ne 3 ] ; then
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
echo "failed"
exit 1;
fi
echo "ok"
# now try denying x and make sure perms are cleared
# notice that only deny and quiet information is being carried
# {1} <== (allow/deny/audit/quiet)
# {3} (0x 0/fe17f85/0/14005)
echo -n "Minimize profiles deny xtrans "
parser: Add support for automatic @{attach_path} variable Have the parser extract the attachment path from the profile declaration and make it available as a variable within the profile. This allows profile rules to use the executable attachment path in rules. eg. ``` profile ex /bin/** { @{attach_path} r, # ... } profile /path/to/bin { @{attach_path} r, # ... } ``` if a profile does not define an attachment like ``` profile noattach { @{attach_path} r, } ``` the apparmor_parser will fail the compile with the error. ``` Found reference to variable attach_path, but is never declared ``` The attachment xattr/label conditionals are not made available at this time as regular file path rules can not use them. Similarly a @{exec_path} variable is made available. It is different than @{attach_path} in that it is intended to be a kernel variable that represents the specific executable that was matched at run time. However to support policy on kernels that don't define the kernel variable it has a fallback value that is the same as @{attach_path}. This patch is a follow on to MR:1637 (https://gitlab.com/apparmor/apparmor/-/merge_requests/1637) and is similar to how the apparmor.d project uses the manually setup @{exec_path} variable. We can bike shed over the variable name. @{attach_path} was chosen here because this is the attachment conditional path for the executable, not the executable's actual path. While @{exec_path} is intended to be the applications actual executable path. support the @{exec_path} kernel variable (all of them atm). Notes: The minimize.sh tests are changed because this patch causes path based profile names to create an attachment. This could be done by doing the attach_variable expansion in the alternate location marked by the patch, but since the kernel is going to start doing this for all profiles that don't have an attachment it is better for the parser to do it, as it can optimize better. This patch may cause breakage if policy declares either @{attach_path} or @{exec_path} this will not be dealt with here, but in a subsequent patch that allows variables to have a local scope so that the compiler defined vars will just get declared locally. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-04-20 16:34:51 -07:00
if [ "$(echo "profile t { /b px, deny /* xr, /a Cx -> foo, }" | ${APPARMOR_PARSER} -M features_files/features.nopolicydb -QT -O minimize -D dfa-states 2>&1 | grep -v '<==' | grep -c '^{.*}(.*)$')" -ne 1 ] ; then
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
echo "failed"
exit 1;
fi
echo "ok"
# now try audit + denying x and make sure perms are cleared
treewide: spelling/typo fixes in comments and docs With the exception of the documentation fixes, these should all be invisible to users. Signed-off-by: Steve Beattie <steve.beattie@canonical.com> Acked-by: Christian Boltz <apparmor@cboltz.de> MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/687
2020-11-19 12:30:04 -08:00
# notice that the deny info is being carried, by an artificial trap state
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
# {1} <== (allow/deny/audit/quiet)
# {3} (0x 0/fe17f85/0/0)
echo -n "Minimize profiles audit deny xtrans "
parser: Add support for automatic @{attach_path} variable Have the parser extract the attachment path from the profile declaration and make it available as a variable within the profile. This allows profile rules to use the executable attachment path in rules. eg. ``` profile ex /bin/** { @{attach_path} r, # ... } profile /path/to/bin { @{attach_path} r, # ... } ``` if a profile does not define an attachment like ``` profile noattach { @{attach_path} r, } ``` the apparmor_parser will fail the compile with the error. ``` Found reference to variable attach_path, but is never declared ``` The attachment xattr/label conditionals are not made available at this time as regular file path rules can not use them. Similarly a @{exec_path} variable is made available. It is different than @{attach_path} in that it is intended to be a kernel variable that represents the specific executable that was matched at run time. However to support policy on kernels that don't define the kernel variable it has a fallback value that is the same as @{attach_path}. This patch is a follow on to MR:1637 (https://gitlab.com/apparmor/apparmor/-/merge_requests/1637) and is similar to how the apparmor.d project uses the manually setup @{exec_path} variable. We can bike shed over the variable name. @{attach_path} was chosen here because this is the attachment conditional path for the executable, not the executable's actual path. While @{exec_path} is intended to be the applications actual executable path. support the @{exec_path} kernel variable (all of them atm). Notes: The minimize.sh tests are changed because this patch causes path based profile names to create an attachment. This could be done by doing the attach_variable expansion in the alternate location marked by the patch, but since the kernel is going to start doing this for all profiles that don't have an attachment it is better for the parser to do it, as it can optimize better. This patch may cause breakage if policy declares either @{attach_path} or @{exec_path} this will not be dealt with here, but in a subsequent patch that allows variables to have a local scope so that the compiler defined vars will just get declared locally. Signed-off-by: John Johansen <john.johansen@canonical.com>
2025-04-20 16:34:51 -07:00
if [ "$(echo "profile t { /b px, audit deny /* xr, /a Cx -> foo, }" | ${APPARMOR_PARSER} -M features_files/features.nopolicydb -QT -O minimize -O no-filter-deny -D dfa-states 2>&1 | grep -v '<==' | grep -c '^{.*}(.*)$')" -ne 0 ] ; then
Fix dfa minimization to deal with exec conflicts Minimization was failing because it was too agressive. It was minimizing as if there was only 1 accept condition. This allowed it to remove more states but at the cost of loosing unique permission sets, they where being combined into single commulative perms. This means that audit, deny, xtrans, ... info on one path would be applied to all other paths that it was combined with during minimization. This means that we need to retain the unique accept states, not allowing them to be combined into a single state. To do this we put each unique permission set into its own partition at the start of minimization. The states within a partition have the same permissions and can be combined within the other states in the partition as the loss of unique path information is will not result in a conflict. This is similar to what perm hashing used to do but deny information is still being correctly applied and carried. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-By: Steve Beattie <sbeattie@ubuntu.com>
2012-03-09 04:20:19 -08:00
echo "failed"
exit 1;
fi
echo "ok"
Reference in New Issue Copy Permalink