[apparmor] Profile Templating

[John Johansen]

On 03/26/2011 03:24 PM, Christian Boltz wrote:
> Hello,
> 
> Am Samstag, 26. März 2011 schrieb John Johansen:
>> 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.
> 
> IMHO options 1 and 2 are not needed, they are not even a good idea 
> because they make the syntax more complicated than needed and make the 
> profiles harder to read. (And I don't even want to know how many code 
> sections you would need to change to implement this.)
> 
Not say they are or aren't, its just something that came up again this
week so its worth exploring and getting opinions on.  When it comes
to language design I definitely need input from others.

>> 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>
>>   }
> 
> Yes, exactly this is the way to go IMHO.
> 
quite likely

>> in many ways this is an appealing option but its not always the
>> most convenient.  
> 
> Well, then you should fix it where it is broken - make creating and 
> handling of abstractions easier.
> 
yes this has been needed for a long time

> As an example: logprof always adds new rules to the main profile. 
> It should offer an option to add a rule to a include'd file.
> 
well not just that it would be nice if we had some smarts as to show
when rules are common across profiles.
> 
> That's one thing. Another idea that reaches your goals without making 
> the syntax too complicated: support an additional way for #include.
> It should include the content/rules of a complete profile except the 
> profile name - basically the result of
> 
>     grep -v "^/.*{\|^}" /etc/apparmor.d/bin.ping
> 
> Syntax-wise, it could be something like
> 
>     #include content <bin.ping>
> 
thats and interesting idea

> (the additional keyword is just an idea to show what I mean - I don't 
> say that "content" is the perfect keyword for this. "rules" might be 
> another option, or maybe something completely different ;-)
> 
right, just like I was throwing out possibilities, to get the idea across

> BTW: you can also "sell" the above grep command as a new shiny 
> "aa_create_abstraction_from_profile" tool *g*
> 
hehe, well I don't know about that, but a better way to create
abstractions is needed and comming.  I have nearly finished enough of the
parser work that we can use the backend to analyze policy, so that it
can automatically show the grouping of common rules from all the profiles,
even when the rules contain regexes.

The idea being feed it all the profiles, and it will dump back out the
sets with the rules for each set.

Eg.
p1 {              p2 {             p3 {
  /rule1 rw,         /rule1 r,        /rule1 w,
  /rule2 r,          /rule2 r,
  /rule3 w,          /rule3 w,        /rule3 w,
                     /rule4 w,
}                 }                }


{p2} {
  /rule4 w,
}

{p1, p2} {
  /rule1 r,
  /rule2 r,
}

{p1, p3} {
  /rule1 w,
}

{p1, p2, p3} {
  /rule3 w,
}


This should help a lot in making abstractions.