Profiles are now updated only at initialization and when aa-notify
itself updates a profile.
A future MR will come to read profiles individually only when an event
for this profile comes to reduce overhead, as more and more profiles are
created.
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
Many test provide their own implementation of cmd(). This commit makes
all of them rely on common.py implementation of cmd()
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
Snap policy is a special case of the unknown profile. Give the user
a slightly better message for these messages.
Signed-off-by: John Johansen <john.johansen@canonical.com>
The current notification can be confusing, in that it can present a
profile followed by a list of rules that can't be selected.
Explictly state that the Unknown profile can't be modified so the user
has some indication that not being able to select the shown rules is
expected.
Signed-off-by: John Johansen <john.johansen@canonical.com>
--configdir is meant for testing and should override all other configs,
instead of being combined with them. Config combination causes aa-notify
test failures if e.g. the user-local config sets filtering options.
Also supply a notify.conf file for exclusive use during testing.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1610
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: John Johansen <john@jjmx.net>
--configdir is meant for testing and should override all other configs,
instead of being combined with them. Config combination causes aa-notify
test failures if e.g. the user-local config sets filtering options.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
Both the unconfined profile and unprivileged_userns are part of the
default notify.conf, so the default fallback when no configurations are
present should also match this default.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
It is now possible to select individual rules to allow through an
improved GUI (ShowMoreGUIAggregated).
This commit also simplifies codebase thanks to new classes ProfileRules
and SelectableRules.
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1444
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
Precompile each filter regex with re.compile so they don't need to be
recompiled for each log message when using re.match directly.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Allow notification filtering of the fields profile, operation, name,
denied_mask, net_family and net_socket using regex. Both command line
and config options in notify.conf are available.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Update (most of the) code and inline comments/docstrings to follow
https://peps.python.org/pep-0008/ so that future maintenance is slightly
easier.
Continue to keep long lines as splitting them does not always improve
the code readability.
Some STATUS log events trigger a crash in aa-notify because the log
line doesn't have operation=. Examples are:
type=AVC msg=audit(1630913351.586:4): apparmor="STATUS" info="AppArmor Filesystem Enabled" pid=1 comm="swapper/0"
type=AVC msg=audit(1630913352.610:6): apparmor="STATUS" info="AppArmor sha1 policy hashing enabled" pid=1 comm="swapper/0"
Fix this by not looking at log events without operation=
Also add one of the example events as libapparmor testcase.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/194
Fix spelling errors in code strings. Some strings are translatable.
This fixes are potentially user visible.
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
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
If aa-notify races file rotation it may crash with a trace back to
the log file being removed before the new one is moved into place.
Traceback (most recent call last):
File "/usr/sbin/aa-notify", line 570, in <module>
main()
File "/usr/sbin/aa-notify", line 533, in main
for message in notify_about_new_entries(logfile, args.wait):
File "/usr/sbin/aa-notify", line 145, in notify_about_new_entries
for event in follow_apparmor_events(logfile, wait):
File "/usr/sbin/aa-notify", line 236, in follow_apparmor_events
if os.stat(logfile).st_ino != log_inode:
FileNotFoundError: [Errno 2] No such file or directory: '/var/log/audit/audit.log'
If we hit this situation sleep and then retry opening the logfile.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/130
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/688
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Christian Boltz <apparmor@cboltz.de>
Since this option is mostly meant for testing, it will not show up in
--help.
aa-notify was the only tool that honored the __AA_CONFDIR env variable.
It still does if --configdir is not given.
Note: Since we now pass confdir= to init_aa() (in most cases None),
setting the default needs to be moved inside the function.
When run with the -p flag, aa-notify works fine for 100 seconds and then it exits.
I suspect that the issue arises from the following check on line 259 in utils/aa-notify
if debug_logger.debug_level <= 10 and int(time.time()) - start_time > 100:
debug_logger.debug('Debug mode detected: aborting notification emitter after 100 seconds.')
sys.exit(0)
together with line 301 in utils/apparmor/common.py which initializes debug_logger.debug_level to logging.DEBUG which has the numerical value 10.
A simple solution might be to just remove the check as I'm not quit sure why one would want aa-notify to exit when run in debug mode in the first place.
Alternatively, one could check against debug_logger.debugging (initialized to False) or change the initialization of debug_logger.debug_level to something else, but I don't know how that would affect other consumers of utils/apparmor/common.py.
For now just add dbugger_logger.debugging as an additional check as the
reason for timing out after 100s during debugging are unclear.
Suggested-by: vicvbcun
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/126
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/660
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Otto Kekäläinen <otto@kekalainen.net>
aa-notify does not need to load the policy includes for its current
features, so drop the unneeded overhead.
Signed-off-by: John Johansen <john.johansen@canonical.com>
- Code layout based on aa-genprof example
- Extend Python dependencies to cover new need by aa-notify
- Update documentation after aa-notify is no longer in Perl
Legacy path ~/.apparmor/notify.conf is preferred if it exists, otherwise
$XDG_CONFIG_HOME/apparmor/notify.conf, with fallback to
~/.config/apparmor/notify.conf, is used.
Signed-off-by: nl6720 <nl6720@gmail.com>
This is needed by new versions of notify-send, as found on openSUSE
Tumbleweed. Without this, desktop notifications don't work anymore, and
notify-send starts to eat up CPU.
If DBUS_SESSION_BUS_ADDRESS is already set, it won't be changed.
critical urgency notifications result in a notification that must be explictly
clicked to dismiss (ie, they don't time out) and gnome-shell does not honor --
expire-time with (at least) critical urgency. In other popular DEs critical
urgency notifications time out. This patch updates the urgency to 'normal' to
obtain intended behavior across DEs.
Signed-off-by: Jamie Strandboge <jamie@canonical.com>
Acked-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Christian Boltz <apparmor@cboltz.de>
Change aa-notify parse_message() to also honor complain mode log events.
This affects both modes - desktop notifications and the summary report.
Acked-by: Steve Beattie <steve@nxnw.org>
If $DISPLAY is not set and --display is not used, aa-notify prints a
warning that notifications won't be shown (exact warning text depends if
using sudo or not).
Acked-by: John Johansen <john.johansen@canonical.com>
