Kernel to userspace communication is needed to notify trusted helpers of profile changes

Bug #1306781 reported by Tyler Hicks on 2014-04-11
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AppArmor
Low
Unassigned
apparmor (Ubuntu)
Low
Unassigned
dbus (Ubuntu)
Undecided
Unassigned
linux (Ubuntu)
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 :

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.

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
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers