AppArmor cache entries not removed when profile is deleted

[Daniel Richard G.]

This concerns apparmor 2.13.3-7ubuntu5 in Ubuntu focal.

If I delete a profile from /etc/apparmor.d/, reboot the system, and then look in /var/cache/apparmor/XXXXXXXX.0/, I still see a file for the compiled form of the profile.

The same occurs if the profile is "deleted" by other means, such as symlinking it from /etc/apparmor.d/disable/.

This behavior caused me some consternation as I was developing an alternate profile for a program that already had one, and I continued to see old behavior even though I had removed the old profile.

[John Johansen (jjohansen)]

Daniel,

Currently it is expected that manually deleting a profile also requires manual profile removal from the kernel, using an of
- aa-remove-unknown
- apparmor_parser -R <profile before file deletion>
- sudo bash -c "echo -n '<profile_name>' > /sys/kernel/security/apparmor/.remove"

However this does indeed currently leave behind the cache file, cluttering the file system. However once the profile is removed from the kernel the cached file should not be applied.

Can you clarify whether you removed the profile from the kernel?

Can you clarify if when you were developing the new profile whether you changed the filename from the original profile to a different filename when developing the new profile?

[Daniel Richard G. (skunk)]

Hello John,

I did not take any specific action to unload a profile from the kernel. Instead, I rebooted the system, under the assumption that this would wipe the slate clean, with everything reloading cleanly from /etc/apparmor.d/.

The new profile I developed was under a new filename, because I did not want to modify the stock file. Specifically (assuming the profile is "usr.bin.foo"), I created usr.bin.foo.new, and symlinked usr.bin.foo from disable/.

It appears to me that aa-remove-unknown (or something like it) should be invoked on startup. The cache is supposed to be an implementation detail (so that the system doesn't spend much time compiling the profiles every time they are loaded), but in this case, it is behaving as a sort of opaque "shadow config" outside of /etc, which is very bad.

I can understand that if I edit a file under /etc, the change may not take effect as soon as I save it. Sometimes I have to send a SIGHUP, sometimes I have to restart the daemon, etc. But if I reboot the system, then I think it is reasonable to assume that the entire system config is reloaded (or behaves as if it were reloaded) from /etc. The cache should be properly updated by the system in that situation---it should not require additional action by the user.

[John Johansen (jjohansen)]

Daniel,

Right the profile should be removed on reboot, or service restart, having stale cache files loaded is a huge problem.

It is the auto-cleanup of old cache files when a profile is manually deleted/renamed that is a wishlist item.

With this clarification I am moving this from wishlist back to undecided. And will look into this further.

[Daniel Richard G. (skunk)]

Thanks. I am in complete agreement.

I don't need (or even want) AppArmor to automagically update the kernel state right after changing something under /etc/apparmor.d/, because having to do a SIGHUP/restart/etc. is already normal practice. But I do expect that a reboot/reload will take care of that for me, as it does for other services.

[Daniel Richard G. (skunk)]

A related issue: "/etc/init.d/apparmor stop" should invoke aa-teardown(8). Depending on the semantics of the apparmor "service," this could also be "/etc/init.d/apparmor unload" or the like. I was surprised to find that "apparmor stop" was not actually unloading the profiles, as I had assumed.

From the perspective of a sysadmin, I rely on the init scripts to manage daemons/services without having to know the specific technical details of how to interact with each one. A major reason why those scripts exist is to translate a simple start/stop logic into whatever that reasonably means for a particular daemon or service.

[John Johansen (jjohansen)]

/etc/init.d/apparmor stop cannot and should not invoke aa-teardown. Such a stop mechanism was the source of many problems and the reason stop was switch to a no-opin /etc/init.d/apparmor and teardown was added.

Unfortunately systemd implements restart as stop followed by start. This a very poor fit for apparmor as once the security state is torn down you have to restart all services or in some cases the entire system.

Admittedly the current situation is less than ideal, there are WI scheduled to help better address this but atm the stop behavior is deliberate as on a whole it causes less problems than using teardown.

[Daniel Richard G. (skunk)]

That's why I hedged on having something like "apparmor unload". What you're saying explains why "restart" and "reload" are distinct actions (I'd never been clear on this), so having a new action that is "like 'stop' but actually does stop apparmor, even though that is not usually what you want" makes similar sense.