Hello!
I run AppArmor daily on my personal machine and use `aa-notify` to receive alerts for any audit events. I wanted to submit two features and one bugfix for problems that I've seen while running `aa-notify`.
### Here are the two features in this merge request:
1. Allow `aa-notify` to run in the foreground.
I understand that `aa-notify` is ment to be run as a background notification daemon, however there are situations when running in the foreground would be better suited. One example is any startup "launcher" that creates and monitors it's child processes (my setup basically does this) and when `aa-notify` forks, the launcher percieves it as crashing on startup.
This merge request adds an option "-F"/"--foreground" to prevent background forking and perserves the default behavior, while allowing `aa-notify` to run like a standard foreground application. The test cases in `utils/test/test-aa-notify.py` are also updated to reflect the argument changes.
2. Prevent `aa-notify` from exiting with a fatal error when the AppArmor profiles directory cannot be read.
During startup, `aa-notify` will attempt to read the AppArmor profiles from the profile directory using the `aa.read_profiles` function. If this function fails due to a permissions check, `aa-notify` will exit with an error. In my setups, the standard user does not have any read access to the AppArmor profiles directory (reasoning: as an attacker, I could read the profiles to find something that would have the weakest permissions for explitation, but with that route blocked, this becomes significantly harder). In this merge request, an optional paramater `skip_perm_error` that is by-default False, is added to the `read_profiles` function call in `aa-notify`. In `aa.py`, this function has two added lines, which are under `except (OSError, TypeError):`. The extra code checks if `skip_perm_error` is True, and if so will print a warning out using the `aaui.UI_Info` function and returns cleanly. During my test cases, I have not run into any issues running `aa-notify` without reading any profiles.
### BugFixes
1. Crash during `aa-notify` polling during audit events that cause `rl.parse_record(event)` to return None
I've noticed certain events will cause `aa-notify` to crash, specifically the ones in the attached log snipped will cause `ev` to be `None`.
In this merge request, I've added a simple `if ev is None:` check before attempting to read from `ev`. If `ev` is None, it will fall into `continue` and prevent a crash from occuring. The crash log is also attached for additional information.
Please let me know if there's any additional questions or information you may need! And thank you for all your hard work on this project!
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1706
Approved-by: Maxime Bélair <maxime.belair@canonical.com>
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Christian Boltz <apparmor@cboltz.de>
After an upgrade to libfuse 3.17.1-rc0, autopkgtests started to fail
due to a missing x permission for /usr/bin/mount. After looking at the
source code for fusermount, I noticed that it does call /bin/mount and
/bin/umount in certain cases. These uses were already there in
previous versions of libfuse but I'm still not sure why it hasn't
triggered before.
To reproduce it:
sudo autopkgtest-buildvm-ubuntu-cloud -v -r questing
autopkgtest archivemount -U --apt-pocket=proposed=src:fuse3 --shell-fail -- qemu autopkgtest-questing-amd64.img
After the test fails, enter the vm by
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 10022 ubuntu@localhost
You can reproduce the test by running
cd /tmp/autopkgtest.*/build.*/src/
/tmp/autopkgtest.*/build.*/src/debian/tests/test
Note that ix for mount and umount were enough to make the autopkgtest
failures to start passing, but there could be issues in the future
regarding the use of fs specific mount binaries like
/usr/sbin/mount.fuse
Fixes: http://bugs.launchpad.net/bugs/2111845
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
@jjohansen had mentioned to me when he suggested this profile that there was smth he noticed about john that gave him the impression it was a good candidate for confinement. I think that would be the only thing I'd want to call out - wondering whether something like this captures that spirit or if there's something else worth including.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1662
Approved-by: Maxime Bélair <maxime.belair@canonical.com>
Merged-by: Maxime Bélair <maxime.belair@canonical.com>
This is a small improvement that makes sure lsusb is able to read some
properties of the virtual USB devices provisioned for the test.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
AppArmor profile for the lsusb binary, developed and tested on Ubuntu 22.04.
Signed-off-by: Federico Quattrin <federico.quattrin@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1433
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
... but don't get a new value assigned.
Found by pyflakes 3.3.2 / python 3.13.3
While on it, remove some obsolete, commented out debugging code.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1708
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
Otherwise tst_regex would log as being from parser_common.c instead of
being from the actual source of parser_regex.c
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1707
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
Parsing mount options (also) accepted partial matches as long as the
option started with the right characters. For example, 'options=syncfoo'
was parsed as 'sync'. This is also the reason why the list of mount
options was re-ordered so that 'r' and 'w' came last to give longer
options a chance to match (otherwise, 'rw' would be interpreted as 'r').
Fix parsing by adding a lookahead match so that the regex enforces that
the mount option is followed by whitespace, or is at the end of
rule_details.
Note that this issue only affected the options=foo syntax.
options=(foo) worked correctly even without this fix.
Now that this is fixed, move 'r' and 'w' back to their original position
in the list of mount options.
Also add a test where a mount rule ends with 'options=rw,' to ensure
that the '$' lookahead works.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1712
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: Georgia Garcia <georgia.garcia@canonical.com>
Parsing mount options (also) accepted partial matches as long as the
option started with the right characters. For example, 'options=syncfoo'
was parsed as 'sync'. This is also the reason why the list of mount
options was re-ordered so that 'r' and 'w' came last to give longer
options a chance to match (otherwise, 'rw' would be interpreted as 'r').
Fix parsing by adding a lookahead match so that the regex enforces that
the mount option is followed by whitespace, or is at the end of
rule_details.
Note that this issue only affected the options=foo syntax.
options=(foo) worked correctly even without this fix.
Now that this is fixed, move 'r' and 'w' back to their original position
in the list of mount options.
Also add a test where a mount rule ends with 'options=rw,' to ensure
that the '$' lookahead works.
Parsing `mount options=x` results in "Passed unknown options keyword to
MountRule: x", while parsing `mount options=xy` results in "Can't parse mount rule".
This difference happens because the code checks (besides the list of
known options) for a regex `([A-Za-z0-9])` which only matched a
single-character unknown option.
Change that regex to also match multiple characters, and also allow to
match `-` (used in some known mount options, so it's likely that it also
gets used in so far unknown mount options)
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1710
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: Georgia Garcia <georgia.garcia@canonical.com>
The whole pattern already has `(...)*`, therefore there's no need to
make option_pattern optional.
Before this change, mount_condition_pattern could have matched
- on empty strings (it still can, thanks to the trailing `*` which can
also mean "zero matches") or
- whitespace-only strings (which is covered by the two regexes using
mount_condition_pattern - they both have `\s*` and/or `\s+` around it)
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1709
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: Christian Boltz <apparmor@cboltz.de>
Parsing `mount options=x` results in "Passed unknown options keyword to
MountRule: x", while parsing `mount options=xy` results in "Can't parse mount rule".
This difference happens because the code checks (besides the list of
known options) for a regex `([A-Za-z0-9])` which only matched a
single-character unknown option.
Change that regex to also match multiple characters, and also allow to
match `-` (used in some known mount options, so it's likely that it also
gets used in so far unknown mount options)
The whole pattern already has `(...)*`, therefore there's no need to
make option_pattern optional.
Before this change, mount_condition_pattern could have matched
- on empty strings (it still can, thanks to the trailing `*` which can
also mean "zero matches") or
- whitespace-only strings (which is covered by the two regexes using
mount_condition_pattern - they both have `\s*` and/or `\s+` around it)
Otherwise tst_regex would log as being from parser_common.c instead of
being from the actual source of parser_regex.c
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
The hwctl profile is being carried upstream, so we can keep it in
sync, but is being packaged from the regular profile set so that it
can be part of a package that is SRUed (ubuntu stable release update)
separate from the rest of apparmor, and its profiles.
Provide backwards compat with older parser to reduce the amount of
distro patching that is needed.
Signed-off-by: John Johansen <john.johansen@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1705
Approved-by: Maxime Bélair <maxime.belair@canonical.com>
Merged-by: John Johansen <john@jjmx.net>
