[apparmor] Profile Templating

[Christian Boltz]

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.)

> 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.

> 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.

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.


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>

(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 ;-)

BTW: you can also "sell" the above grep command as a new shiny 
"aa_create_abstraction_from_profile" tool *g*


Regards,

Christian Boltz
-- 
Fsck, I'm remembering back to the pre-archived-by-Google era of Usenet;
some local newbie was asking how to compile RM COBOL programs in the
Unix environment, and my anti-COBOL bias might have shown through as I
explained that the RM COBOL compiler on Unix was named "rm".     [AdB]