[apparmor] Bug#735470: Fwd: Bug#735470: Could be implemented centrally with a dpkg trigger instead of requiring every package shipping an apparmor file to use dh_apparmor

[John Johansen]

On 01/17/2014 02:26 AM, Didier 'OdyX' Raboud wrote:
> Le jeudi, 16 janvier 2014, 14.49:06 Kees Cook a écrit :
>> On Thu, Jan 16, 2014 at 07:37:04PM +0100, Didier 'OdyX' Raboud wrote:
>>> man deb-trigggers contradicts you, in my reading; an 'activate
>>> /etc/apparmor.d' triggers' file in apparmor would make its action
>>> run _before_ cups (which would have shipped
>>> /etc/apparmor.d/usr.sbin.cupsd) would be 'configured' (hence its
>>> postinst run).
>>
>> Right, sorry, you are right, but my original observation stands: we
>> should never reload all apparmor profiles when installing a single
>> profile. Just the single profile should be reloaded. Otherwise we end
>> up doing very CPU expensive work for no reason. The point of
>> dh-apparmor is to reload a single profile, not all of them.
> 
> That's quite easily circumvented in the trigger code by maintaining a 
> list of timestamps for the various apparmor.d/* files, as is done for 
> cups:
> 
> http://sources.debian.net/src/cups/1.7.1-2/debian/cups.postinst#L181
> 
> Then the trigger can reload only the concerned profiles, and never do it 
> for all of them. (Using the dpkg hashsums instead of timestamps would 
> allow doing it only for _changed_ profiles too.)
> 
> I'll try implementing something along those lines this week-end.
> 
Its not just profile time stamps, any update to any of the include files
the profile depends on must also be checked.

The parser does check those dependent time stamps at the moment. What it
doesn't do is abort loading the profile if the cached version is up to
date.

The parser could and should pickup the ability to introspect the kernel
and abort the load if the profile is there. Which would fix the problem
for kernels that have the introspection patch, or 3.12+ kernels. For
other kernels we can just always load or fallback to the -u flag style
patch.

The -u flag patch I posted is a work around that could work from triggers.
Basically it tells the parser to make the assumption that if there is
a cached profile and it is good to assume you are doing an update and
to skip loading it to the kernel.

This should not be used in initial load from the init script because
you can't assume a profile is loaded. But it works for packaging hooks
because if the package adds a profile or updates a profile or dependencies
it will get properly loaded