[apparmor] Profile Templating

[John Johansen]

On 03/26/2011 01:36 AM, John Johansen wrote:
> So this is to propose another extension to the profile language, and get
> feed back on different possible syntax.
> 
> The basic idea is creating new profiles based off of already existing
> profiles.  Instead of manually duplicating the profile it would be nice
> to be able say this new profile is the same as X but I want to add Y
> to it.
> 
> so there are few basic ways I have kicked around to go about this
> 
> 1.  Declare the profile as part of an exec rule
> 
>   profile /foo {
> 
>     /bar  px -> /foo + { deny network, }
> 
>   }
> 
> this seem convenient but makes it hard to reuse the profile if it
> is used in multiple rules.  It also further clutters the exec rule.
> It also doesn't provide for a profile name so the tools would have
> to generate one and it may be hard to which profile maps to which
> transition.
> 
> 2. Extend profile declaration to allow combining profiles/rules.
> 
>   profile foo2 is /foo + { deny network, }
> 
>   profile /foo {
> 
>     /bar px -> foo2,
>   }
> 
> this allows keeping profile creation separate from x transition
> rules, provides a name for the profiles, and I think has the
> potential to be extended more easily in the future.
> 
> It also has the potential to have generic template blocks declared
> that could be reused with out creating a profile from them
> 
>   template base {
>     ..
>   }
> 
>   profile foo is base + { deny network, }
> 
> 
> 
> The other thing to work out is of course syntax,  Should + used
> or a more explicit keyword like union, etc.
> 
> The goal here is to make things cleaner, and enabled better reuse.
> Which brings the third option,
> 
> 3. Just make better use of includes
> Templating can largely be achieved by just using includes, by
> sticking the profile contents in an include and doing
> 
>   profile /foo {
>     #include <foo_base>
>   }
> 
>   profile foo2 {
>      #include <foo_base>
>      deny network,
>   }
> 
> in many ways this is an appealing option but its not always the
> most convenient.  I know this discussion is actually similar to
> a previous discussion but it came up again this week so I am
> interested in more feedback.
> 
> 

So just to clarify a couple things,

1) The previous discussion that was similar was about parameterizing
includes, and the decision was it wasn't needed/added more complexity
than the benefits it would bring.

2) This specific discussion is about whether its worth adding extension
to make it easier to define new profiles based on a profile that has
already been defined.

Includes do provide a mechanism for doing this, but requiring abstracting
out the original profile, and only work for the union of rules case.

This isn't about dynamic profile stack which is a separate discussion
that needs to be still had.