Describe the Issue
Control 1.6.1.3 mandates to Ensure all AppArmor Profiles are in enforce or complain mode.
However, the corresponding task only allows the role to set every profile to enforce mode --
the existing toggle in defaults/main.yml disables the tasks rather than switching between
enforce and complain mode.
Fixing this is made more complicated by the fact that Controls 1.6.1.3 and 1.6.1.4 target the same setting.
If Control 1.6.1.3 is configured to set complain, then it is weaker than 1.6.1.4. If it is set to enforce, then
it is actually equal.
What if 1.6.1.3 is set to complain and both rules are present, because the role is run with -t level1-server -t level2-server (which is what you must do in order to implement all controls required for level-2-compliance?
Then both 1.6.1.3 and 1.6.1.4 are executed. Rule 1.6.1.4 overwrite the setting of 1.6.1.3, so that is OK, I guess, but still, we targetting the same setting two times with different values.
The solution is to change the order: have 1.6.1.4 be executed first and set a flag that it has run, which is then examined by 1.6.1.3 -- if 1.6.1.4 has run, then 1.6.1.3 is skipped.
Expected Behavior
Change the implementation such that complain or enforce mode can be chosen for 1.6.1.3 and it is ensured that 1.6.1.3 and 1.6.1.4 are not carried out in the same run.
Actual Behavior
See above
Control(s) Affected
1.6.1.3, 1.6.1.4
Environment (please complete the following information):
Describe the Issue Control 1.6.1.3 mandates to
Ensure all AppArmor Profiles are in enforce or complain mode
. However, the corresponding task only allows the role to set every profile toenforce
mode -- the existing toggle indefaults/main.yml
disables the tasks rather than switching betweenenforce
andcomplain
mode.Fixing this is made more complicated by the fact that Controls 1.6.1.3 and 1.6.1.4 target the same setting. If Control 1.6.1.3 is configured to set
complain
, then it is weaker than 1.6.1.4. If it is set toenforce
, then it is actually equal.What if 1.6.1.3 is set to
complain
and both rules are present, because the role is run with-t level1-server -t level2-server
(which is what you must do in order to implement all controls required for level-2-compliance?Then both 1.6.1.3 and 1.6.1.4 are executed. Rule 1.6.1.4 overwrite the setting of 1.6.1.3, so that is OK, I guess, but still, we targetting the same setting two times with different values.
The solution is to change the order: have 1.6.1.4 be executed first and set a flag that it has run, which is then examined by 1.6.1.3 -- if 1.6.1.4 has run, then 1.6.1.3 is skipped.
Expected Behavior Change the implementation such that complain or enforce mode can be chosen for 1.6.1.3 and it is ensured that 1.6.1.3 and 1.6.1.4 are not carried out in the same run.
Actual Behavior See above
Control(s) Affected 1.6.1.3, 1.6.1.4
Environment (please complete the following information):
Possible Solution I will provide a pull request.