[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 08:02 PM, Seth Arnold wrote:
> On Thu, Jan 16, 2014 at 05:03:43PM -0800, John Johansen wrote:
>> Well some of this will depend on which parser version you want to support.
> 
> Argh. Leave it to me to forget that kernel, userspace, and surrounding
> frameworks do not update in lockstep. Just how many dimensions does this
> matrix have, anyway?
> 
> - Kernel
>   - No introspection
>   - Poor introspection
>   - Good introspection
>   - Features file
>   - Features directory
profile sha1 that can be enabled based on whether you want to linkin/compiler crypto

> 
> - Parser
>   - No caching
- No cache invalidation. The first generation of caching was done entirely in the
initscripts and was based on the parser using -S to dump the profile.

>   - Cache invalidation based on profile timestamp?
>   - Cache invalidation based on profile timestamp and features?
>   - Cache invalidation based on profile and include timestamps and
>     features?
>   - Explicitly named profiles
you can delete this. Explicitly named profiles existed before caching. They where
added in 2.3, -S was added in 2.1 and the init script handling of caching later.

>   - Directory-at-a-time
> 
> - init
>   - No AppArmor knowledge
how about initscripts with all too much apparmor knowledge? having to manage the
cache etc.

>   - Upstart with AppArmor knowledge with --write-cache (I hope this is the
>     only version..)
Hrmmm I am not sure what upstart is doing wrt the --write-cache flag

> 
> - Packages
>   - dh_apparmor with --write-cache (I hope this is the only version..)
> 
as far as I know

> - Click packages
>   - click.py with --write-cache (I hope this is the only version..)
> 
hrmm just a couple things.

Realistically we don't need to worry about history too much. We modify init scripts
going forward. And we can selectively backport if needed.

The case we really have to watch is people compiling their own kernels, so
we would like to work at least some in those cases. And we need to support kernels
that are a couple years old as best we can.

I think -u flag achieves most of this, and it can be made better by extending the
parser to introspect the kernel before policy loads on kernels that support it.