Kernel to userspace communication is needed to notify trusted helpers of profile changes
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| AppArmor |
Triaged
|
Low
|
Unassigned | ||
| apparmor (Ubuntu) |
Triaged
|
Low
|
Unassigned | ||
| dbus (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
| linux (Ubuntu) |
Triaged
|
Low
|
Unassigned | ||
Bug Description
It is common for trusted helpers to cache information about a profile, such as the profile name and enforcement mode, when they're making AppArmor policy decisions. However, there's currently no way for the trusted helper to receive notification when changes are made to the profile.
For example, dbus-daemon caches the profile name and enforcement mode when an application connects to the bus. If the profile is in enforce mode when the application connects but the system administrator moves the profile to complain mode, dbus-daemon does not find out about the change and continues to enforce the profile.
The opposite is true, as well. If a profile is in complain mode when an application connects to the bus and is then moved to enforce mode, dbus-daemon continues to treat the profile as if it were in complain mode until the application reconnects to the bus.
To solve this, there are two options that immediately come to mind:
1. dbus-daemon checks with the kernel before every permission query. It would get the latest profile information and then decide what to do (query and enforce if the profile is in enforce mode, query and allow if in complain mode, don't query if unconfined). This results in an extra round trip per query and would hurt performance.
2. The kernel could notify trusted helpers when profile changes are made, such as when an enforcement mode changes, a new profile is loaded, a profile is removed, a profile is renamed, etc. Userspace would need to be able to receive the notification and invalidate its cached information for that profile. This could become complicated in some trusted helper implementations.
| Tyler Hicks (tyhicks) wrote | #1 |
| Changed in apparmor: | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
| tags: | added: aa-feature |
| Changed in apparmor (Ubuntu): | |
| importance: | Medium → Low |
| Changed in apparmor: | |
| importance: | Medium → Low |
| Changed in linux (Ubuntu): | |
| status: | New → Triaged |
| importance: | Undecided → Low |
| tags: | added: aa-kernel |
A potential dbus specific solution could be to leverage the SIGHUP handling in dbus-daemon. It is typically for reloading configuration files, but it might provide a nice way for an admin to force a refresh of the confinement contexts across all of the active connections.