[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 04:20 PM, Seth Arnold wrote:
> [I've trimmed the Cc:, it didn't seem worthwhile to keep all this in the
> Debian BTS in addition to the usual mail list archives.]
> 
> On Thu, Jan 16, 2014 at 04:15:35PM -0800, John Johansen wrote:
>> It does not at the moment consider what is loaded into the kernel, but only
>> works off of the cache time stamps. For older kernels there really isn't
>> a way to check if what is loaded in the kernel is up to date. However
>> for 3.12+ kernels we could leverage the policy dir to compare timestamps
>> or if policy hashing is enabled we could compare to the sha1 stored for
>> each profile that is loaded.
>>
>> we can of course also change the letter chosen
> 
>> @@ -873,6 +878,14 @@
>>  		if (!skip_read_cache &&
>>  		    stat(cachename, &stat_bin) == 0 &&
>>  		    stat_bin.st_size > 0 && (mru_t_cmp(stat_bin.st_mtim))) {
>> +			if (update_only) {
>> +				/* cache hit means profile is not out of
>> +				 * date so don't load
>> +				 */
>> +				if (show_cache)
>> +					PERROR("skipping load of up to date: %s\n", cachename);
>> +				goto out;	/* retval already 0 */
>> +			}
>>  			if (show_cache)
>>  				PERROR("Cache hit: %s\n", cachename);
>>  			retval = process_binary(option, cachename);
> 
> I don't like this much; why wouldn't -u be the default?
> 
> I know that /etc/apparmor/parser.conf can be used to set default options,
> but I like that even less -- the parser shouldn't behave differently from
> system to system.
> 
> Most of the time --replace is the right option. Most of the time
> --write-cache is the right option. And once we're happy with the
> implementation of -u, it should probably be used for every --replace.
> 
> So why expose it to the user? Why not just do it?
> 
Because as the patch stands, -u prevents loading of profiles on boot/
if for some reason a profile isn't loaded and has a cache file.

Oh look the timestamp is good, so I can skip loading it!

We could invert the flag and use that instead for anything that is
supposed to load a profile regardless of whether a cache file exists.
But until the kernel load picks up introspection, this is the best we
can do.

Please by all means add kernel introspection. I don't have time atm
but if you want to pick that up as part of your init rework I'd be
ecstatic.