[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/16/2014 04:23 PM, Seth Arnold wrote:
> On Thu, Jan 16, 2014 at 02:57:52PM -0800, John Johansen wrote:
>> Is there a way for a trigger to notice which file was updated?
>> That way we could use a trigger.
>>
>> If not another option that comes to mind is we could add a new flag to the
>> parser that would say reload only if the cache is out of date.
>>
>> The trigger would have to still do work figuring out which cache files
>> are out of date but thats still better than reloading everything to the
>> kernel.
> 
> One of my work-items for 14.04 LTS is to rework the AppArmor policy
> loading.
> 
yes something that desperately needs to be done

> Currently, the initscript does some work to figure out which profile files
> to load, which ones to ignore, and calls the parser individually for each
> file. There are (in Ubuntu) profiles in both /etc/apparmor.d/ and in
> /var/lib/apparmor/profiles/.
> 
yep, its a pita

> The initscript also attempts to manage the caches; 'service apparmor
> restart' or 'service apparmor stop' actually deletes the entire cache
> regardless if it makes sense to do so.
> 
yep

> I'd like the parser to take on as many of the tasks from the initscripts
> as possible. Clearing the cache is a bad idea when stopping or restarting
> the AppArmor "service", and in the usual case of "service apparmor start",
> I'd like the parser to be in charge of determining which files to load
> and if the cached profiles can be read. (This could remove some 30-50
> or more fork+exec()s of the parser.)
> 
yep

> Perhaps the parser should also be extended to determine if a loaded
> profile is older than the cached profile or the plaintext profile; I
this will be possible but requires a newer kernel. In older kernels you
either have no introspection (upstream), or limited introspection (patched).

With the 3.12 we finally have the policy directory which we can leverage.
We could use the timestamps (though there is a bug where the modified
time stamp isn't being updated on replace) or the sha1 profile hash.

> believe the parser currently loads the profiles it was asked to load
> regardless if the kernel already has the identical profile already loaded.
> 
yes it does. Again determining whether the loaded profile was the same
was just not possible in the past

> If dh_apparmor doesn't currently use --write-cache we should make it do
> so, to allow the compilation to be saved for later. Same with the click
> packaging hooks.
> 
well it has to use write-cache to update the cache. The issue isn't so
much the current dh_apparmor hook. But that you have to use the dh_apparmor
hook instead of a trigger to reload policy.

the -u patch I just posted is a 95% solution for that. It is missing the
ability to know what has been loaded to the kernel. It can't detect if
the profile has been loaded so shouldn't be used on in an init script
but it will work from a trigger. If the profile is new (cache file is
missing) or updated, it will reload the profile.

> Upstart currently has some AppArmor policy knowledge built-in. We should
> also make sure it Does The Right Thing, ideally that'd be mostly up to
> the parser to get correct.
> 
Well some of this will depend on which parser version you want to support.
Eg. the dev branch supports having the parser manage the whole directory
   apparmor_parser -r -W /etc/apparmor.d/

where in the past you had to give it a list of profiles

> I'm sure there's more I've over-looked, I've not looked at this for a
> while, so please feel free to speak up if I've overlooked important
> considerations.
> 
> Thanks
>