** Description changed:

  1) Ubuntu 26.04
  2) 5.0.2-0ubuntu1~26.04.1
- 3) Add a system-tray indicator for AppArmor that surfaces security-relevant 
events (new crontab entries, reverse-shell patterns, profile violations) with 
allow/block actions and a protected alert log.
+ 3) Add a system-tray security indicator for AppArmor that surfaces critical 
events and requires explicit user approval for persistence mechanisms (crontab, 
systemd user units, XDG autostart, etc.).
  Summary
- Provide a persistent system-tray icon for AppArmor that notifies users of 
important security events in real time. The icon would display a chronological 
log of alerts, offer per-event Allow/Block (or “add exception”) actions, and 
restrict log-clearing to superuser (or a polkit-authorized user). This closes 
the current visibility gap where AppArmor denials and related system changes 
(crontab modifications, unexpected network listeners) are largely silent to the 
average desktop user.
+ Introduce a persistent system-tray icon for AppArmor that provides real-time 
visibility into security-relevant events and acts as a controlled approval 
gateway for common persistence techniques.
+ The indicator would:
+ •  Display notifications and a chronological alert log for AppArmor denials, 
new crontab entries, reverse-shell patterns, and similar events.
+ •  Offer per-alert Allow / Block (or “add exception”) actions.
+ •  Restrict creation or modification of persistence mechanisms so that they 
succeed only after explicit user approval through the tray interface.
+ •  Allow only a superuser (or polkit-authorized user) to clear the alert log 
or permanently silence alert classes.
+ This turns the tray from a passive notifier into a lightweight policy 
enforcement point for one of the most important attacker goals: surviving 
reboots.
  Problem / Motivation
- AppArmor currently logs denials to the audit/journal subsystem, but most 
users never see them. Malware or a compromised process can:
- •  Silently add or modify crontab entries
- •  Spawn a reverse shell
- •  Trigger profile violations that look like privilege-escalation attempts
- …with little or no interactive feedback. Existing tools such as aa-notify 
only produce transient desktop notifications and lack a persistent indicator, 
historical log view, or interactive allow/block workflow. Application firewalls 
like OpenSnitch provide a tray experience, but they focus on network 
connections rather than AppArmor profiles or local system-integrity events.
- A tray icon with actionable alerts would bring AppArmor closer to the 
usability of modern endpoint-protection tools while remaining true to its 
mandatory-access-control model.
+ AppArmor currently logs denials largely out of sight of desktop users. At the 
same time, common persistence vectors (crontab, systemd user units, XDG 
autostart entries, etc.) can be modified silently by any process running as the 
user.
+ Malware that has achieved user-level code execution can therefore:
+ •  Add a crontab entry or systemd timer,
+ •  Drop an autostart .desktop file,
+ •  Or trigger profile violations that look like privilege-escalation attempts,
+ with little or no interactive feedback. Existing tools such as aa-notify 
produce only transient notifications and provide no interactive approval 
workflow or historical log protected from tampering.
+ A tray-based indicator that both surfaces these events and gates persistence 
behind explicit user consent closes that gap while remaining compatible with 
AppArmor’s mandatory-access-control model.
  Proposed Solution
- 1.  Tray icon states
-       •  Quiet / green
-       •  Pending alerts / yellow
-       •  Critical events (reverse shell, unexpected crontab change, 
high-severity denial) / red
- 2.  Event sources (monitored by a privileged helper)
-       •  AppArmor audit/denial events
-       •  Changes to system and user crontabs (/etc/crontab, /var/spool/cron/, 
etc.)
-       •  Suspicious process behavior suggestive of reverse shells (new 
listening sockets, unexpected outbound connections from interpreters, etc.)
-       •  Profile load/unload or mode-change events
- 3.  User interface
-       •  Click the icon → chronological list of recent alerts
-       •  Per-alert actions: Allow (temporary or permanent exception), Block, 
View related profile, Open journal entry
-       •  Only a superuser (or a user granted a specific polkit privilege) may 
clear the log or permanently silence an alert class
- 4.  Security requirements
-       •  Tray applet runs as the logged-in user
-       •  Decision engine, log storage, and clearing operations run in a 
privileged helper (polkit-activated service or capability-restricted binary)
-       •  Alert log is append-only and integrity-protected so an attacker 
cannot erase their own traces
+ 1. Tray icon & alert surface
+ •  Icon states: quiet/green, pending alerts/yellow, critical events/red.
+ •  Click opens a chronological log of alerts.
+ •  Each alert offers: Allow (once or permanently), Block & revert, View 
related profile / journal entry.
+ •  Only root or a polkit-authorized user may clear the log or silence an 
alert class.
+ 2. Event sources (privileged monitoring daemon)
+ •  AppArmor audit/denial events.
+ •  Changes to system and user crontabs.
+ •  Creation or modification of systemd user units/timers.
+ •  New or changed XDG autostart .desktop files.
+ •  Heuristics for reverse-shell behavior (unexpected listeners, suspicious 
interpreter network activity, etc.).
+ •  Profile load/unload or mode-change events.
+ 3. Gated persistence (core new requirement)
+ Persistence mechanisms are no longer freely writable by user processes.
+ When a monitored location is modified:
+ 1.  The privileged daemon detects the change.
+ 2.  The change is held in a pending state (or automatically reverted).
+ 3.  The tray icon surfaces a high-severity alert describing the exact change, 
the responsible process, and the command or unit content.
+ 4.  Only after the user explicitly clicks Allow does the daemon commit the 
change (or mark it as trusted).
+ 5.  Block & revert restores the previous state and may install a temporary or 
permanent block rule.
+ Unapproved persistence attempts remain visible in the protected log and can 
be configured to re-alert on next login or timer trigger.
+ 4. Privilege separation & hardening
+ •  Tray applet runs as the logged-in user and speaks to the daemon over D-Bus.
+ •  All detection, decision enforcement, log storage, and revert actions are 
performed by a privileged helper (systemd service + polkit).
+ •  Alert log is root-owned and append-only so an attacker cannot erase 
history by killing the tray.
+ •  The monitoring daemon itself is protected by a strong AppArmor profile, 
systemd sandboxing (ProtectSystem=, ProtectHome=, capability bounding, etc.), 
and optional eBPF/audit rules.
  Benefits
- •  Dramatically improves user awareness of AppArmor activity
- •  Enables quick, informed decisions (allow legitimate new behavior or block 
suspicious activity)
- •  Makes crontab and reverse-shell detection visible without requiring users 
to read journalctl
- •  Complements existing tools (aa-notify, OpenSnitch, auditd) rather than 
replacing them
- •  Encourages broader adoption of AppArmor on desktop systems by reducing its 
“silent” character
- Possible Implementation Notes
- •  Extend or re-use the existing aa-notify infrastructure
- •  Prefer a D-Bus interface between a privileged daemon and a lightweight 
Qt/GTK tray applet
- •  Use inotify for crontab directories and eBPF/audit rules for 
process/network heuristics
- •  Ship as an optional package (e.g. apparmor-notify-tray) so distributions 
can decide default enablement
+ •  Users gain immediate visibility into AppArmor activity and persistence 
attempts.
+ •  Malware seeking persistence is forced either to interact with the user 
(high detection probability) or to use rarer, unmonitored techniques.
+ •  Creates an auditable record of every persistence decision.
+ •  Complements existing tools (aa-notify, OpenSnitch, auditd) rather than 
replacing them.
+ •  Keeps the trusted computing base small: the tray is only a UI front-end; 
the real security logic stays in the hardened daemon.
  4) No AppArmor system tray icon.

** Summary changed:

- Feature Request: AppArmor System Tray Icon with Security Notifications
+ Feature Request: AppArmor System Tray Indicator with Gated Persistence 
Approval

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2170303

Title:
  Feature Request: AppArmor System Tray Indicator with Gated Persistence
  Approval

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2170303/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to