Bug 96720 - AppArmor mode not reloaded until a process reconnects
Summary: AppArmor mode not reloaded until a process reconnects
Status: RESOLVED MOVED
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: 1.10
Hardware: Other All
: medium normal
Assignee: D-Bus Maintainers
QA Contact: D-Bus Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-29 10:42 UTC by Philip Withnall
Modified: 2018-10-12 21:28 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Philip Withnall 2016-06-29 10:42:21 UTC
• I have a process (A) running in enforce mode under AppArmor, and connected to dbus-daemon
 • Process B is also running in enforce mode, and the profile for process A does not allow incoming method calls from process B (but doesn’t deny them either)
 • Process B tries to call a method on process A — this is correctly rejected by dbus-daemon
 • I call `sudo aa-complain /path/to/process/A` to switch process A to complain mode, which instantly affects all AppArmor decisions made on the syscall boundary for it
 • Process B should now be able to call methods on process A, but they are still denied
 • If I restart process A, process B //can// now call methods on it

So it seems like the AppArmor mode for a connection to dbus-daemon is being cached and not updated when it changes in the kernel.

dbus version 1.10.8 on an Ubuntu derivative.
Comment 1 Simon McVittie 2016-06-30 13:28:55 UTC
(In reply to Philip Withnall from comment #0)
> So it seems like the AppArmor mode for a connection to dbus-daemon is being
> cached and not updated when it changes in the kernel.

I don't know whether we *can* update this. In the kernel, the peer credentials are stashed in the socket structure at connect() time (if they were not, we'd be vulnerable to attacks similar to the one described in Bug #83499). So whether we can do anything about this depends on whether the struct aa_profile is altered in-place, or whether an up-to-date struct aa_profile is used for new sockets only. The kernel -> user-space interface is to take the LSM-specific void * (in AppArmor's case it's a struct aa_profile *) and turn it into a string that usually looks like "/usr/bin/foo (complain)".

We would also need to be able to learn from the kernel that a profile's enforcement mode has been altered, so that we could fetch the new SO_PEERSEC for each connection.

It seems that the process's /proc/$pid/attr/current does change when the profile's enforcement mode is changed:

% cat /proc/27475/attr/current
/usr/sbin/avahi-daemon (complain)
% sudo aa-enforce /usr/sbin/avahi-daemon
% cat /proc/27475/attr/current
/usr/sbin/avahi-daemon (enforce)
% sudo aa-complain /usr/sbin/avahi-daemon
% cat /proc/27475/attr/current
/usr/sbin/avahi-daemon (complain)

so maybe this is possible?
Comment 2 GitLab Migration User 2018-10-12 21:28:30 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/151.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.