No need to assign a variable to itsself, not even conditionally.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1442
Approved-by: Ryan Lee <rlee287@yahoo.com>
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: Georgia Garcia <georgia.garcia@canonical.com>
This check is intended for ensuring that the profiles file can actually
be opened. The *actual* check is performed by the shell, not the read
utility, which won't even be executed if the input redirection (and
hence the test) fails.
If the test succeeds, though, using `read` here might actually
jeopardize the test result if there are no profiles loaded and the file
is empty.
This commit fixes that case by simply using `true` instead of `read`.
The new flag --merge-notifications enables the merging of all
notifications from a fixed time period into a single one, thus
preventing notification flooding.
A new GUI allows users to choose either a synthetic or a comprehensive
view of the notifications.
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1324
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Georgia Garcia <georgia.garcia@canonical.com>
This fixes an error with Python 3.11:
```
test/test-parser-simple-tests.py:420:21: E502 the backslash is redundant between brackets
```
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Builds for risc64 are much slower than on other architectures (4-5
seconds with qemu-user or on Litchi Pi 4A).
Since the timeout is only meant as a safety net, increase it generously,
and hopefully for the last time.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/463
We use ProfileStorage everywhere, which makes checking if a specific
rule_type exists obsolete.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1405
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
I don't know when (or even: if) this function was in use. A quick look
at the git history of aa.py shows that the function was (blindly?)
updated a few times. However, I didn't find a commit that uses or stops
using profile_exists(), so maybe it was never used at all.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1404
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
I don't know when (or even: if) this function was in use. A quick look
at the git history of aa.py shows that the function was (blindly?)
updated a few times. However, I didn't find a commit that uses or stops
using profile_exists(), so maybe it was never used at all.
If a user specifies a non-existing file to merge into the profiles
(`aa-mergeprof /file/not/found`), this results in a backtrace showing an
AppArmorBug because that file unsurprisingly doesn't end up in the
active_profiles filelist.
Handle this more gracefully by adding a read_error_fatal parameter to
read_profile() that, if set, forwards the exception. With that,
aa-mergeprof doesn't try to list the profiles in this non-existing file.
Note that all other callers of read_profile() continue to ignore read
errors, because aborting just because a single file in /etc/apparmor.d/
(for example a broken symlink) isn't readable would be a bad idea.
Instead of always storing the name of the main profile, store the child
profile/hat name if we are in a child profile or hat.
As a result, we always get the correct "profile xy" header even for
child profiles when dumping the ProfileStorage object.
Also extend the tests to check that the name gets stored correctly.
.
Add aa-complain tests for profile with hats and subprofiles
So far, change_profile_flags() in aa.py is the only user of
ProfileStorage's 'name'.
Rewrite minitools test_cleanprof() so that most of its code can be
reused, and add a test that runs 'aa-complain
/usr/bin/a/simple/cleanprof/test/profile' on cleanprof.in to ensure
aa-complain still works as expected on subprofiles and hats.
Note: aa-complain $profilename will change the flags of hats, but not
child profiles. This is a known issue, and doesn't change with this MR.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1359
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
... which only existed for historical reasons
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1389
Approved-by: Ryan Lee <rlee287@yahoo.com>
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: Georgia Garcia <georgia.garcia@canonical.com>
Several fixes for test-libapparmor-test_multi.py and the expected profiles. The most important fix is that testing exec events/rules now works.
Please check the individual commits for details and readable diffs.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1390
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: Georgia Garcia <georgia.garcia@canonical.com>
'testcase01', 'testcase12' and 'testcase13' contain a strange mix of
exec and network events.
Nevertheless, there's enough information to parse them as good-enough
exec events. While this is not perfectly correct, it's better than
skipping these logs in this test.
Stop expecting that these profiles have a wrong content, and adjust them
so that they contain the (somewhat) expected exec rule.
So far, exec events were accidentally skipped in
test-libapparmor-test_multi.py because aa[profile][hat] was not
initialized, and ask_exec() exited early because of this.
Initialize aa[profile][hat] in the test to fix this.
To avoid that someone needs to select "inherit" each time the tests run,
add an optional default_ans parameter to ask_exec(), and let the test
call it with 'CMD_ix'.
(In case you wonder - defaulting to CMD_cx would ask to sanitize the
environment. CMD_ix avoids this.)
Also, we have to copy over aa[profile][hat] to log_dict in the test
because ask_exec() modifies aa[...], but the test only checks its local
log_dict.
Finally, add the expected exec rules to the *.profile files
It is handled correctly in the current codebase.
It would be even better if it would generate a link rule that includes
the source, but let's leave that for a later fix.
confirm_and_abort() is unused (note that a function with the same name
exists in ui.py and is used there)
Also delete the now-unused delete_profile() - luckily it was never used,
because it would also have deleted profiles that were "just" modified.
When a log like system.journal is passed on to aa-genprof, for
example, the user receives a TypeError exception: in method
'parse_record', argument 1 of type 'char *'
This patch catches that exception and displays a more meaningful
message.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/436
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
So far, change_profile_flags() in aa.py is the only user of
ProfileStorage's 'name'.
Rewrite minitools test_cleanprof() so that most of its code can be
reused, and add a test that runs 'aa-complain
/usr/bin/a/simple/cleanprof/test/profile' on cleanprof.in to ensure
aa-complain still works as expected on subprofiles and hats.
Note: aa-complain $profilename will change the flags of hats, but not
child profiles. This is a known issue, and doesn't change with this MR.
Instead of always storing the name of the main profile, store the child
profile/hat name if we are in a child profile or hat.
As a result, we always get the correct "profile xy" header even for
child profiles when dumping the ProfileStorage object.
Also extend the tests to check that the name gets stored correctly.
When both the owner and file keywords were used, the clean rule
generated would have owner after file which is not accepted by the
parser.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/430
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
When the profile already contains a "file" rule containing the owner
prefix and the tool is trying to handle a new file entry, it tries to
show it in the logprof header as "old mode".
The issue is that when the owner rule is an implicit all files
permission, then the object "FileRule" is used instead of the set of
permissions. When subtracting FileRule from set() a TypeError
exception is thrown.
Fix this by "translating" FileRule.ALL perms to "mrwlkix".
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/429
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Followup to !1315 that updates apparmor-utils.pot. The other ones should also be updated at some point, so I'm marking this as a draft until we have a better idea of when/how we want to do that.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1316
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
utils: ignore peer when parsing logs for non-peer access modes
Some access modes (create, setopt, getopt, bind, shutdown, listen,
getattr, setattr) cannot be used with a peer in network rules.
Due to how auditing is implemented in the kernel, the peer information
might be available in the log (as faddr= but not daddr=), which causes
a failure in log parsing.
When parsing the log, check if that's the case and ignore the peer,
avoiding the exception on the NetworkRule constructor.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/427
Reported-by: Evan Caville <evan.caville@canonical.com>
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Closes#427
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1314
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: John Johansen <john@jjmx.net>
Some access modes (create, setopt, getopt, bind, shutdown, listen,
getattr, setattr) cannot be used with a peer in network rules.
Due to how auditing is implemented in the kernel, the peer information
might be available in the log (as faddr= but not daddr=), which causes
a failure in log parsing.
When parsing the log, check if that's the case and ignore the peer,
avoiding the exception on the NetworkRule constructor.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/427
Reported-by: Evan Caville <evan.caville@canonical.com>
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
This enables adding a priority to a rules in policy, finishing out the
priority work done to plumb priority support through the internals in
the previous patch.
Rules have a default priority of 0. The priority prefix can be added
before the other currently support rule prefixes, ie.
[priority prefix][audit qualifier][rule mode][owner]
If present a numerical priority can be assigned to the rule, where the
greater the number the higher the priority. Eg.
priority=1 audit file r /etc/passwd,
priority=-1 deny file w /etc/**,
Rule priority allows the rule with the highest priority to completely
override lower priority rules where they overlap. Within a given
priority level rules will accumulate in standard apparmor fashion.
Eg. given
priority=1 w /*c,
priority=0 r /a*,
priority=-1 k /*b*,
/abc, /bc, /ac .. will have permissions of w
/ab, /abb, /aaa, .. will have permissions of r
/b, /bcb, /bab, .. will have permissions of k
User specified rule priorities are currently capped at the arbitrary
values of 1000, and -1000.
Notes:
* not all rule types support the priority prefix. Rukes like
- network
- capability
- rlimits need to be reworked
need to be reworked to properly preserve the policy rule structure.
* this patch does not support priority on rule blocks
* this patch does not support using a variable in the priority value.
Signed-off-by: John Johansen <john.johansen@canonical.com>
I couldn't figure out why the show info window was using a different
font color than the theme default but this forces its use.
Also, add padding when "Show Current Profile" button is not shown.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
